CI/CD Pipeline — nó là gì, các giai đoạn tự động hóa và công cụ

CI/CD Pipeline là gì

CI/CD Pipeline là một tập hợp các quy trình được chính thức hóa và tự động hóa mà mã nguồn trải qua từ khi commit thay đổi vào kho lưu trữ đến khi triển khai lên môi trường sản xuất. Thuật ngữ này kết hợp hai thực hành: Continuous Integration (tích hợp liên tục) và Continuous Delivery (phân phối liên tục), cùng nhau tạo thành một pipeline phân phối phần mềm.

Lịch sử của CI/CD

Khái niệm Continuous Integration được Grady Booch mô tả vào năm 1991 và được Martin Fowler phổ biến vào những năm 2000. Continuous Delivery như một thuật ngữ được thiết lập sau cuốn sách “Continuous Delivery” của Jez Humble và David Farley (2010). CI/CD Pipeline hiện đại đã trở thành tiêu chuẩn thực tế trong phát triển di động sau năm 2015 — với sự ra đời của máy chủ CI đám mây và tự động hóa cửa hàng ứng dụng.

Tại sao cần CI/CD Pipeline trong phát triển di động

Các ứng dụng di động có yêu cầu cụ thể về xây dựng và xuất bản: ký chứng chỉ, nhiều cấu hình (debug, release, staging), làm rối ProGuard/R8, nhiều loại bản build (APK, AAB, IPA) và tích hợp với các cửa hàng ứng dụng. Thực hiện thủ công các bước này mất hàng giờ và dễ xảy ra lỗi — CI/CD Pipeline tự động hóa các công việc thường nhật.

Các giai đoạn CI/CD Pipeline cho ứng dụng di động

Một CI/CD Pipeline tiêu chuẩn cho ứng dụng Android hoặc iOS bao gồm bảy giai đoạn chính. Một số giai đoạn chạy song song, số khác chạy tuần tự. Tập hợp các giai đoạn chính xác phụ thuộc vào công nghệ và độ trưởng thành của nhóm, nhưng phần lõi vẫn giữ nguyên.

1. Checkout và cài đặt phụ thuộc

Pipeline bắt đầu bằng việc sao chép kho lưu trữ và cài đặt các phụ thuộc: Gradle/Maven cho Android, CocoaPods hoặc SPM cho iOS. Lưu đệm phụ thuộc giữa các lần chạy giảm thời gian cài đặt từ 3–5 phút xuống còn vài giây — tất cả các dịch vụ CI hiện đại đều hỗ trợ tối ưu hóa này.

2. Phân tích tĩnh và linting

Trước khi xây dựng, mã nguồn được kiểm tra bởi các công cụ lint (ktlint, detekt cho Android, SwiftLint cho iOS) và các bộ phân tích tĩnh (Android Lint, SonarQube). Linting phát hiện các lỗi tiềm ẩn, vi phạm phong cách mã và API không còn được dùng trước khi chạy kiểm thử — nguyên tắc fail-fast tiết kiệm thời gian cho nhóm.

3. Xây dựng dự án

Ở giai đoạn xây dựng, toàn bộ dự án được biên dịch và tạo ra các tạo phẩm: APK và AAB cho Android, IPA cho iOS. Android sử dụng các tác vụ Gradle (assembleDebug, bundleRelease), iOS sử dụng xcodebuild hoặc xcrun. Bản build được thực thi trong môi trường biệt lập của máy chủ CI, đảm bảo tính tái tạo.

# Ví dụ về CI/CD Pipeline cho Android trên GitHub Actions
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. Kiểm thử tự động

Sau khi xây dựng, các kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử giao diện được chạy. JUnit và MockK cho kiểm thử đơn vị, Espresso và Compose Test cho giao diện Android, XCTest và XCUITest trên iOS. Kết quả được xuất bản trong báo cáo và chặn pipeline nếu kiểm thử quan trọng thất bại.

5. Ký và làm rối

Đối với bản build phát hành, việc ký chứng chỉ số (APK Signer cho Android, codesign cho iOS) và làm rối mã được thực hiện. ProGuard hoặc R8 cho Android giảm kích thước APK từ 15–30%. Khóa ký được lưu trữ trong bí mật của máy chủ CI — không bao giờ được commit vào kho lưu trữ.

6. Phân phối và triển khai

Giai đoạn cuối cùng của pipeline là xuất bản tạo phẩm: tải APK lên Google Play Console để kiểm thử nội bộ, gửi IPA lên TestFlight hoặc xuất bản lên Firebase Distribution. Continuous Delivery có nghĩa là bước này yêu cầu phê duyệt thủ công, trong khi Continuous Deployment chạy tự động.

7. Thông báo và báo cáo

Sau khi pipeline hoàn thành, nhóm nhận được thông báo kết quả: thành công/thất bại, thời gian thực thi, liên kết đến tạo phẩm. Slack, Telegram hoặc email — các kênh thông báo được chọn theo nhu cầu của nhóm. Khi một giai đoạn thất bại, thông báo bao gồm liên kết đến nhật ký lỗi cụ thể.

Sự khác biệt giữa CI và CD

Các thuật ngữ CI và CD thường được sử dụng như một khái niệm duy nhất CI/CD, nhưng có sự khác biệt cơ bản giữa chúng. CI (Continuous Integration) chịu trách nhiệm kiểm tra chất lượng ở mỗi lần tích hợp mã, trong khi CD (Continuous Delivery) đảm bảo mã nguồn sẵn sàng cho phát hành. Hiểu được sự khác biệt là rất quan trọng khi thiết kế pipeline.

Continuous Integration — kiểm tra chất lượng

CI chạy ở mọi push hoặc pull request và bao gồm xây dựng, phân tích tĩnh và kiểm thử. Mục tiêu của CI là phát hiện vấn đề càng sớm càng tốt, khi chi phí sửa chữa là tối thiểu. Nếu CI thất bại — mã nguồn không vào được nhánh chính. Thời gian thực thi CI trung bình cho một dự án di động là 5–15 phút.

Continuous Delivery — sẵn sàng phát hành

CD thêm vào CI các giai đoạn chuẩn bị phát hành: ký, làm rối, tạo ghi chú phát hành, kiểm tra giấy phép, xuất bản lên kho lưu trữ cho người kiểm thử. CD đảm bảo rằng bất kỳ commit nào trong nhánh chính đều có thể được đưa lên sản xuất bằng một cú nhấp chuột, nhưng bản phát hành yêu cầu phê duyệt thủ công.

Công cụ xây dựng CI/CD Pipeline

Hệ sinh thái công cụ CI/CD cho phát triển di động bao gồm các dịch vụ đám mây, giải pháp tự lưu trữ và nền tảng chuyên biệt. Việc chọn công cụ phụ thuộc vào quy mô nhóm, ngân sách và yêu cầu bảo mật. Dưới đây là các tùy chọn phổ biến nhất.

GitHub Actions

CI/CD tích hợp trong GitHub với giới hạn miễn phí 2000 phút mỗi tháng cho kho lưu trữ công khai. GitHub Actions phổ biến nhờ hệ sinh thái khổng lồ các hành động có sẵn (marketplace), cấu hình dễ dàng qua YAML và tích hợp liền mạch với kho lưu trữ GitHub. Hạn chế — không hỗ trợ trình chạy Windows cho bản build iOS trong gói miễn phí.

GitLab CI/CD

Giải pháp tự lưu trữ và đám mây với trình cấu hình YAML mạnh mẽ. GitLab CI hỗ trợ công việc song song, lưu đệm, tạo phẩm và môi trường. Phổ biến trong phân khúc doanh nghiệp nhờ khả năng triển khai trên cơ sở hạ tầng riêng và kiểm soát dữ liệu hoàn toàn.

Jenkins

Máy chủ CI mã nguồn mở cổ điển. Jenkins được cấu hình thông qua plugin (hơn 1800), hỗ trợ Declarative Pipeline ở định dạng Groovy và chạy trên mọi môi trường: Windows, macOS, Linux. Yêu cầu quản trị riêng nhưng mang lại sự linh hoạt cấu hình tối đa.

CircleCI

Dịch vụ CI đám mây tập trung vào tốc độ và đơn giản. CircleCI tự động lưu đệm các phụ thuộc, hỗ trợ hình ảnh Docker cho các bản build biệt lập và tích hợp với macOS cho bản build iOS. Giá cả dựa trên tín chỉ — phù hợp cho các nhóm coi trọng hiệu suất.

Ví dụ thiết lập CI/CD Pipeline

Hãy xem một CI/CD Pipeline hoàn chỉnh cho ứng dụng iOS sử dụng GitHub Actions và Fastlane. Fastlane là công cụ tự động hóa cho các dự án di động, trừu tượng hóa các thao tác xây dựng, ký và xuất bản phức tạp thành các lệnh đơn giản.

# Fastfile — cấu hình Fastlane cho iOS CI/CD
default_platform(:ios)

platform :ios do
  desc "Chạy kiểm thử và lint"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "Xây dựng bản phát hành và tải lên TestFlight"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match quản lý chứng chỉ và hồ sơ cấp phép, build_app xây dựng IPA, pilot tải bản build lên TestFlight. Lệnh fastlane release thực thi tất cả các giai đoạn tuần tự: lấy chứng chỉ, xây dựng, ký, tải lên App Store Connect cho người kiểm thử beta.

CI/CD Pipeline cho iOS với GitHub Actions

Tích hợp Fastlane với GitHub Actions cho phép chạy toàn bộ pipeline tự động khi có pull request vào nhánh chính. Cần một trình chạy tự lưu trữ trên macOS để biên dịch mã iOS — GitHub không cung cấp trình chạy macOS trong gói miễn phí.

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

Thực hành tốt nhất CI/CD Pipeline

Xây dựng một CI/CD Pipeline hiệu quả không chỉ đòi hỏi chọn công cụ mà còn phải tuân theo các thực hành đã được kiểm chứng. Nếu không tổ chức đúng cách, pipeline có thể trở thành nút thắt cổ chai, làm chậm phát triển thay vì tăng tốc. Dưới đây là các khuyến nghị chính dựa trên kinh nghiệm của các nhóm di động trưởng thành.

Fail fast

Các kiểm tra nhanh nhất (linting, kiểm thử đơn vị) được chạy đầu tiên. Nếu chúng thất bại — pipeline kết thúc mà không chạy kiểm thử giao diện dài hay bản build phát hành. Fail fast tiết kiệm phút thời gian CI và tăng tốc phản hồi cho nhà phát triển. Thời gian trung bình đến lần thất bại đầu tiên không được vượt quá 2–3 phút.

Lưu đệm phụ thuộc

Bộ đệm Gradle, CocoaPods và SPM cần được khôi phục giữa các lần chạy. GitHub Actions hỗ trợ lưu đệm qua actions/cache, GitLab CI qua từ khóa cache. Nếu không có lưu đệm, mỗi bản build tải lại tất cả các phụ thuộc từ đầu — thêm 3–10 phút vào thời gian pipeline.

Thực thi song song

Các giai đoạn độc lập (lint cho Android và iOS, kiểm thử đơn vị của các mô-đun khác nhau) chạy như các công việc song song. Song song hóa giảm tổng thời gian pipeline từ 20–30 phút xuống còn 5–10 phút. Hầu hết các dịch vụ CI tính phí riêng cho công việc song song — hãy ghi nhớ điều này khi chọn gói.

Cô lập môi trường

Mỗi lần chạy pipeline được thực thi trong môi trường sạch: container Docker, máy ảo hoặc trình chạy tạm thời. Cô lập ngăn các bản build trước ảnh hưởng đến bản build hiện tại. Tránh sử dụng trình chạy dùng chung giữa các dự án — ô nhiễm môi trường chéo dẫn đến lỗi không xác định.

Bảo mật bí mật

Khóa API, chứng chỉ ký và mã truy cập cửa hàng ứng dụng được lưu trữ trong kho được mã hóa của máy chủ CI. Không bao giờ đưa bí mật vào nhật ký, tạo phẩm hoặc biến môi trường mà không có tiền tố SECRET_. Sử dụng các công cụ như Fastlane match để quản lý chứng chỉ iOS.