Mẫu checklist trước release

Cách dùng

Mỗi release chép một bản mới vào phiếu release, điền ngày và số hiệu phiên bản. Mỗi nhóm có một người chịu trách nhiệm ký tên — không phải cả đội cùng tick. Chưa đủ chữ ký thì không cắt bản.

Checklist này bổ sung cho Quy trình release và rollback, không thay thế: bài đó nói làm gì, bài này là thứ chép ra dùng.

Mẫu

# Checklist release <phiên bản> — <ngày>

Người cắt bản:
Người trực 24h đầu:

## 1. Mã nguồn và build          ký:
- [ ] Branch main xanh, không có commit nào chưa qua CI
- [ ] Số hiệu phiên bản và build number tăng đúng quy ước
- [ ] Release notes đã viết, người không làm kỹ thuật đọc hiểu được
- [ ] Không còn feature flag tạm nào bật nhầm
- [ ] Build ký đúng chứng chỉ phát hành, không phải chứng chỉ thử nghiệm

## 2. Kiểm thử                   ký:
- [ ] Critical path suite pass 100%
- [ ] Regression suite đã chạy, các case đỏ đều có phiếu và được chấp nhận
- [ ] Không còn bug P0 hoặc P1 đang mở
- [ ] Đã test trên toàn bộ device Tier 1
- [ ] Đã test kịch bản upgrade từ version đang có trên store, không chỉ cài mới
- [ ] Đã test lifecycle và mất mạng ở các luồng mức risk cao

## 3. Tương thích                ký:
- [ ] API các version còn hỗ trợ vẫn chạy với build này
- [ ] Contract test pass, không có thay đổi phá vỡ tương thích
- [ ] Minimum supported version đặt đúng ở cấu hình server
- [ ] Data migration đã test: version liền trước và version cũ nhất còn hỗ trợ

## 4. Bảo mật và quyền riêng tư  ký:
- [ ] Secret scan và dependency scan không có lỗi High trở lên
- [ ] Checklist security baseline đã soát
- [ ] Khai báo privacy trên App Store và Data Safety trên Play khớp với hành vi thật
- [ ] SDK mới thêm trong release này đã được duyệt và ghi vào bảng kiểm kê

## 5. Cửa hàng ứng dụng          ký:
- [ ] Ảnh chụp màn hình và mô tả đã cập nhật nếu giao diện đổi
- [ ] Đã tính thời gian review của App Store vào lịch phát hành
- [ ] Cấu hình staged rollout đặt đúng tỷ lệ khởi điểm

## 6. Vận hành                   ký:
- [ ] Crash reporting và analytics hoạt động trên build này
- [ ] Analytics event của tính năng mới đã kiểm chứng trên build thật
- [ ] Dashboard kỹ thuật và nghiệp vụ sẵn sàng, cắt được theo version
- [ ] Feature flag của tính năng mới đặt đúng trạng thái khởi điểm
- [ ] Phương án lui đã ghi rõ: tắt flag nào, dừng rollout ra sao, ai được quyết
- [ ] Bộ phận hỗ trợ đã biết có gì thay đổi

Sau khi mở rộng rollout

Chép thêm phần này và điền ở mỗi mốc:

## Theo dõi rollout

| Mốc | Ngày giờ | Crash-free | Đăng nhập | Thanh toán | Quyết định |
|---|---|---|---|---|---|
| 1%   | | | | | đi tiếp / dừng |
| 10%  | | | | | đi tiếp / dừng |
| 50%  | | | | | đi tiếp / dừng |
| 100% | | | | | — |

Số điền vào là số của version mới so với version liền trước, không phải số tổng — xem Production monitoring.

Khi cần bỏ qua một mục

Có. Nhưng phải để lại dấu vết, vì một quality gate không có đường xin ngoại lệ chính thức sẽ bị lách bằng đường không chính thức — và đường không chính thức thì không ai nhìn thấy.

Yêu cầu	Nội dung
Ai duyệt	Chủ kỹ thuật, cộng chủ sản phẩm nếu mục bị bỏ thuộc nhóm 2, 3 hoặc 4
Ghi ở đâu	Ngay trong phiếu release, dưới mục bị bỏ
Ghi những gì	Bỏ mục nào, vì sao, risk chấp nhận là gì, ai theo dõi
Trả nợ khi nào	Một hạng mục trong backlog, hạn chậm nhất là release kế tiếp

Cấm tuyệt đối một cách: hạ severity của một bug để nó không còn chặn checklist. Đó không phải ngoại lệ, đó là làm sai dữ liệu — và nó phá luôn chỉ số defect leakage ở Quality metrics.

Giới hạn

• Checklist dài ra theo thời gian là chuyện tự nhiên và cũng là rủi ro. Mỗi quý soát lại: mục nào ba release liền không bắt được gì thì bỏ hoặc chuyển thành kiểm tra tự động.
• Mục nào máy kiểm được thì chuyển cho máy. Checklist tay chỉ nên giữ những thứ cần phán đoán của con người.