CI/CD Pipeline: Tự động hóa quy trình deploy với GitHub Actions

GitHub Actions cho phép bạn tự động chạy kiểm thử, build và deploy ứng dụng mỗi khi có push hoặc pull request, ngay trong kho mã GitHub mà không cần dựng máy chủ CI riêng. Bài này đi thẳng vào thực hành: cấu trúc một workflow, cách tách job kiểm thử và deploy, cách quản lý môi trường và secrets, cùng những mẹo giúp pipeline chạy nhanh và an toàn hơn.

GitHub Actions hoạt động thế nào

Mỗi pipeline trong GitHub Actions là một workflow, được định nghĩa bằng file YAML đặt trong thư mục .github/workflows/. Workflow được kích hoạt bởi sự kiện như push, pull_request, lịch cron hoặc kích hoạt thủ công (workflow_dispatch). Một workflow gồm nhiều job; mỗi job chạy trên một runner (máy ảo Linux, Windows, macOS do GitHub cung cấp hoặc máy tự host) và gồm nhiều step. Step có thể là lệnh shell hoặc một action đóng gói sẵn từ Marketplace.

Mặc định các job chạy song song; muốn job B chờ job A, bạn khai báo needs. Đây là cơ chế để xây chuỗi "kiểm thử xong mới build, build xong mới deploy".

Workflow CI tối thiểu cho một dự án Node.js

Một workflow kiểm thử đơn giản chạy lint và test trên mọi pull request vào nhánh main gồm các thành phần sau:

• name: ci đặt tên workflow.
• on: pull_request với branches: [main] để chỉ chạy khi có pull request nhắm vào main.
• Một job tên test với runs-on: ubuntu-latest.
• Step 1 dùng action actions/checkout@v4 để lấy mã nguồn.
• Step 2 dùng actions/setup-node@v4 với node-version: 20 và cache: npm.
• Các step tiếp theo lần lượt chạy npm ci, npm run lint và npm test.

Vài điểm đáng chú ý: npm ci cài đúng phiên bản theo lockfile nên kết quả lặp lại được; tùy chọn cache: npm lưu thư mục cache giữa các lần chạy giúp giảm thời gian cài đặt. Khi workflow thất bại, GitHub hiển thị dấu đỏ ngay trên pull request, và bạn có thể bật branch protection để bắt buộc check này phải xanh trước khi merge.

Từ CI đến CD: thêm bước build và deploy

Phần CD thường tách thành workflow riêng, kích hoạt khi có push vào main (tức là sau khi pull request đã merge). Cấu trúc gợi ý:

1. Job test: chạy lại kiểm thử trên mã đã merge.
2. Job build: needs: test, build ảnh Docker hoặc gói tĩnh, gắn tag bằng mã commit (github.sha) và đẩy lên registry như GitHub Container Registry.
3. Job deploy-staging: needs: build, cập nhật môi trường staging với đúng ảnh vừa build.
4. Job deploy-production: needs: deploy-staging, gắn với environment "production" có yêu cầu phê duyệt thủ công.

Gắn tag theo mã commit thay vì latest giúp bạn biết chính xác phiên bản nào đang chạy và rollback chỉ bằng cách deploy lại tag cũ. Bước deploy cụ thể tùy nền tảng: cập nhật dịch vụ ECS, chạy kubectl set image trên cụm Kubernetes, đồng bộ file lên S3 kèm làm mới CDN, hoặc SSH vào máy ảo. Nếu bạn deploy lên máy chủ EC2, tham khảo cách chuẩn bị một instance EC2 từ đầu trước khi tự động hóa.

Environments, phê duyệt và quy tắc bảo vệ

Tính năng Environments của GitHub cho phép định nghĩa staging, production với secrets riêng và quy tắc bảo vệ riêng. Với production, bạn có thể yêu cầu một hoặc nhiều người duyệt, giới hạn chỉ nhánh main được deploy, hoặc đặt thời gian chờ. Lịch sử deploy theo từng môi trường cũng được hiển thị trên trang kho mã, thuận tiện khi cần biết bản nào đang chạy.

Lưu ý một số tính năng bảo vệ môi trường phụ thuộc gói GitHub và loại kho (công khai hay riêng tư); hãy kiểm tra tài liệu chính thức cho gói bạn đang dùng.

Quản lý secrets an toàn

Pipeline deploy cần thông tin xác thực đến cloud, registry hoặc máy chủ. Nguyên tắc chung:

• Lưu thông tin trong Secrets ở cấp kho, tổ chức hoặc environment; không bao giờ ghi vào file YAML.
• Ưu tiên OIDC: GitHub Actions phát token định danh ngắn hạn, cloud provider (AWS, Azure, Google Cloud) tin tưởng token đó và cấp quyền tạm thời. Bạn không còn phải lưu khóa truy cập dài hạn.
• Đặt permissions ở đầu workflow để giới hạn quyền của GITHUB_TOKEN, ví dụ chỉ contents: read nếu không cần ghi.
• Cẩn thận với sự kiện pull_request_target và pull request từ fork: không chạy mã chưa tin cậy với quyền truy cập secrets.
• Ghim action bên thứ ba theo mã commit SHA thay vì tag, vì tag có thể bị dịch chuyển.

Những thực hành này là một phần của tư duy rộng hơn được trình bày trong bài DevSecOps và nguyên tắc bảo mật đám mây.

Tăng tốc pipeline

Pipeline chậm khiến lập trình viên mất tập trung và gom nhiều thay đổi vào một lần, làm tăng rủi ro. Một số kỹ thuật hữu ích:

• Cache phụ thuộc: dùng actions/cache hoặc tùy chọn cache tích hợp trong các action setup ngôn ngữ.
• Cache layer Docker: docker/build-push-action hỗ trợ cache qua GitHub Actions cache backend.
• Matrix: chạy kiểm thử song song trên nhiều phiên bản runtime hoặc chia nhỏ bộ test thành nhiều phần.
• Lọc theo đường dẫn: dùng paths để chỉ chạy workflow khi thư mục liên quan thay đổi, rất có ích với monorepo.
• Concurrency: khai báo concurrency với cancel-in-progress: true để hủy lần chạy cũ khi có commit mới trên cùng nhánh.

Tái sử dụng workflow

Khi tổ chức có nhiều kho với quy trình giống nhau, sao chép YAML khắp nơi sẽ nhanh chóng lệch nhau. GitHub cung cấp hai cơ chế tái sử dụng:

Runner do GitHub cung cấp hay tự host

Runner của GitHub tiện lợi, sạch sau mỗi lần chạy và không cần bảo trì. Runner tự host phù hợp khi bạn cần phần cứng đặc thù (GPU, nhiều RAM), truy cập mạng nội bộ hoặc muốn kiểm soát chi phí khi chạy rất nhiều. Đổi lại, bạn chịu trách nhiệm cập nhật và cô lập chúng. Không nên dùng runner tự host cho kho công khai, vì pull request từ người lạ có thể chạy mã tùy ý trên máy của bạn.

Theo dõi và xử lý sự cố

Khi một bước thất bại, log chi tiết có sẵn trong tab Actions. Bật biến ACTIONS_STEP_DEBUG để có log chi tiết hơn. Với deploy, nên có bước kiểm tra sức khỏe (health check) sau khi cập nhật và tự động rollback nếu thất bại. Gửi thông báo kết quả deploy đến kênh chat của đội giúp mọi người cùng nắm trạng thái.

Checklist trước khi đưa pipeline vào dùng thật

• Branch protection bắt buộc CI xanh trước khi merge.
• Ảnh build được gắn tag theo commit và lưu trong registry.
• Production yêu cầu phê duyệt và dùng secrets riêng.
• Quyền GITHUB_TOKEN được giới hạn; ưu tiên OIDC thay khóa dài hạn.
• Có quy trình rollback đã được thử ít nhất một lần.

Khi đã nắm GitHub Actions, bạn có thể tìm hiểu bức tranh tổng thể hơn về các tầng kiểm thử trong một quy trình CI/CD để quyết định nên chạy loại test nào ở giai đoạn nào.