CI/CD chất lượng: quality gate, rollback và release an toàn

CI/CD không chỉ là tự động deploy#

Một pipeline CI/CD chuyên nghiệp không đơn giản là push code rồi server tự restart. Nó là chuỗi kiểm soát chất lượng giúp team biết thay đổi nào đủ điều kiện đi tiếp, artifact nào được phát hành, rủi ro nào còn mở và rollback bằng cách nào nếu production lỗi.

Điểm dễ sai là nhầm tốc độ với sự vội vàng. CI/CD tốt làm team đi nhanh hơn vì loại bỏ thao tác thủ công, nhưng vẫn giữ checkpoint rõ ràng: kiểm tra code, test, build artifact, scan, review, deploy và quan sát sau deploy.

Quality gate nên bắt lỗi đúng tầng#

Quality gate là các điều kiện phải pass trước khi merge hoặc deploy. Với web app, một bộ gate hợp lý thường gồm lint, type check, unit test, integration test quan trọng, build production, dependency audit và kiểm tra secret. Không phải gate nào cũng chạy ở mọi push. Gate nhanh nên chạy ở pull request; gate nặng có thể chạy theo lịch hoặc trước release.

• Lint: bắt lỗi style, pattern nguy hiểm và code dễ gây bug.
• Type check: bắt lỗi contract giữa component, API, model và helper.
• Unit test: kiểm tra logic nhỏ, nhanh, ít phụ thuộc môi trường.
• Integration test: kiểm tra luồng nhiều module như auth, post creation, checkout.
• Build: xác minh app có thể tạo artifact production.
• Security scan: phát hiện dependency rủi ro, secret hoặc image vulnerability.

Đừng biến gate thành hình thức. Nếu một gate thường xuyên fail vì flaky test, team sẽ mất niềm tin và bắt đầu bỏ qua nó. Test flaky cần được sửa hoặc tách ra khỏi đường merge chính cho tới khi ổn định.

Artifact phải bất biến và truy vết được#

Mỗi lần build production nên tạo artifact có định danh rõ: image tag theo commit SHA, package version hoặc build number. Khi production đang chạy version nào, bạn phải truy về được commit, pull request, người approve và log deploy. Nếu production build lại từ source theo trạng thái hiện tại của main, rollback sẽ kém chắc chắn.

IMAGE_TAG=$(git rev-parse --short HEAD)
docker build -t registry.example.com/app:$IMAGE_TAG .
docker push registry.example.com/app:$IMAGE_TAG

Với frontend như Next.js, artifact có thể là Docker image, output build hoặc deployment trên platform. Với backend, artifact có thể là image hoặc binary. Dù hình thức nào, nguyên tắc vẫn giống nhau: build một lần, deploy artifact đó qua các môi trường.

Rollback là một phần của thiết kế release#

Nếu chỉ nghĩ tới deploy lên mà không nghĩ tới quay lại, pipeline chưa hoàn chỉnh. Rollback app thường dễ hơn rollback database. Vì vậy migration cần được thiết kế tương thích ngược khi có thể. Một release an toàn thường chia thay đổi lớn thành các bước nhỏ.

1. Thêm cột/bảng mới nhưng chưa dùng bắt buộc.
2. Deploy code ghi song song hoặc đọc được cả schema cũ và mới.
3. Backfill dữ liệu nếu cần.
4. Chuyển traffic sang logic mới.
5. Sau khi ổn định, dọn schema cũ ở release sau.

Cách này giảm rủi ro khi cần rollback code. Nếu migration phá schema ngay trong cùng release, rollback app có thể không đủ để phục hồi.

Promotion giữa môi trường#

Staging không nên là nơi build lại một artifact khác với production. Lý tưởng hơn là cùng một artifact được promote qua dev, staging và production với configuration khác nhau. Điều này giúp bạn test đúng thứ sắp chạy ở production.

Configuration nên nằm ở environment variable hoặc secret manager. Secret không đi vào image. Feature flag có thể giúp bật/tắt hành vi mới theo nhóm user, nhưng feature flag cũng cần cleanup. Flag để lâu trở thành một nhánh logic ẩn khó test.

Checklist release an toàn#

• Pull request nhỏ, có mô tả risk và cách test.
• CI pass lint, type check, test và build production.
• Artifact được gắn tag theo commit hoặc version.
• Migration tương thích rollback hoặc có kế hoạch phục hồi dữ liệu.
• Deploy có health check và timeout rõ ràng.
• Dashboard có error rate, latency, throughput và log liên quan.
• Rollback command hoặc quy trình rollback được viết trước.

Nguồn tham khảo chính#

• GitHub Docs: GitHub Actions
• Kubernetes Docs: Deployments
• Docker Docs: Multi-stage builds