Hướng dẫn thiết lập CI/CD pipeline tự động cho dự án web

CI/CD pipeline là chuỗi bước tự động chạy mỗi khi có thay đổi mã nguồn: kiểm tra định dạng và lỗi tĩnh, chạy test, build sản phẩm, rồi triển khai lên môi trường thử nghiệm và production. CI (Continuous Integration – tích hợp liên tục) đảm bảo mọi thay đổi được kiểm tra ngay khi đẩy lên; CD (Continuous Delivery/Deployment – chuyển giao hoặc triển khai liên tục) đảm bảo phần mềm luôn sẵn sàng phát hành và có thể deploy chỉ bằng một thao tác hoặc hoàn toàn tự động. Bài hướng dẫn này mô tả cách thiết kế pipeline cho một dự án web điển hình, với ví dụ trên GitHub Actions, áp dụng tương tự cho GitLab CI hay các công cụ khác.

Lợi ích thực tế

• Phát hiện lỗi sớm, khi thay đổi còn nhỏ và người viết còn nhớ ngữ cảnh.
• Deploy trở thành việc nhàm chán, lặp lại được, không phụ thuộc vào "người biết deploy".
• Giảm lỗi do thao tác tay như quên chạy migration, build sai nhánh.
• Tăng tần suất phát hành, mỗi lần phát hành nhỏ hơn nên rủi ro thấp hơn.

Các giai đoạn của một pipeline web

Nguyên tắc quan trọng: build một lần, deploy nhiều nơi. Cùng một image đi từ staging lên production, chỉ khác cấu hình môi trường, để thứ bạn đã kiểm tra chính là thứ chạy thật.

Ví dụ với GitHub Actions

Workflow là file YAML trong thư mục .github/workflows. Một cấu trúc gợi ý gồm ba workflow:

1. ci.yml chạy khi có pull request: checkout, cài đặt runtime với cache, chạy lint, test. Có thể dùng matrix để test trên nhiều phiên bản runtime. Với integration test cần database, khai báo service container PostgreSQL ngay trong job.
2. build-deploy.yml chạy khi merge vào main: build Docker image, đẩy lên registry, deploy staging, chạy smoke test, rồi deploy production qua environment có yêu cầu phê duyệt.
3. scheduled.yml chạy định kỳ: quét lỗ hổng phụ thuộc, dọn tài nguyên cũ.

Docker image là đơn vị triển khai thuận tiện; cách viết Dockerfile tối ưu có trong bài cách sử dụng Docker container hóa ứng dụng.

Quản lý bí mật và quyền

• Lưu mật khẩu, token trong Secrets của kho hoặc của environment, không bao giờ in ra log.
• Với cloud (AWS, Google Cloud, Azure), dùng xác thực OIDC giữa GitHub Actions và nhà cung cấp để nhận thông tin đăng nhập tạm thời, không lưu access key dài hạn.
• Giới hạn quyền của GITHUB_TOKEN ở mức tối thiểu trong từng workflow.
• Ghim phiên bản action bên thứ ba theo mã commit thay vì thẻ có thể bị thay đổi.
• Không chạy workflow có bí mật cho pull request từ fork chưa được tin cậy.

Các lớp quét bảo mật nên gắn vào pipeline được trình bày trong bài xu hướng DevSecOps.

Chiến lược deploy và rollback

• Rolling: thay dần từng instance cũ bằng instance mới; mặc định của nhiều nền tảng.
• Blue-green: chạy song song môi trường cũ và mới, chuyển lưu lượng một lần, quay lại tức thì nếu lỗi.
• Canary: chuyển một phần nhỏ lưu lượng sang bản mới, theo dõi chỉ số rồi tăng dần.
• Feature flag: deploy code nhưng bật tính năng sau, tách thời điểm deploy khỏi thời điểm phát hành.

Luôn có cách rollback nhanh: deploy lại image của phiên bản trước. Với migration database, áp dụng thay đổi tương thích ngược (thêm cột trước, xóa cột sau) để rollback code không làm vỡ dữ liệu.

Môi trường và cấu hình

Pipeline cần biết sẽ deploy tới đâu và với cấu hình nào. Cách làm phổ biến là định nghĩa các environment như staging và production, mỗi environment có bộ biến và bí mật riêng, quy tắc bảo vệ riêng (ví dụ production chỉ deploy từ nhánh main và cần một người phê duyệt). Cấu hình ứng dụng đọc từ biến môi trường theo nguyên tắc của mô hình twelve-factor app, không đóng gói cứng vào image. Với ứng dụng có nhiều nhánh tính năng, có thể tạo môi trường xem trước (preview) tạm thời cho mỗi pull request để người kiểm thử và bên nghiệp vụ xem thay đổi trước khi merge, rồi tự xóa khi pull request đóng để không tốn chi phí.

Giữ pipeline nhanh

• Cache phụ thuộc và lớp Docker.
• Chạy song song các job độc lập (lint, unit test, quét bảo mật).
• Chỉ chạy job liên quan khi thư mục tương ứng thay đổi (với monorepo).
• Chia nhỏ bộ test lớn ra nhiều runner.
• Theo dõi thời gian pipeline; nếu vượt khoảng mười phút, đội sẽ bắt đầu né tránh hoặc gom thay đổi lớn.

Kiểm thử trong pipeline

Pipeline chỉ đáng tin bằng bộ test của nó. Ngoài unit test, nên có integration test với database thật trong container và một bộ kiểm thử API sau khi deploy staging; bộ collection Postman chạy bằng Newman là cách nhanh để bắt đầu, xem bài cách sử dụng Postman kiểm thử API. Test chập chờn phải được sửa hoặc cách ly ngay để đội không quen bỏ qua pipeline đỏ.

Lựa chọn công cụ CI/CD

Pipeline tốt được xây dần: bắt đầu bằng lint và test cho pull request trong ngày đầu, thêm build và deploy staging trong tuần, rồi mới tự động hóa production khi đội đã tin tưởng vào bộ test.