Phát hành phần mềm an toàn hơn: vì sao vẫn cần staging?

UDT Insights

Từ kho tri thức UDT: ghi chép đào tạo CI/CD, tháng 5/2024. Bài biên tập mới.

Pipeline xanh là bằng chứng, chưa phải quyền phát hành

Một bản phát hành có thể vượt qua kiểm tra tự động nhưng vẫn sai trong luồng sử dụng thực tế. Bộ kiểm tra có thể bỏ sót tích hợp, khác biệt cấu hình hoặc thao tác ngoài dự kiến. Hãy hỏi pipeline đã kiểm tra gì trước khi xem trạng thái xanh là sẵn sàng.

Bài viết đề xuất cách rà soát phát hành cho đội khách hàng và kỹ thuật. Từ kiến thức đào tạo CI/CD, bài bổ sung khuyến nghị thực hành về staging, phê duyệt và khôi phục.

Giao cho staging một nhiệm vụ rõ ràng

Jenkins mô tả pipeline phân phối là quy trình lặp lại được, đưa bản build qua các bước kiểm thử và triển khai.[2] Quy trình cần các kiểm tra có ý nghĩa, không chỉ một chuỗi lệnh tự động.

Dùng staging để kiểm tra bản dự kiến phát hành trước khi người dùng thật phụ thuộc vào nó. Chạy các luồng quan trọng và điểm tích hợp. Thống nhất điều kiện nào cần giống production, đồng thời ghi rõ những khác biệt còn lại.

Đừng gọi staging là bản sao hoàn toàn nếu chưa kiểm chứng. Dữ liệu, dịch vụ bên ngoài hoặc cấu hình khác nhau có thể làm hành vi thay đổi. Kiểm tra đạt trên staging giúp làm rõ điều kiện đã thử. Nó không chứng minh production sẽ hoạt động giống hệt.

Checklist phát hành cần giúp đưa ra quyết định

Giao người phụ trách từng kiểm tra. Gắn bằng chứng với đúng bản dự kiến phát hành, không chỉ dựa vào tóm tắt cuộc họp.

• Bản dự kiến phát hành: xác định phiên bản và gói build nhóm định đưa lên.
• Truy vết: ghi thay đổi mã nguồn, kết quả build và kiểm tra gắn với bản đó.
• Staging: chạy luồng chính, các ranh giới tích hợp và tình huống lỗi liên quan.
• Khác biệt: ghi chênh lệch môi trường quan trọng và cách kiểm tra rủi ro còn lại.
• Quyết định: ghi giới hạn đã biết, trách nhiệm phê duyệt và điều kiện phải hoãn.
• Khôi phục và xác minh: thống nhất ai được dừng phát hành, khôi phục dịch vụ và kiểm tra production sau đó.

Ví dụ giả định: thông báo xác nhận

Đây là ví dụ giả định, không phải lịch sử bàn giao của UDT. Một nhóm sửa thông báo xác nhận lịch hẹn dịch vụ.

Build và kiểm tra tự động đều đạt. Trên staging, người rà soát đi hết luồng đặt lịch và thấy thông báo vẫn hiển thị giờ hẹn cũ. Một nhánh tích hợp chưa nằm trong bộ kiểm tra hiện có.

Nhóm hoãn phát hành, ghi tình huống lỗi và bổ sung kiểm tra phù hợp. Sau khi sửa, nhóm kiểm tra bản dự kiến phát hành mới có định danh riêng. Không dùng lại phê duyệt cũ cho phần mềm đã thay đổi.

Người phụ trách xem lại khác biệt còn tồn tại rồi cho phép triển khai production. Sau đó, nhóm thực hiện các kiểm tra đã thống nhất. Nếu không đạt, người phụ trách thực hiện phương án khôi phục. Triển khai thành công chưa đồng nghĩa dịch vụ hoạt động đúng.

Luồng phát hành bốn bước

Làm rõ điểm chuyển từ bằng chứng kỹ thuật sang trách nhiệm quyết định.

• Build: tạo và định danh bản dự kiến phát hành có thể truy vết.
• Diễn tập: kiểm tra luồng sử dụng và khác biệt trên staging.
• Phê duyệt: rà soát bằng chứng, giới hạn và khả năng khôi phục.
• Xác minh: phát hành, kiểm tra production và ghi nhận kết quả.

Bắt đầu từ luồng sử dụng quan trọng nhất

Chọn một luồng mà khách hàng hoặc người vận hành nhận ra được. Cùng xác định kết quả mong đợi, hành vi khi lỗi và bằng chứng phát hành. Nhờ vậy, staging có mục đích rõ hơn một nhãn trạng thái kỹ thuật.

Điều chỉnh mức kiểm tra theo thay đổi. Bản nhỏ vẫn cần định danh phiên bản và người chịu trách nhiệm quyết định. Bản phức tạp cần kiểm tra sâu hơn. Không trường hợp nào cần lời hứa thiếu căn cứ rằng tự động hóa loại bỏ mọi rủi ro phát hành.