Continuous Integration (CI) — định nghĩa, nguyên tắc và thiết lập tự động hóa

Continuous Integration là gì

Continuous Integration (CI) là một phương pháp phát triển tự động hóa quy trình tích hợp mã từ nhiều người đóng góp vào một cơ sở mã duy nhất. Thuật ngữ này được Martin Fowler giới thiệu vào đầu những năm 2000 như một tập hợp các phương pháp để ngăn chặn “địa ngục tích hợp” — tình huống các nhà phát triển làm việc biệt lập trong nhiều tuần và khi hợp nhất các thay đổi, vô số xung đột phát sinh cần nhiều ngày để giải quyết thủ công.

Vấn đề CI giải quyết

Không có CI, một nhà phát triển hoàn thành tính năng, cố gắng hợp nhất các thay đổi của mình vào nhánh main và phát hiện ra rằng đồng nghiệp đã sửa đổi cùng các tệp tin. Giải quyết xung đột mất hàng giờ và thường làm hỏng mã đang hoạt động. CI giải quyết vấn đề này bằng cách bắt buộc tích hợp nhiều lần trong ngày: tích hợp càng thường xuyên thì càng ít xung đột và càng dễ giải quyết. Thực tế cho thấy với tích hợp hàng ngày, giải quyết xung đột mất vài phút, trong khi với tích hợp hàng tuần mất hàng giờ.

Tác động kinh tế của CI

Theo IBM Systems Sciences Institute, chi phí sửa lỗi ở giai đoạn viết mã là 25 đô la, ở giai đoạn kiểm thử là 100 đô la và ở giai đoạn sản xuất là 2.500 đô la. CI dịch chuyển việc phát hiện lỗi càng xa về bên trái càng tốt (shift left), tìm ra lỗi ở giai đoạn commit khi việc sửa chữa gần như miễn phí. Các nhóm sử dụng CI dành trung bình 15% thời gian cho việc gỡ lỗi, so với 35% ở nhóm không sử dụng CI.

Nguyên tắc cơ bản của Continuous Integration

Martin Fowler đã xác định các phương pháp chính của CI luôn phù hợp bất kể công nghệ sử dụng. Tuân thủ các nguyên tắc này đảm bảo CI mang lại giá trị thay vì trở thành gánh nặng hành chính. Phát triển di động đặt ra các yêu cầu bổ sung, nhưng phần cốt lõi vẫn không thay đổi.

Kho lưu trữ duy nhất

Tất cả mã của dự án được lưu trữ trong một kho lưu trữ duy nhất với hệ thống kiểm soát phiên bản thống nhất (Git). Một nguồn sự thật duy nhất loại bỏ tình huống một tính năng được phát triển trong fork và không được đồng bộ hóa với cơ sở mã chính trong nhiều tuần. Trong các dự án di động, điều này có nghĩa là các phần Android, iOS và backend có thể nằm trong một kho lưu trữ (monorepo) hoặc trong các kho lưu trữ riêng biệt với sơ đồ phiên bản dùng chung.

Build tự động

Build dự án phải thực thi được bằng một lệnh duy nhất. Đối với Android là ./gradlew assembleDebug, đối với iOS — xcodebuild hoặc fastlane build. Tập lệnh build xác minh tính tái tạo: build trên máy chủ CI phải cho kết quả giống như trên máy của nhà phát triển. Mọi khác biệt về môi trường được loại bỏ thông qua container hóa hoặc IaC (Infrastructure as Code).

Kiểm thử tự động

Sau khi build, tất cả các cấp độ kiểm thử được thực hiện: đơn vị, tích hợp và UI. Nếu kiểm thử thất bại, commit được coi là không hợp lệ. Duy trì trạng thái xanh là trách nhiệm chung của cả nhóm. Trong các dự án di động, kiểm thử nhanh (thực thi trong vòng 5 phút mỗi commit) thường được tách khỏi kiểm thử chậm (kiểm thử UI trên thiết bị thực, chạy ít thường xuyên hơn).

// Ví dụ kiểm thử đơn vị với báo cáo thân thiện với CI
class LoginViewModelTest {

    private val repository = mock<AuthRepository>()
    private val viewModel = LoginViewModel(repository)

    @Test
    fun loginWithValidCredentials_success() {
        val email = "test@example.com"
        val password = "ValidPass123"

        whenever(repository.login(email, password))
            .thenReturn(Result.success(User("token-xyz")))

        val result = viewModel.login(email, password)

        assertEquals(LoginState.Success, result)
        verify(repository).login(email, password)
    }
}

Fail fast và minh bạch

Kết quả CI được công khai cho toàn bộ nhóm: mọi người đều thấy commit nào đã làm hỏng build. Minh bạch tạo ra văn hóa trách nhiệm: các nhà phát triển kiểm tra thay đổi của họ trước khi push và sửa build hỏng ngoài lượt. Máy chủ CI gửi thông báo đến Slack hoặc Telegram khi trạng thái build thay đổi.

Các thành phần của hệ thống CI

Một hệ thống CI hoàn chỉnh bao gồm nhiều thành phần tương tác với nhau. Mỗi thành phần chịu trách nhiệm cho phần của mình trong pipeline: từ kích hoạt đến báo cáo. Hiểu kiến trúc CI giúp chẩn đoán sự cố và tối ưu hiệu suất.

Máy chủ CI

Thành phần trung tâm quản lý hàng đợi build, phân bổ tài nguyên và xuất bản kết quả. Máy chủ CI có thể dựa trên đám mây (GitHub Actions, GitLab CI, CircleCI) hoặc tự lưu trữ (Jenkins, TeamCity). Máy chủ theo dõi các thay đổi trong kho lưu trữ qua webhook hoặc polling và kích hoạt pipeline mỗi lần push hoặc pull request.

Runner và tác nhân

Runner là máy ảo hoặc vật lý thực hiện các tác vụ build. Trong CI đám mây, runner được nhà cung cấp cung cấp và tính phí theo thời gian sử dụng. Runner tự lưu trữ được cài đặt trên cơ sở hạ tầng của riêng bạn và yêu cầu bảo trì. Build iOS yêu cầu runner macOS, build Android yêu cầu Linux hoặc Windows.

Các tạo phẩm và bộ nhớ đệm

Sau khi build, hệ thống CI lưu trữ các tạo phẩm (APK, IPA, báo cáo kiểm thử) vào kho — chúng có sẵn để tải xuống và triển khai. Lưu đệm phụ thuộc (bộ nhớ đệm Gradle, bộ nhớ đệm CocoaPods) giữa các lần chạy tăng tốc các build tiếp theo lên 3–5 lần.

Continuous Integration cho ứng dụng di động

Phát triển di động có các yêu cầu đặc biệt đối với CI khác với các dự án web hoặc backend. Thời gian build dài (3–15 phút cho Android, 5–20 phút cho iOS), nhiều loại tạo phẩm (APK, AAB, IPA), nhu cầu ký mã và làm rối — tất cả đều yêu cầu cấu hình pipeline CI tùy chỉnh.

Pipeline CI cho Android

CI điển hình cho Android bao gồm: linting (ktlint, detekt) và phân tích tĩnh, kiểm thử đơn vị với JUnit và MockK, build APK/AAB debug và release, kiểm thử thiết bị trên trình giả lập trong CI và xuất bản tạo phẩm. Bộ nhớ đệm Gradle tăng tốc các build lặp lại — nếu không có nó, mỗi build tải lại phụ thuộc từ đầu, mất 3–5 phút.

Pipeline CI cho iOS

CI cho iOS yêu cầu runner macOS để biên dịch mã Swift/Objective-C. Pipeline bao gồm: cài đặt phụ thuộc CocoaPods hoặc SPM, SwiftLint để kiểm tra phong cách, kiểm thử đơn vị với XCTest, build IPA, ký mã qua Fastlane match và tải lên TestFlight. Runner tự lưu trữ trên Mac mini hoặc Mac trong trung tâm dữ liệu là giải pháp thay thế cho runner macOS đám mây.

Dự án đa nền tảng (Flutter, React Native)

Flutter và React Native biên dịch thành build gốc cho cả hai nền tảng. CI phải hỗ trợ hai runner: Linux cho build Android và macOS cho build iOS. Chiến lược tối ưu là pipeline phân chia: build Android trên runner Linux, build iOS trên runner macOS, sau đó cả hai tạo phẩm được kết hợp thành một bản phát hành duy nhất.

So sánh các công cụ CI

Việc chọn công cụ CI phụ thuộc vào quy mô nhóm, hiệu suất yêu cầu, ngân sách và công nghệ sử dụng. Dưới đây là so sánh các giải pháp phổ biến với trọng tâm là phát triển di động. Giải pháp tự lưu trữ mang lại quyền kiểm soát nhưng yêu cầu quản trị; giải pháp đám mây mang lại sự tiện lợi nhưng hạn chế cấu hình.

GitHub Actions

Miễn phí cho kho lưu trữ công khai (2000 phút/tháng). GitHub Actions cung cấp hệ sinh thái các hành động có sẵn cho Android (gradle/actions) và iOS (apple-actions). Nhược điểm là runner macOS chỉ khả dụng trong các gói trả phí. Lý tưởng cho mã nguồn mở và nhóm nhỏ đã sử dụng GitHub.

Jenkins

Máy chủ CI tự lưu trữ mã nguồn mở. Jenkins được cấu hình qua Groovy Pipeline, hỗ trợ hàng trăm plugin và chạy trên mọi phần cứng. Yêu cầu kỹ sư DevOps để cài đặt và bảo trì. Phổ biến trong phân khúc doanh nghiệp nơi việc kiểm soát cơ sở hạ tầng là quan trọng.

GitLab CI

CI/CD tích hợp trong GitLab với kiến trúc runner mở. GitLab CI cho phép sử dụng runner riêng (bao gồm macOS) trong gói miễn phí. Cấu hình YAML mạnh hơn GitHub Actions nhưng khó học hơn. Phù hợp cho nhóm sử dụng GitLab làm nền tảng DevOps duy nhất.

CircleCI

CI đám mây tập trung vào tốc độ. CircleCI hỗ trợ hình ảnh Docker, macOS và Android, tự động lưu đệm phụ thuộc. Giá dựa trên tín chỉ — đắt hơn GitHub Actions cho nhóm nhỏ nhưng nhanh hơn nhờ runner được tối ưu hóa. Được khuyến nghị cho các dự án sản xuất có yêu cầu về tốc độ.

Ví dụ thiết lập CI

Hãy xem xét thiết lập CI cho một dự án Android sử dụng GitHub Actions. Pipeline thực hiện phân tích tĩnh, build và kiểm thử mỗi lần push và pull request vào nhánh main. Cấu hình tối thiểu mất 15 phút và không yêu cầu dịch vụ bên ngoài.

name: Android CI
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - run: ./gradlew ktlintCheck detekt

  unit-tests:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew testDebugUnitTest
      - uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/tests/

Pipeline bao gồm hai công việc song song: lint (thực hiện phân tích tĩnh) và unit-tests (phụ thuộc vào lint — nếu linting thất bại, kiểm thử không chạy). Công việc unit-tests tải báo cáo kiểm thử lên như một tạo phẩm — nhóm có thể xem lại trong giao diện GitHub Actions mà không cần tải tệp xuống cục bộ.

Kiểm tra cục bộ trước CI

Để tránh lỗi CI do các lỗi nhỏ, hãy thiết lập hook pre-push trong Git hoặc tác vụ Gradle chạy cùng các kiểm tra đó cục bộ. Ví dụ: ./gradlew ktlintCheck detekt testDebugUnitTest. Nếu kiểm tra cục bộ mất hơn 3 phút, hãy chia chúng thành nhanh (linter) và chậm (kiểm thử), chạy kiểm tra nhanh trước mỗi commit và kiểm tra chậm chỉ trước khi push.