Vào thẳng nội dung

Hướng dẫn Phân nhánh & CI/CD (Branching & CI/CD Guidance)

Mục đích: Cung cấp một chính sách ngắn gọn, thực tế và các ví dụ mẫu mà các đội ngũ có thể áp dụng cho việc tích hợp, phân nhánh và thiết lập rào chắn kiểm soát chất lượng CI (CI gating). Trang này được thiết kế súc tích — các nhóm nên điều chỉnh chính sách sao cho phù hợp với dự án và chuỗi công cụ (toolchain) của mình.

  • Ưu tiên phát triển dựa trên nhánh chính (Trunk-based development) bất cứ khi nào có thể đối với các dự án mới. Sử dụng các nhánh tính năng ngắn hạn (short-lived feature branches) khi cần thiết và hợp nhất (merge) thường xuyên vào nhánh tích hợp mặc định (thường là main hoặc trunk).
  • Sử dụng quy tắc bảo vệ nhánh (Branch protection rules) trên nhánh tích hợp để thực thi các cửa ngõ chất lượng (bắt buộc vượt qua CI, bắt buộc có người review code, vượt qua các bước kiểm tra trạng thái).
  • Quy trình phát hành đơn giản: Tạo tag/release trực tiếp từ nhánh tích hợp và lưu trữ tài liệu quy trình phát hành riêng biệt.

Ví dụ về các quy tắc bảo vệ nhánh (Example branch protection rules)

  • Bắt buộc có ít nhất một reviewer phê duyệt (approve) cho mỗi Pull Request (PR).
  • Bắt buộc toàn bộ pipeline CI kiểm thử thành công trước khi cho phép merge.
  • Bắt buộc cập nhật nhánh tính năng mới nhất theo nhánh chính trước khi merge.

Mẫu GitHub Actions CI cơ bản (Sample minimal GitHub Actions CI gate)

name: ci
on: [pull_request]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test

Danh mục kiểm tra chính sách Merge gợi ý (Merge policy checklist)

  • Mã nguồn biên dịch thành công và toàn bộ kiểm thử tự động vượt qua trong CI.
  • Có ít nhất một reviewer phê duyệt thay đổi.
  • Thay đổi được liên kết với một hạng mục công việc (Work Item) hoặc Issue cụ thể.
  • Đã cập nhật tài liệu tương ứng nếu có thay đổi liên quan.

Lời khuyên hữu ích (Tips)

  • Giữ các nhánh tính năng tồn tại trong thời gian ngắn (short-lived); việc merge thường xuyên giúp giảm đáng kể rủi ro xung đột tích hợp (integration risk).
  • Tự động hóa tối đa các rào chắn kiểm soát (linting, kiểm thử đơn vị, quét bảo mật cơ bản) để các reviewer con người có thể tập trung vào thiết kế, thuật toán và kiến trúc hệ thống.
  • Điều chỉnh các quy tắc bảo vệ nhánh phù hợp với quy mô đội ngũ và nhịp độ bàn giao.

Hướng dẫn CI/CD chuyên sâu

Trang này bổ trợ cho tài liệu Hướng dẫn CI/CD cốt lõi. Những kỳ vọng chính mà các đội ngũ nên tuân thủ:

  • Nhánh tích hợp (main) luôn ở trạng thái sẵn sàng xuất xưởng (continuously shippable) và ổn định — tại bất kỳ thời điểm nào, chúng ta đều có thể triển khai bản build từ main lên môi trường production nếu cần.
  • Chạy pipeline kiểm soát chất lượng (linting, unit tests, integration tests cơ bản) trên mỗi PR và mỗi khi merge vào nhánh chính.
  • Khởi tạo tài nguyên đám mây và cấu hình môi trường thông qua mã nguồn (Infrastructure as Code - IaC, ví dụ: Terraform, Bicep, Pulumi) và thử nghiệm chúng trên các môi trường non-production.
  • Tự động triển khai các bản release candidate lên môi trường non-production để kiểm chứng tích hợp và vận hành thực tế.
  • Tự động hóa quy trình phát hành (release) và quay lui (rollback) để việc bàn giao có thể lặp lại ổn định và dễ dàng kiểm toán.
Cập nhật cuối cùng: 11 tháng 11, 2026
Back to top