CI/CD cơ bản cho team dev nhỏ

Với team dev nhỏ, release thường bắt đầu bằng vài lệnh thủ công: pull code, build, restart service. Cách này có thể ổn ở giai đoạn đầu, nhưng càng về sau càng dễ lỗi: quên chạy migration, deploy nhầm branch, thiếu biến môi trường hoặc không biết bản nào đang chạy trên server.

CI/CD giúp biến release thành một quy trình có thể lặp lại. Không nhất thiết phải phức tạp ngay từ đầu; một pipeline nhỏ nhưng rõ ràng đã đủ giúp team tự tin hơn khi ship sản phẩm.

CI và CD là gì?

CI, viết tắt của Continuous Integration, là quá trình tự động kiểm tra code mỗi khi có thay đổi. CD có thể hiểu là Continuous Delivery hoặc Continuous Deployment, tức tự động hóa bước đóng gói và đưa ứng dụng lên môi trường chạy.

• CI trả lời: code mới có làm hỏng test/build không?
• CD trả lời: làm sao đưa bản build đã kiểm tra lên staging hoặc production một cách ổn định?

Pipeline tối thiểu nên có gì?

Một pipeline cơ bản cho team nhỏ có thể bắt đầu với bốn bước: install dependencies, lint/test, build, deploy. Đừng thêm quá nhiều bước nếu team chưa thật sự cần; mục tiêu là giảm lỗi release, không phải tạo một hệ thống automation khó hiểu.

1. Checkout source code từ repository.
2. Cài dependency theo lockfile.
3. Chạy lint, type check và unit test.
4. Build artifact hoặc Docker image.
5. Deploy lên staging trước, production sau.

Ví dụ workflow đơn giản

Với GitHub Actions, một workflow Node.js tối giản có thể trông như sau:

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

Tách staging và production

Ngay cả với team nhỏ, staging vẫn rất hữu ích. Đây là nơi kiểm tra build thật trước khi đẩy production. Nếu có thể, hãy để mọi merge vào main deploy staging tự động, còn production cần approval hoặc tag release.

• Staging: deploy thường xuyên, dùng để test nhanh.
• Production: deploy có kiểm soát, có changelog và rollback plan.
• Preview environment: hữu ích cho frontend hoặc pull request lớn, nhưng không bắt buộc lúc đầu.

Secrets phải được quản lý đúng

Không bao giờ commit secret vào Git. Token deploy, SSH key, database URL, API key cần nằm trong secret store của CI provider. Quyền của secret cũng nên giới hạn theo môi trường.

• Tách secret staging và production.
• Dùng deploy key hoặc token có quyền tối thiểu.
• Rotate secret khi nghi ngờ bị lộ.
• Không in secret ra log pipeline.

Deploy không chỉ là copy file

Một bước deploy tốt cần trả lời vài câu hỏi: migration chạy khi nào, service restart ra sao, health check ở đâu, nếu deploy lỗi thì rollback thế nào. Với sản phẩm nhỏ, bạn có thể bắt đầu bằng script đơn giản nhưng script đó phải rõ ràng và có log.

set -e

git pull origin main
npm ci --omit=dev
npm run build
npm run migrate
pm2 reload app
curl -f https://example.com/health

Rollback plan là bắt buộc

Một pipeline không có rollback chỉ mới làm được nửa việc. Ít nhất team cần biết bản release trước là gì, artifact nằm ở đâu và cách quay lại khi production lỗi.

• Giữ lại artifact hoặc Docker image của vài bản gần nhất.
• Tag release rõ ràng theo version hoặc timestamp.
• Ghi changelog ngắn cho mỗi lần deploy.
• Theo dõi log và metric ngay sau release.

Checklist CI/CD cho team nhỏ

1. Mỗi pull request phải chạy test/build tự động.
2. Không deploy production từ máy cá nhân.
3. Secret nằm trong CI provider, không nằm trong repo.
4. Staging chạy gần giống production nhất có thể.
5. Có health check và rollback plan tối thiểu.

Kết luận

CI/CD không phải đặc quyền của team lớn. Với team nhỏ, một pipeline đơn giản nhưng đáng tin cậy giúp giảm stress khi release và giảm lỗi do thao tác thủ công. Hãy bắt đầu từ CI cho pull request, sau đó thêm deploy staging, rồi mới tự động hóa production khi team đã đủ tự tin với quy trình.