Bàn giao mã nguồn: checklist để không mất quyền kiểm soát

Bàn giao mã nguồn là việc chuyển giao kho mã, lịch sử thay đổi, quy trình dựng, cấu hình, giấy phép và quyền sở hữu tài khoản. Bàn giao chỉ hoàn tất khi người không quen dự án dựng lại và chạy được sản phẩm từ kho của bên nhận.

Tóm tắt nhanh

• Nhận tệp nén mã nguồn không phải là bàn giao; đó là sao chép.
• Điều kiện nghiệm thu thực tế là dựng lại được từ máy sạch, bằng tài khoản của bên nhận.
• Quyền sở hữu kho mã và tài khoản bên thứ ba quan trọng ngang nội dung mã nguồn.
• Giấy phép của thư viện và tài nguyên phải được kê trước khi ký, không phải sau.
• Bốn kiểu thất bại phổ biến đều để lại một điểm phụ thuộc duy nhất vào nhà cung cấp cũ.

Bàn giao mã nguồn không phải gửi tệp nén

Một tệp nén chứa mã nguồn trả lời được câu hỏi "mã của sản phẩm là gì". Nó không trả lời được bốn câu quan trọng hơn: mã đã thay đổi thế nào, dựng ra bản chạy bằng cách nào, cấu hình nào làm nó chạy, và ai có quyền sửa nó.

Lịch sử thay đổi là thứ đầu tiên bị mất khi chỉ nhận tệp nén. Không có lịch sử, không ai biết một đoạn mã được thêm để sửa lỗi gì, và cũng không ai dám sửa vì sợ làm hỏng một thứ không được ghi lại. Với hệ thống đã chạy vài năm, mất lịch sử làm chi phí tiếp nhận tăng lên đáng kể, dù mã nguồn vẫn đầy đủ.

Cách kiểm tra đơn giản nhất là đặt câu hỏi: nếu ngày mai nhà cung cấp cũ không còn tồn tại, bên nhận có tự dựng lại được hệ thống trong một ngày làm việc không? Nếu câu trả lời là không, việc bàn giao chưa xong, bất kể đã nhận bao nhiêu tệp.

Mười hai hạng mục bàn giao

Mười hai hạng mục này không cùng mức độ. Hạng mục 1, 4 và 12 là nhóm chặn: thiếu một trong ba thì bên nhận không thực sự kiểm soát hệ thống. Các hạng mục còn lại ảnh hưởng đến tốc độ và chi phí tiếp nhận. Khi thời gian eo hẹp, ưu tiên nhóm chặn trước, nhưng vẫn phải ghi các hạng mục còn lại vào danh sách mục treo có hạn đóng.

Bài kiểm tra dựng lại từ đầu

Đây là bài kiểm tra duy nhất chứng minh bàn giao mã nguồn đã hoàn tất. Nó phải được thực hiện bởi người của bên nhận, trên máy không có công cụ hay cấu hình do nhà cung cấp cài trước.

1. Máy sạch. Dùng một máy hoặc máy ảo mới, chỉ cài hệ điều hành và công cụ phiên bản cơ bản.
2. Tài khoản bên nhận. Đăng nhập kho mã bằng tài khoản của bên nhận, không dùng tài khoản được mời tạm.
3. Đúng thẻ phát hành. Lấy đúng thẻ tương ứng với bản đang chạy trên môi trường thật.
4. Cài phụ thuộc từ tệp khoá. Không cài thủ công từng gói; dùng tệp khoá để phiên bản khớp.
5. Tạo cấu hình từ tệp mẫu. Chỉ dùng giá trị mẫu, không dùng giá trị thật của môi trường thật.
6. Dựng bản phát hành. Chạy đúng lệnh trong tài liệu, không hỏi thêm.
7. Chạy bộ kiểm thử. Ghi lại số lượng kiểm thử đạt và thất bại.
8. Khởi động và gọi thử. Chạy trên môi trường tạm, gọi một giao diện lập trình và một màn hình chính.

Tiêu chí đạt: tám bước hoàn tất, không cần nhà cung cấp cũ hỗ trợ, và thời gian được ghi lại. Nếu bước 6 hoặc bước 7 cần hỏi, đó là bằng chứng tài liệu chưa đủ. Nếu bước 2 phải dùng tài khoản được mời, đó là bằng chứng quyền sở hữu chưa chuyển.

Nên chạy bài kiểm tra này trước buổi ký, không phải sau. Một buổi kiểm tra mất nửa ngày nhưng phát hiện được phần lớn vấn đề, trong khi phát hiện sau khi ký thì chi phí sửa do bên nhận chịu.

Quyền sở hữu tài khoản: mời vào hay chuyển chủ

Có hai cách cấp quyền khác nhau về bản chất, và biên bản cần ghi rõ đang dùng cách nào.

Mời vào tổ chức giữ chủ sở hữu là nhà cung cấp. Bên nhận có quyền đọc, ghi hoặc quản trị, nhưng quyền đó phụ thuộc vào tài khoản của nhà cung cấp. Khi hợp đồng kết thúc hoặc có tranh chấp, quyền có thể bị thu hồi.

Chuyển quyền sở hữu đưa tổ chức, tên miền, tài khoản thanh toán về bên nhận. Cách này chậm hơn và có thể phát sinh chi phí chuyển, nhưng là cách duy nhất để bên nhận thực sự sở hữu hệ thống.

Với kho mã, nên tạo tổ chức riêng của bên nhận ngay từ đầu dự án, và mời nhà cung cấp vào với quyền cần thiết. Khi đó việc thu hồi quyền chỉ là xoá thành viên, không phải chuyển toàn bộ lịch sử. Với tên miền, chủ thể đăng ký phải là bên nhận; nhà cung cấp chỉ giữ quyền quản lý kỹ thuật nếu cần.

Sau khi chuyển, bắt buộc phải xoay toàn bộ khoá bí mật. Khoá cũ đã từng nằm trong tay nhà cung cấp thì không còn là bí mật, kể cả khi chưa có dấu hiệu bị lộ. Danh sách tối thiểu gồm khoá gọi dịch vụ bên ngoài, khoá ký phiên đăng nhập, mật khẩu cơ sở dữ liệu, khoá lưu trữ tệp và khoá cổng thanh toán.

Giấy phép và phụ thuộc bên thứ ba

Mã nguồn của dự án hiếm khi chỉ chứa mã do nhà cung cấp viết. Nó chứa thư viện mã nguồn mở, tài nguyên hình ảnh, phông chữ, thành phần trả phí và đôi khi cả đoạn mã sao chép từ nguồn khác. Mỗi loại có điều kiện sử dụng riêng.

Bảng kê giấy phép nên được tạo tự động từ tệp phụ thuộc, rồi bổ sung thủ công phần tài nguyên không nằm trong trình quản lý gói. Khi bàn giao, bảng này là một hạng mục có bằng chứng, không phải lời cam kết "toàn bộ thư viện đều miễn phí".

Mã nguồn thuộc về ai

Đây là câu hỏi pháp lý, và câu trả lời phụ thuộc vào hợp đồng chứ không phụ thuộc vào việc ai viết nhiều hơn. Một số hợp đồng chuyển toàn bộ quyền sở hữu khi thanh toán đủ; một số chỉ cấp quyền sử dụng; một số giữ quyền sở hữu cho nhà cung cấp và cấp phép lại cho khách hàng.

Ba điểm nên kiểm tra trong hợp đồng trước khi bàn giao. Thứ nhất, thời điểm chuyển quyền: khi ký, khi thanh toán đủ, hay khi hết thời hạn bảo hành. Thứ hai, phạm vi chuyển: chỉ mã nguồn hay bao gồm tài liệu, thiết kế, cơ sở dữ liệu và tài nguyên hình ảnh. Thứ ba, quyền của bên thứ ba: thư viện và thành phần trả phí vẫn thuộc chủ sở hữu của chúng, nên hợp đồng không thể chuyển những gì nhà cung cấp không sở hữu.

Một cơ chế giảm rủi ro là ký gửi mã nguồn. Bên nhận giữ một bản sao trong kho trung lập, chỉ được mở khi xảy ra sự kiện đã định nghĩa, ví dụ nhà cung cấp ngừng hoạt động. Cơ chế này không thay thế việc chuyển quyền, nhưng giúp bên nhận không bị kẹt nếu quan hệ đổ vỡ. Điều khoản cụ thể cần luật sư soạn; bài viết này chỉ nêu cơ chế để bạn biết cần hỏi gì.

Sáu điều khoản nên có trong hợp đồng

Bàn giao là sự kiện hợp đồng, không chỉ là sự kiện kỹ thuật. Sáu điều khoản dưới đây biến các hạng mục kỹ thuật thành nghĩa vụ kiểm được.

Điều khoản phạm vi là điều khoản hay bị viết mơ hồ nhất. Cụm từ "toàn bộ mã nguồn liên quan đến dự án" nghe đầy đủ nhưng không xác định được biên giới: thành phần dùng chung giữa nhiều khách hàng có thuộc phạm vi không, thư viện nội bộ của nhà cung cấp có được chuyển không, tài nguyên thiết kế có nằm trong "mã nguồn" không. Cách viết an toàn là liệt kê theo nhóm và ghi rõ phần loại trừ.

Điều khoản điều kiện nên dẫn chiếu đến một phụ lục kỹ thuật mô tả bài kiểm tra dựng lại. Khi điều kiện nằm trong hợp đồng dưới dạng một câu như "bàn giao đầy đủ, đúng hạn", hai bên sẽ tranh cãi về định nghĩa đầy đủ. Khi điều kiện là tám bước kiểm tra với tiêu chí đạt rõ ràng, tranh cãi chuyển thành câu hỏi kỹ thuật có câu trả lời.

Điều khoản sau bàn giao thường bị bỏ quên vì cả hai bên tập trung vào ngày chuyển giao. Nó cần trả lời ba việc: quyền truy cập của nhà cung cấp cũ được thu hồi khi nào, khoá bí mật nào phải xoay, và dữ liệu của khách hàng được xoá hoặc trả lại theo hình thức nào. Thiếu điều khoản này, quyền truy cập cũ có thể tồn tại rất lâu sau khi hợp đồng kết thúc.

Bốn kiểu bàn giao thất bại

Chỉ nhận tệp nén. Dấu hiệu: không có kho mã, không có lịch sử. Hậu quả: không truy vết được thay đổi, chi phí tiếp nhận tăng, dễ phát sinh lỗi khi sửa. Cách phòng: yêu cầu quyền truy cập kho ngay từ đầu dự án, không đợi đến cuối.

Kho mã thuộc nhà cung cấp. Dấu hiệu: bên nhận chỉ là thành viên được mời. Hậu quả: quyền bị thu hồi khi quan hệ kết thúc. Cách phòng: tạo tổ chức của bên nhận và mời nhà cung cấp vào, ghi rõ trong hợp đồng.

Bản dựng chỉ chạy trên máy nhà cung cấp. Dấu hiệu: dựng thành công ở máy họ, thất bại ở máy khác; không có tệp khoá phụ thuộc; biến môi trường nằm trong tệp cá nhân. Hậu quả: không thể phát hành bản sửa lỗi khẩn cấp. Cách phòng: chạy bài kiểm tra dựng lại từ máy sạch trước khi ký.

Thiếu bảng kê giấy phép. Dấu hiệu: không ai biết thành phần trả phí nào đang dùng, hoặc thư viện copyleft nằm sâu trong hệ thống. Hậu quả: rủi ro pháp lý xuất hiện khi sản phẩm phát triển, không phải lúc bàn giao. Cách phòng: tạo bảng kê từ tệp phụ thuộc và rà soát định kỳ, không chỉ một lần.

Bốn kiểu này có chung một đặc điểm: chúng không gây lỗi ngay, nên dễ bị bỏ qua trong buổi bàn giao. Chúng chỉ biểu hiện khi có sự cố, khi cần thay đổi lớn, hoặc khi quan hệ với nhà cung cấp thay đổi. Vì vậy, kiểm tra phải dựa trên bằng chứng chứ không dựa trên cảm giác yên tâm.

Câu hỏi thường gặp

Bàn giao mã nguồn có cần bàn giao cả cơ sở dữ liệu không?

Cần bàn giao lược đồ, danh sách migration và dữ liệu mẫu, không cần bàn giao dữ liệu thật của khách hàng. Dữ liệu thật nên được chuyển qua kênh riêng, có kiểm soát và làm sạch trước khi dùng cho kiểm thử. Nếu bên nhận không có lược đồ và migration, họ không thể nâng cấp hoặc khôi phục hệ thống một cách an toàn.

Có nhất thiết phải chuyển quyền sở hữu kho mã cho khách hàng không?

Nên chuyển, hoặc tạo tổ chức riêng của khách hàng ngay từ đầu. Mời khách hàng vào tổ chức của nhà cung cấp là cách nhanh nhưng tạo ra điểm phụ thuộc duy nhất. Trong trường hợp không thể chuyển, hợp đồng cần quy định rõ nghĩa vụ bàn giao và cơ chế xử lý khi nhà cung cấp không thực hiện.

Làm sao biết bộ kiểm thử có thực sự chạy?

Chạy nó trên máy sạch và đọc kết quả, thay vì xem ảnh chụp màn hình. Kiểm tra thêm rằng bộ kiểm thử có dữ liệu riêng, không phụ thuộc vào cơ sở dữ liệu thật, và có ít nhất một bài kiểm tra thất bại khi cố tình sửa một điều kiện. Nếu bộ kiểm thử luôn báo đạt trong mọi trường hợp, nó không phải lưới an toàn.

Ký gửi mã nguồn có thay thế được việc bàn giao không?

Không. Ký gửi là cơ chế dự phòng cho tình huống xấu, không phải quy trình bàn giao thông thường. Bên nhận vẫn cần kho mã, lịch sử, quy trình dựng và quyền sở hữu tài khoản để vận hành hằng ngày. Ký gửi chỉ có giá trị khi bản gửi được cập nhật định kỳ và có quy trình mở đã thoả thuận trước.

Cập nhật và kiểm chứng

Cập nhật tháng 11/2026. Nội dung được rà soát theo thực tiễn bàn giao dự án phần mềm và các khung quản lý mã nguồn hiện hành. Bài viết mang tính tham khảo, không phải tư vấn pháp lý; điều khoản sở hữu, ký gửi và giấy phép cần được luật sư xem xét theo hợp đồng cụ thể.

Bài viết liên quan: quy trình phát triển phần mềm là gì, quy trình phát triển phần mềm gồm những bước nào và thuế GTGT của phần mềm là bao nhiêu.

Nếu bạn cần bàn giao mã nguồn kèm bài kiểm tra dựng lại và bảng kê giấy phép thay vì một tệp nén, WinSell xây dựng phần mềm theo yêu cầu theo bốn giai đoạn Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — xem dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.