Kho mã và phạm vi bàn giao
Danh mục bàn giao nên chỉ rõ từng kho mã, mục đích sử dụng, nhánh đang chạy thực tế, phiên bản phát hành gần nhất và các mô-đun dùng chung. Nên giữ lịch sử commit, tag và ghi chú phát hành thay vì chỉ nhận bản mã cuối cùng, vì lịch sử thay đổi giúp đội tiếp quản đối chiếu nguyên nhân lỗi và xác định những phần đang được bảo trì.
Gợi ý: chuyển quyền quản trị kho mã sang tài khoản do doanh nghiệp kiểm soát và lập bảng trạng thái cho từng thành phần. Nếu dự án tham chiếu thư viện nội bộ, kho riêng, submodule hoặc gói phần mềm không công khai, bảng này cần ghi rõ nguồn phụ thuộc, cách truy cập và thành phần nào không thuộc phạm vi bàn giao.
Build và triển khai có thể lặp lại
Tài liệu kỹ thuật cần nêu phiên bản runtime, trình quản lý gói, lệnh cài đặt, lệnh build, bộ kiểm thử và cách tạo bản phát hành. Tệp khóa phiên bản phụ thuộc, script migration, cấu hình pipeline và script triển khai cũng nên được kiểm tra. Một tiêu chí tiếp nhận hữu ích là môi trường mới có thể tạo và chạy phần mềm từ đúng phiên bản mã đã nhận.
Với hệ thống đám mây, Microsoft lưu ý rằng quy trình triển khai nên được tự động hóa và cho kết quả có thể dự đoán trước; giám sát và telemetry giúp quan sát hệ thống. Gợi ý: nếu dự án đang dùng hạ tầng dưới dạng mã, hãy đưa cấu hình đó vào danh mục bàn giao, đồng thời rà soát để không chuyển bí mật nằm trong tệp cấu hình. [2]
Cấu hình, dữ liệu và tài khoản
Nên tách cấu hình theo môi trường và liệt kê biến môi trường, tên miền, chứng thư, tài khoản dịch vụ, kho lưu trữ, dịch vụ gửi thư cùng các tích hợp bên thứ ba. Không nên ghi mật khẩu hoặc khóa bí mật trực tiếp trong biên bản. Gợi ý: chuyển bí mật qua công cụ quản lý phù hợp, đổi thông tin xác thực sau tiếp nhận và xác định người sở hữu từng tài khoản.
Nếu hệ thống có cơ sở dữ liệu, phạm vi bàn giao nên gồm lược đồ, migration, dữ liệu mẫu đã xử lý phù hợp và hướng dẫn sao lưu, khôi phục. Cần phân biệt dữ liệu phục vụ chạy thử với dữ liệu thật của khách hàng. Doanh nghiệp nên tự xác nhận phạm vi truy cập và chuyển dữ liệu theo chính sách quản trị dữ liệu đang áp dụng.
Kiến trúc và hướng dẫn vận hành
Một sơ đồ ngắn gọn nên thể hiện các thành phần, luồng dữ liệu, API, tác vụ nền, điểm tích hợp và phụ thuộc quan trọng. Kèm theo đó là hướng dẫn khởi động, dừng, triển khai, quay lui, đọc log và xử lý sự cố thường gặp. Kiến trúc không mặc nhiên phải là microservices; Microsoft khuyến nghị lựa chọn kiểu kiến trúc và mẫu thiết kế theo yêu cầu kinh doanh cùng các đánh đổi của từng phương án. [2]
Ví dụ: với ứng dụng bán hàng, tài liệu có thể mô tả luồng từ giao diện đến API, cơ sở dữ liệu và cổng thanh toán; chỉ rõ nơi xem log khi giao dịch lỗi, cách chạy migration, cách quay lui bản phát hành và phiên bản cấu hình đang dùng ở môi trường sản xuất.
Bảo mật và xác nhận tiếp nhận
NIST mô tả phát triển phần mềm an toàn như các thực hành cần được tích hợp vào vòng đời phát triển và điều chỉnh theo rủi ro, chi phí, tính khả thi cùng nguồn lực. Từ đó, gợi ý kiểm tra khi bàn giao gồm kết quả quét phụ thuộc nếu có, danh sách lỗ hổng còn mở, cơ chế phân quyền, nhật ký thay đổi và quy trình cập nhật. Các mục này hỗ trợ quản lý rủi ro, không bảo đảm an toàn tuyệt đối. [1]
Biên bản tiếp nhận nên ghi phiên bản của từng hiện vật, tài khoản đã chuyển, hạng mục còn thiếu và cách xác nhận khả năng build hoặc triển khai. Nên ghi riêng các tệp đã nhận và các tài liệu quy định phạm vi sử dụng, chuyển giao hoặc sở hữu mã nguồn. Nếu nội dung chưa rõ, doanh nghiệp cần đối chiếu hợp đồng và giấy phép liên quan thay vì suy ra quyền chỉ từ việc đang giữ bản mã.