Bài 44 — Continuous Integration — Build & Test

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng một đội 8 lập trình viên cùng làm một sản phẩm. Mỗi người ngồi code trên nhánh riêng của mình suốt hai tuần, không ai đụng vào code của ai. Đến ngày "gộp code" (merge), cả đội tá hỏa: hàng trăm file xung đột (conflict), người này sửa hàm mà người kia đang gọi, tính năng của bạn A làm hỏng tính năng của bạn B. Đội mất trọn ba ngày chỉ để gộp code — chưa viết thêm được dòng tính năng nào. Trong ngành, người ta gọi nỗi đau này là integration hell (địa ngục tích hợp).

Continuous Integration (CI — Tích hợp liên tục) ra đời để chữa đúng căn bệnh đó. Triết lý cực kỳ đơn giản: thay vì gộp code một lần mỗi hai tuần với đau đớn khủng khiếp, hãy gộp thật thường xuyên — mỗi ngày ít nhất một lần — và mỗi lần gộp đều tự động build và tự động test. Nếu có lỗi, ta biết ngay trong vài phút, khi thay đổi còn nhỏ và dễ sửa, thay vì phát hiện sau hai tuần khi mọi thứ đã rối như tơ vò.

Với một DevOps Engineer, CI là nền móng của toàn bộ pipeline giao hàng phần mềm. Không có CI vững, mọi thứ phía sau — Continuous Deployment, GitOps, feature flags — đều xây trên cát. Bài này sẽ giúp bạn hiểu tường tận CI là gì, một pipeline build & test được cấu trúc ra sao, và cách dựng một pipeline CI chạy thật.

Khái niệm cốt lõi

Định nghĩa chính xác

Continuous Integration là thực hành: mọi lập trình viên merge code của mình vào nhánh chung (main/trunk) một cách thường xuyên — tối thiểu mỗi ngày một lần — và mỗi lần merge đều kích hoạt một quy trình tự động build và tự động test để xác nhận code vẫn hoạt động đúng.

Ba từ khóa cần khắc cốt ghi tâm:

• Thường xuyên (frequently): Merge nhỏ, merge sớm. Nhánh sống càng ngắn (short-lived branch) thì xung đột càng ít.
• Tự động (automated): Không ai bấm nút chạy test thủ công. Máy tự làm mỗi lần có commit.
• Nhanh có phản hồi (fast feedback): Lập trình viên biết code của mình pass hay fail trong vòng vài phút, không phải vài ngày.

Một hiểu lầm phổ biến: nhiều người nghĩ "CI là cái công cụ Jenkins/GitHub Actions". Sai. CI trước hết là một thói quen kỹ thuật của con người (merge thường xuyên); công cụ chỉ là phương tiện tự động hóa. Bạn có Jenkins nhưng cả đội ôm nhánh feature ba tuần mới merge một lần thì bạn không đang làm CI.

Pipeline stages — các chặng của một pipeline CI

Một pipeline CI điển hình chạy tuần tự qua các chặng (stage). Nếu một chặng fail, pipeline dừng lại và báo đỏ ngay, không chạy tiếp chặng sau (fail fast):

1. Checkout & Prepare — CI server kéo (clone) code từ commit vừa được push về, chuẩn bị môi trường (cài runtime, khôi phục cache dependencies).

2. Build / Compile — Biên dịch mã nguồn thành sản phẩm chạy được (với Java là file .jar, với Go là binary, với front-end là bundle JS). Với ngôn ngữ thông dịch như Python/PHP, chặng này thường là kiểm tra cú pháp và cài dependencies. Mục tiêu: khẳng định code build được.

3. Unit Test — Chạy các bài kiểm thử đơn vị, kiểm tra từng hàm/lớp riêng lẻ. Đây là chặng chạy nhanh nhất (thường vài giây tới vài phút) và bắt được nhiều lỗi nhất, nên đặt sớm.

4. Lint & Static Analysis — Kiểm tra chất lượng code: định dạng chuẩn, biến không dùng, lỗ hổng bảo mật cơ bản (SAST). Công cụ như ESLint, golangci-lint, SonarQube.

5. Integration Test — Kiểm thử nhiều thành phần phối hợp với nhau: code + database, code + API ngoài. Chặng này chậm hơn vì cần dựng dịch vụ phụ (thường dùng Docker để bật một database tạm).

6. Package / Artifact — Đóng gói kết quả build thành một "artifact" bất biến: một Docker image, một file zip. Artifact này được đánh dấu bằng commit hash để truy vết.

Ranh giới của CI dừng ở đây: build được, test pass, đóng gói xong. Việc đưa artifact đó lên môi trường chạy thật là địa hạt của Continuous Deployment (Bài 45) — bài này không bàn tới.

Nguyên tắc vàng: "Keep the build green"

Trong văn hóa CI, khi pipeline trên nhánh main báo đỏ (fail), đó là tình trạng khẩn cấp. Cả đội ưu tiên số một là làm nó xanh trở lại, vì main đỏ nghĩa là không ai merge được tiếp một cách an toàn. Nhiều đội áp dụng quy tắc "ai làm gãy build thì người đó (hoặc cả đội) dừng mọi việc để sửa". Đây chính là hiện thực hóa The First Way — Flow mà bạn đã học ở Bài 6: giữ dòng chảy công việc luôn thông suốt.

Tình huống thực tế

Ví dụ 1 — Tiki và bài học "integration hell" trước khi có CI

Hãy hình dung một đội backend tại một sàn thương mại điện tử lớn ở Việt Nam (bối cảnh giả định dựa trên mô hình vận hành phổ biến của các công ty như Tiki, Sendo). Giai đoạn đầu, đội 12 người, mỗi người ôm một nhánh tính năng dài ngày. Cứ cuối mỗi sprint hai tuần, một bạn senior được giao nhiệm vụ "merge master" — và bạn ấy mất trung bình 2 ngày/sprint chỉ để giải quyết conflict và sửa lỗi phát sinh. Tính ra mỗi năm đội đốt khoảng 48 ngày công chỉ cho việc gộp code.

Sau khi áp dụng CI: đội đặt quy tắc mỗi nhánh feature không sống quá 2 ngày, mọi PR đều phải qua pipeline GitHub Actions (build + unit test + lint) mới được merge. Kết quả sau 3 tháng: thời gian gộp code giảm từ 2 ngày xuống gần như bằng 0 vì mỗi lần merge chỉ vài chục dòng thay đổi, conflict hiếm và nhỏ. Số bug lọt lên môi trường staging giảm khoảng 40% vì unit test bắt sớm.

Bài học: integration hell không phải do "code khó" mà do merge quá thưa. Merge càng thường xuyên, mỗi lần merge càng ít đau. CI biến việc gộp code từ một sự kiện đáng sợ thành một hoạt động thường nhật vô hình.

Ví dụ 2 — Một startup fintech và cái giá của pipeline chậm

Một startup fintech ở TP.HCM (bối cảnh giả định) có pipeline CI chạy tới 28 phút mỗi lần push, vì họ nhét cả bộ integration test nặng (kết nối database thật, gọi API bên thứ ba) vào chung với unit test. Hậu quả: lập trình viên push code xong đi uống cà phê 30 phút, mất mạch tư duy; nhiều người bắt đầu "gom nhiều thay đổi rồi push một lần" để đỡ phải chờ — vô tình phá vỡ tinh thần CI (merge nhỏ, thường xuyên).

Đội quyết định tái cấu trúc pipeline theo test pyramid: tách thành hai luồng. Luồng nhanh (build + unit test + lint) chạy dưới 4 phút cho mọi PR — đây là cổng chặn merge. Luồng chậm (integration test đầy đủ) chỉ chạy sau khi đã merge vào main, hoặc chạy ban đêm (nightly). Họ thêm cache dependencies và chạy test song song trên nhiều runner. Pipeline PR từ 28 phút xuống còn 3 phút 40 giây.

Bài học: tốc độ phản hồi là tính mạng của CI. Một pipeline chậm sẽ tự bị lập trình viên phá hoại vì họ tìm cách né. Quy tắc kinh nghiệm: giữ pipeline chặn-merge dưới 10 phút, lý tưởng dưới 5 phút.

Ví dụ 3 — Grab và văn hóa "trust the green build"

Ở quy mô một công ty công nghệ khu vực Đông Nam Á như Grab, hàng nghìn kỹ sư push code mỗi ngày. Điều duy nhất khiến hệ thống này không sụp là niềm tin vào build xanh: nếu pipeline báo xanh, artifact đó được coi là đủ tin cậy để đưa tiếp vào quy trình release. Để niềm tin đó có thật, họ đầu tư rất mạnh vào chất lượng test (không có test "giả xanh"), và họ dùng cơ chế merge queue — khi nhiều PR muốn merge cùng lúc, hệ thống xếp hàng và chạy CI trên trạng thái sau-khi-gộp của từng PR để đảm bảo main không bao giờ vỡ ngay cả khi hai PR riêng lẻ đều xanh nhưng gộp lại thì hỏng.

Bài học: ở quy mô lớn, CI không chỉ là công cụ mà là một hợp đồng niềm tin trong tổ chức. Build xanh phải thực sự có nghĩa là "code an toàn", nếu không toàn bộ dây chuyền phía sau mất giá trị.

Hướng dẫn từng bước

Dưới đây là cách dựng một pipeline CI cơ bản bằng GitHub Actions cho một ứng dụng (ví dụ Node.js). Cùng nguyên lý áp dụng cho GitLab CI, CircleCI hay Jenkins.

Bước 1 — Đặt quy ước nhánh và bảo vệ main. Vào Settings > Branches, bật branch protection cho nhánh main: bắt buộc mọi thay đổi phải qua Pull Request, và PR chỉ merge được khi pipeline CI xanh. Đây là điều kiện tiên quyết — không có nó, CI chỉ là trang trí.

Bước 2 — Tạo file workflow. Tạo .github/workflows/ci.yml:

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

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'          # cache dependencies cho nhanh

      - name: Install
        run: npm ci             # cài đúng theo lock file, tái lập được

      - name: Lint
        run: npm run lint

      - name: Build
        run: npm run build

      - name: Unit tests
        run: npm test -- --coverage

Bước 3 — Kích hoạt đúng sự kiện. Chú ý on: chạy pipeline cho cả pull_request (chặn merge code lỗi) và push vào main (bắt lỗi sau khi gộp). Đây là hai lớp lưới an toàn.

Bước 4 — Đảm bảo tính tái lập (reproducibility). Dùng npm ci thay vì npm install; ghim phiên bản runtime (node-version: '20'); dùng lock file. Mục tiêu: pipeline chạy trên máy CI cho kết quả giống hệt máy lập trình viên — tránh cảnh "trên máy tôi chạy được mà".

Bước 5 — Thêm integration test tách luồng (nếu cần dịch vụ phụ). Dùng services: để bật một database tạm trong lúc test:

      - name: Integration tests
        run: npm run test:integration
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
        ports: [ '5432:5432' ]

Bước 6 — Đóng gói artifact. Ở chặng cuối (chỉ chạy khi push vào main), build một Docker image và đẩy lên registry, gắn tag theo commit SHA. Đây là bàn giao sang Bài 45.

Bước 7 — Hiển thị trạng thái. Gắn badge trạng thái CI vào README và bật thông báo (Slack/Telegram) khi build đỏ, để cả đội thấy ngay và ưu tiên sửa.

Lỗi thường gặp & mẹo

• Nhánh feature sống quá lâu. Đây là lỗi giết CI nguy hiểm nhất. Bạn có công cụ xịn nhưng ôm nhánh hai tuần thì vẫn là integration hell. Mẹo: giới hạn nhánh dưới 1–2 ngày; chia tính năng lớn thành nhiều PR nhỏ; kết hợp feature flags (Bài 46) để merge code chưa hoàn thiện một cách an toàn.

• Flaky tests (test chập chờn). Test lúc xanh lúc đỏ dù code không đổi — thường do phụ thuộc thời gian, thứ tự chạy, hay tài nguyên chung. Flaky test cực kỳ độc hại vì nó giết niềm tin vào build xanh: lập trình viên bắt đầu bấm "re-run" một cách vô thức và bỏ qua cả lỗi thật. Mẹo: cô lập và sửa hoặc cách ly (quarantine) ngay test chập chờn, đừng để nó nằm trong luồng chặn-merge.

• Pipeline quá chậm. Như ví dụ 2. Mẹo: cache dependencies, chạy test song song, tách unit/integration, chỉ chạy test liên quan tới file thay đổi (test selection). Đặt ngân sách thời gian rõ ràng cho pipeline PR.

• Bỏ qua build đỏ (broken window). Khi main đỏ mà đội tặc lưỡi "kệ, do flaky thôi", văn hóa CI sụp đổ. Mẹo: thiết lập kỷ luật "main đỏ là ưu tiên số một"; cân nhắc chặn merge khi main đang đỏ.

• Test không đáng tin nhưng vẫn xanh. Test viết cho có, không thực sự kiểm tra gì (assert luôn đúng). Mẹo: theo dõi coverage nhưng đừng thờ nó như thần tượng; ưu tiên test có ý nghĩa; dùng mutation testing để kiểm tra chất lượng test.

• Nhét secret vào pipeline sai cách. Đừng hardcode mật khẩu/API key trong file YAML. Mẹo: dùng cơ chế secrets của CI (GitHub Secrets, Vault — sẽ học ở Bài 40).

• Đặt quá nhiều thứ vào cổng chặn-merge. Deploy staging, e2e test nặng, security scan đầy đủ — nếu nhét hết vào PR, không ai làm việc nổi. Mẹo: cổng chặn-merge chỉ giữ thứ nhanh và cốt lõi; đẩy phần nặng sang luồng post-merge hoặc nightly.

Bài tập thực hành

• Dựng pipeline tối thiểu. Lấy một dự án nhỏ bất kỳ của bạn (Node/Python/Go/PHP tùy chọn), tạo file workflow GitHub Actions chạy đủ 3 chặng: install → lint → unit test. Push một commit và quan sát pipeline chạy. Sau đó cố tình đẩy một commit làm test fail, xác nhận pipeline báo đỏ và (nếu đã bật branch protection) chặn merge.

• Đo và tối ưu tốc độ. Ghi lại thời gian pipeline hiện tại. Thêm cache dependencies, đo lại. Viết một đoạn ngắn: bạn tiết kiệm được bao nhiêu giây, và với tần suất push của đội thì mỗi tuần tiết kiệm bao nhiêu phút chờ đợi.

• Tình huống phân tích. Đội của bạn có pipeline chạy 22 phút, lập trình viên bắt đầu gom nhiều thay đổi để đỡ chờ, số conflict tăng. Hãy viết một kế hoạch 5 gạch đầu dòng để đưa pipeline chặn-merge xuống dưới 8 phút mà vẫn giữ được độ tin cậy. Nêu rõ test nào tách sang luồng nào.

• Thêm integration test. Mở rộng pipeline ở bài 1 để bật một database tạm (dùng services:) và chạy một integration test đơn giản (ví dụ: ghi rồi đọc một bản ghi). Quan sát pipeline chậm lại bao nhiêu và suy nghĩ nên đặt test này ở luồng nào.

Tóm tắt

• Continuous Integration là thực hành merge code vào nhánh chung thường xuyên (≥ mỗi ngày), mỗi lần merge đều tự động build và tự động test. CI trước hết là thói quen của con người, công cụ chỉ là phương tiện.
• CI sinh ra để diệt integration hell: merge nhỏ và thường xuyên khiến mỗi lần gộp code gần như không đau, thay vì một sự kiện khủng khiếp hai tuần một lần.
• Một pipeline CI đi qua các chặng: checkout → build → unit test → lint → integration test → đóng gói artifact. Nguyên tắc fail fast: chặng nào lỗi thì dừng và báo đỏ ngay.
• Tốc độ phản hồi là tính mạng của CI: giữ pipeline chặn-merge dưới ~10 phút (lý tưởng < 5). Pipeline chậm sẽ bị lập trình viên né tránh và tự phá vỡ tinh thần CI.
• Build xanh là hợp đồng niềm tin: nó phải thực sự có nghĩa là "code an toàn". Vì thế phải diệt flaky test, không dung túng main đỏ, và viết test có ý nghĩa.
• Các kẻ thù lớn nhất: nhánh sống quá lâu, test chập chờn, pipeline chậm, và văn hóa tặc lưỡi bỏ qua build đỏ.
• CI dừng ở "build được, test pass, đóng gói xong". Việc đưa artifact lên môi trường chạy là Continuous Deployment ở Bài 45.