CI/CD không chỉ là Build: xây dựng Quality Gate với GitLab CI và GitHub Actions

Tóm tắt: 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ữ chính: 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

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.

Vì sao cách làm đơn giản chưa đủ

GitLab CI và GitHub Actions khác cú pháp nhưng cùng kiến trúc: quyền hạn tối thiểu, job cô lập, thành phần phụ thuộc rõ, gói phát hành không thể thay đổi và phê duyệt theo môi trường.

Security gate phải có thể xử lý. Lỗi phát hiện cần chính sách theo mức nghiêm trọng, người phụ trách, ngày hết hạn cho ngoại lệ và đường cập nhật thành phần phụ thuộc mà không tắt công cụ quét.

Luồng xử lý

Quyết định kiến trúc

Fail fast rồi mới đi sâu

Chạy formatting, kiểm tra mã nguồn, lint và type trước. Integration test, build và scan chỉ chạy song song sau khi check rẻ đạt.

Build một lần, chuyển tiếp nhiều nơi

Tạo container hoặc package từ commit đã rà soát, ghi digest rồi dùng lại ở môi trường thử nghiệm và môi trường thật thay vì rebuild.

Tách vùng tin cậy

Fork và các job kiểm tra nhánh đề xuất thay đổi dùng chỉ đọc token. Ký số và triển khai chỉ chạy trên nhánh hoặc thẻ được bảo vệ bằng danh tính của tiến trình ngắn hạn và môi trường được duyệt.

Phân tích chuyên sâu

kiểm tra mã nguồn bắt drift ẩn

Kiểm tra formatting, mã máy khách được sinh tự động, schema output, lockfile consistency và file lớn/secret bị cấm. Thư mục làm việc phải sạch sau generation.

Security ngoại lệ là debt được kiểm soát

ngoại lệ tạm ghi lỗi phát hiện, người phụ trách, biện pháp kiểm soát bù và ngày hết hạn. Ngoại lệ tạm hết hạn làm pipeline fail thay vì im lặng vĩnh viễn.

Các bước triển khai

1. Validate trạng thái kho mã, lockfile và tệp được sinh tự động trước job tốn tài nguyên.
2. Chạy lint, type check, test và bản build dùng cho môi trường thật song song với quality threshold rõ.
3. Scan nguồn cùng gói phát hành, ký đúng một lần và chuyển tiếp cùng digest qua các môi trường.

Ví dụ kỹ thuật: Các stage cổng 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)

Trong GitLab dùng stages và needs; GitHub Actions dùng jobs và needs. Đặt command trong script của repository để local và CI chạy giống hệt nhau.

Các tình huống lỗi cần tính trước

• Cache khôi phục binary từ branch không tin cậy.
• Test command exit zero sau khi âm thầm skip project bắt buộc.
• triển khai job rebuild với floating base image và tạo digest mới.

Tín hiệu cần giám sát

Cách kiểm chứng thiết kế

• Tạo có chủ đích một lỗi lint, test, build, secret và vulnerable thành phần phụ thuộc để chứng minh từng gate chặn.
• Mở untrusted Pull yêu cầu và xác nhận không chạm protected secret hoặc runner.
• Truy từ môi trường thật digest về commit, check, SBOM, signature và approval.

Kế hoạch triển khai an toàn

Đo pipeline hiện tại rồi thêm gate ở report-only để biết noise. Sửa lỗi xác định, enforcement check nhanh trước, security severity tiếp theo và gói phát hành signing sau cùng. Tối ưu bằng bộ nhớ đệm thư viện cùng parallel job nhưng không làm yếu ranh giới tin cậy.

Checklist trước khi đưa vào vận hành

• Protected branch yêu cầu đủ check và rà soát vẫn còn hiệu lực.
• Pull yêu cầu không tin cậy không đọc secret triển khai hoặc dùng privileged runner.
• Job lỗi hoặc bị cancel không để lại partial gói phát hành có thể phát hành.

Kết luận

CI/CD là chuỗi bằng chứng từ nguồn đã rà soát tới đúng gói phát hành đang chạy môi trường thật.