GitHub Actions CI/CD: quy trình deploy website an toàn

Bạn đã bao giờ deploy website bằng cách kéo file thủ công, sửa nhanh trên production rồi hy vọng mọi thứ vẫn ổn chưa? Cách đó có thể chạy được lúc team còn nhỏ, nhưng chỉ cần một lần quên build, quên file môi trường hoặc push nhầm branch là website có thể lỗi ngay.

CI/CD giúp bạn biến việc build, test và deploy thành một quy trình có kiểm soát. Bài này không cố biến bạn thành DevOps engineer trong một buổi; mục tiêu là giúp bạn có một pipeline đủ an toàn cho website doanh nghiệp. Cùng làm gọn nhé!

CI/CD là gì?

CI/CD là cách dùng workflow trong GitHub để tự động chạy các bước như cài dependency, build, test, đóng artifact và deploy khi có sự kiện như push hoặc pull request. Thay vì nhớ từng lệnh thủ công, bạn mô tả quy trình trong file YAML để GitHub runner thực thi.

GitHub Docs mô tả Actions như nền tảng tự động hóa workflow ngay trong GitHub repository [1]. Với website, điều này đặc biệt hữu ích vì đa số lỗi deploy đến từ thao tác lặp lại: quên chạy build, dùng sai phiên bản Node.js, thiếu file static, deploy nhầm branch hoặc copy thiếu thư mục.

CI là phần kiểm tra liên tục: mỗi khi có thay đổi, pipeline chạy build/test để phát hiện lỗi sớm [2]. CD là phần đưa bản đã kiểm tra sang môi trường deploy, có thể là staging hoặc production [3]. Nếu triển khai đúng, CI/CD không làm bạn mất kiểm soát; nó giúp bạn kiểm soát tốt hơn.

Nếu team của bạn đang có nhiều lỗi Git căn bản, hãy xử lý nền tảng trước. Bài các lỗi Git thường gặp sẽ giúp team hiểu branch, commit và pull request rõ hơn trước khi tự động hóa deploy.

Khi nào website doanh nghiệp cần CI/CD?

Bạn nên triển khai CI/CD khi website có nhiều người cùng sửa, có build step, có staging hoặc có rủi ro kinh doanh nếu deploy lỗi. Nếu website chỉ là landing page tĩnh ít thay đổi, pipeline có thể rất đơn giản; nếu là WooCommerce, SaaS hoặc web app, pipeline cần chặt hơn.

Những dấu hiệu nên làm CI/CD:

• Team thường xuyên quên chạy build trước khi deploy.
• Website có frontend framework như React, Vue, Next.js hoặc Astro.
• Có nhiều branch, pull request và review code.
• Có staging nhưng việc đẩy staging vẫn thủ công.
• Production từng lỗi vì deploy nhầm file hoặc nhầm môi trường.
• Team cần audit ai deploy, deploy lúc nào và commit nào đang chạy.

Ngược lại, nếu một website brochure chỉ cập nhật vài lần mỗi quý, bạn có thể bắt đầu bằng CI đơn giản: kiểm format, build thử và tạo artifact. Chưa cần deploy tự động ngay. Đây là điều mình khuyên nhiều team nhỏ: tự động hóa phần kiểm trước, rồi mới tự động hóa phần đưa lên production.

Pipeline tối thiểu gồm những bước nào?

Một pipeline CI/CD tối thiểu nên có trigger, checkout code, setup runtime, install dependency, build, test và lưu kết quả. Với website Node.js, GitHub Docs có hướng dẫn riêng cho building and testing Node.js, gồm chọn version, install dependencies, build/test và packaging artifacts [4].

Ví dụ workflow tối giản cho website frontend có thể như sau:

name: Kiem tra website

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Lay ma nguon
        uses: actions/checkout@v4

      - name: Cai Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - name: Cai dependency
        run: npm ci

      - name: Build website
        run: npm run build

      - name: Chay test
        run: npm test -- --runInBand

Điểm quan trọng là pipeline phải phản ánh đúng cách team build local. Nếu local dùng npm ci nhưng pipeline dùng npm install, kết quả có thể lệch. Nếu production cần biến môi trường, đừng hardcode vào repository; hãy dùng secrets hoặc environment variables.

Nếu bạn từng gặp lỗi push bị từ chối hoặc nhánh không đồng bộ, đọc thêm bài git push bị rejected. CI/CD chỉ ổn khi Git workflow nền tảng đủ rõ.

Cache và artifact dùng ra sao?

Cache giúp pipeline chạy nhanh hơn bằng cách tái sử dụng dependency, còn artifact là gói kết quả build cần lưu hoặc chuyển sang bước deploy. Hai khái niệm này dễ bị nhầm, nhưng mục đích khác nhau.

GitHub Docs giải thích dependency caching có cache key, cơ chế match key, setup actions cho package manager và các giới hạn truy cập cache [5]. Với Node.js, cách đơn giản là dùng actions/setup-node với cache: npm. Cách này đủ tốt cho phần lớn website nhỏ.

Artifact nên dùng khi bạn cần lưu thư mục build như dist, build hoặc .next để kiểm tra, tải về hoặc chuyển sang job deploy. Ví dụ:

      - name: Luu ban build
        uses: actions/upload-artifact@v4
        with:
          name: website-build
          path: dist/

Guardrail quan trọng: đừng cache thư mục chứa secret, file cấu hình production hoặc output có dữ liệu nhạy cảm. Cache là công cụ tăng tốc, không phải nơi lưu trạng thái bảo mật.

Deploy staging và production nên tách thế nào?

Staging và production nên dùng environment riêng, secrets riêng và điều kiện deploy riêng. Tách môi trường giúp bạn test bản build trên dữ liệu gần thật trước khi ảnh hưởng người dùng thật.

Một cách triển khai dễ hiểu:

• Pull request: chỉ build và test, không deploy.
• Push vào branch develop: deploy staging.
• Push hoặc tag release từ main: deploy production sau approval.

Với website doanh nghiệp, staging nên có URL riêng, có basic auth nếu cần, và không index trên Google. Production nên yêu cầu người có trách nhiệm duyệt nếu deploy có thể ảnh hưởng doanh thu, form lead hoặc checkout. Đây là chỗ GitHub Environments và deployment protection rules rất hữu ích.

Nếu website của bạn có quy trình từ thiết kế sang code, bài Figma to Code Workflow sẽ giúp nối phần thiết kế, review UI và deploy thành một luồng rõ hơn.

Secret và permission cần kiểm gì?

Secret trong Actions cần được lưu trong GitHub Secrets hoặc environment secrets, không để trong code, log hoặc artifact. Đây là phần quyết định pipeline có an toàn hay không.

Checklist ngắn:

• Không commit file .env, khóa SSH, token API hoặc mật khẩu FTP.
• Dùng secret riêng cho staging và production.
• Token deploy chỉ có quyền tối thiểu cần thiết.
• Không in secret ra log bằng lệnh debug.
• Production environment nên có approval gate.
• Thay token ngay nếu nghi ngờ lộ.

Nếu team từng lỡ để file nhạy cảm vào repository, hãy xử lý trước khi bật deploy tự động. Bài .gitignore không hoạt động giải thích vì sao file đã tracked vẫn bị Git theo dõi và cách bỏ tracking an toàn.

Checklist trước khi bật auto deploy

Trước khi bật auto deploy production, bạn cần có pipeline ổn định, rollback rõ ràng, backup đáng tin và quyền deploy được phân tách. Auto deploy không phải mục tiêu cuối cùng; mục tiêu là deploy nhanh hơn mà ít rủi ro hơn.

1. Pull request đã chạy build và test bắt buộc.
2. Staging deploy tự động và có người kiểm.
3. Production dùng environment riêng và secret riêng.
4. Rollback có tài liệu: revert commit, redeploy artifact cũ hoặc restore bản backup.
5. Thông báo deploy gửi vào Slack, email hoặc hệ thống nội bộ.
6. Log deploy ghi rõ commit SHA, người approve và thời điểm.
7. Không có secret trong repository, artifact hoặc log.

Kết luận: CI/CD không cần phức tạp ngay từ đầu. Hãy bắt đầu bằng CI kiểm build/test, sau đó thêm staging deploy, rồi mới cân nhắc production deploy có approval. Làm theo lộ trình này, team nhỏ vẫn có thể deploy chuyên nghiệp mà không tự tạo thêm rủi ro.

Nguồn tham khảo

1. GitHub Docs: Actions
2. GitHub Docs: Continuous integration
3. GitHub Docs: Continuous deployment
4. GitHub Docs: Building and testing Node.js
5. GitHub Docs: Caching dependencies to speed up workflows

Bạn có thể bắt đầu bằng một workflow chỉ build và test pull request trong tuần này. Khi nó ổn định, hãy thêm staging deploy. Đó là bước nhỏ nhưng thay đổi lớn trong cách team kiểm soát website.