Ý chính: Một pipeline CI tốt tạo ra bằng chứng rằng đúng mã nguồn đã được kiểm tra, đóng gói và đưa tới môi trường thật.
Thuật ngữ trong bài: Quality Gate: điều kiện bắt buộc trước khi hợp nhất hoặc phát hành; SAST: quét lỗi bảo mật trong mã nguồn; SBOM: danh sách thành phần có trong sản phẩm.
Bài toán thực tế
Build thành công chưa chứng minh mã nguồn đạt chất lượng. Kiểm thử có thể bị bỏ qua, thư viện có thể có lỗ hổng và secret có thể bị đưa nhầm vào gói. Runner quá nhiều quyền còn biến một Pull Request thành rủi ro đối với toàn bộ chuỗi phát hành.
GitLab CI và GitHub Actions khác cú pháp nhưng cùng một nguyên tắc: quyền tối thiểu, tác vụ cô lập, quan hệ phụ thuộc rõ và một gói phát hành duy nhất được chuyển qua các môi trường.
Cổng bảo mật chỉ hữu ích khi vấn đề phát hiện có người phụ trách, mức độ nghiêm trọng và thời hạn xử lý. Tắt công cụ quét vì quá nhiều cảnh báo chỉ che rủi ro sang chỗ khác.
Thiết kế và triển khai
- Kiểm tra trạng thái kho mã, lockfile và tệp sinh tự động trước các tác vụ tốn tài nguyên.
- Chạy lint, kiểm tra kiểu dữ liệu, kiểm thử và build production song song với ngưỡng chất lượng rõ ràng.
- Quét cả mã nguồn lẫn gói phát hành, ký số đúng một lần và chuyển cùng mã băm qua mọi môi trường.
Mã minh họa: Các giai đoạn kiểm soát chất lượng tương đương
verify: format --check; generated-diff; lockfile-policy
quality: lint; typecheck; unit --coverage; integration
build: production-build; migration-check
security: secret-scan; SAST; dependency-audit; image-scan
release: SBOM; sign(digest); attest(provenance)
deploy: promote(the_same_digest)GitLab dùng stages và needs; GitHub Actions dùng jobs và needs. Đặt lệnh trong script của repository để máy cá nhân và CI chạy cùng một quy trình.
Rủi ro cần tính trước
- Cache khôi phục tệp thực thi được tạo từ một nhánh không đáng tin cậy.
- Lệnh kiểm thử trả mã thành công dù đã âm thầm bỏ qua một project bắt buộc.
- Tác vụ triển khai tự build lại với image nền không khóa phiên bản và tạo ra mã băm khác.
Nên theo dõi gì?
| Tín hiệu | Điều tín hiệu cho biết |
|---|---|
| Thời gian chạy pipeline và thời gian chờ | Cho biết phản hồi có đủ nhanh để đội ngũ không tìm cách bỏ qua kiểm soát. |
| Tỷ lệ lỗi theo cổng và số kiểm thử chỉ đạt sau khi chạy lại | Phân biệt lỗi sản phẩm thật với pipeline thiếu ổn định. |
| Mức bao phủ của mã băm, SBOM và chữ ký | Chứng minh mỗi bản phát hành có thể truy ngược về đúng mã nguồn và bước kiểm tra. |
Đưa vào production từng bước
Đo pipeline hiện tại, thêm từng cổng ở chế độ chỉ báo cáo và xử lý cảnh báo nhiễu trước. Bật bắt buộc cho các bước kiểm tra nhanh, tiếp đến là chính sách bảo mật; sau cùng mới ký số gói phát hành và tối ưu thời gian chạy bằng cache cùng tác vụ song song.
Điều cần nhớ
CI/CD là chuỗi bằng chứng nối mã nguồn đã rà soát với đúng gói phát hành đang chạy trên production.