CI/CD Pipeline — 是什么、自动化阶段和工具

什么是 CI/CD Pipeline

CI/CD Pipeline — 是代码从提交到生产环境所经历的正式化和自动化的过程集。这个术语融合了两种实践：Continuous Integration（持续集成）和 Continuous Delivery（持续交付），它们共同构成了软件交付管道。

CI/CD 的发展历史

Continuous Integration 的概念由 Grady Booch 于 1991 年提出，并由 Martin Fowler 在 2000 年代彼及广泛传播。「Continuous Delivery」这一术语在 Jez Humble 和 David Farley 的《Continuous Delivery》（2010）一书之后得到确立。现代 CI/CD Pipeline 在 2015 年之后成为移动应用开发的事实标准——随着云 CI 服务器和应用商店自动化的出现。

为什么移动开发需要 CI/CD Pipeline

移动应用对构建和发布有 特殊要求：使用证书签名、多种配置（debug、release、staging）、ProGuard/R8 混淆、多种构建类型（APK、AAB、IPA）以及与应用商店的集成。手动执行这些步骤需要数小时并且容易出错——CI/CD Pipeline 自动化了常规任务。

移动应用的 CI/CD Pipeline 阶段

标准的 CI/CD Pipeline 针对 Android 或 iOS 应用包含七个关键阶段。某些阶段并行执行，其他的按顺序执行。具体的阶段组成取决于技术栈和团队的成熟度，但核心保持不变。

1. 检出和安装依赖

管道从克隆仓库和安装依赖开始：Android 用 Gradle/Maven，iOS 用 CocoaPods 或 SPM。依赖缓存 可以将安装时间从 3–5 分钟缩短到几秒——所有现代 CI 服务都支持这种优化。

2. 静态分析和代码检查

在构建之前，代码由 Linter（Android 用 ktlint、detekt，iOS 用 SwiftLint）和静态分析器（Android Lint、SonarQube）检查。代码检查 在运行测试之前发现潜在错误、代码风格违规和已废弃的 API—— fail-fast 原则节省团队时间。

3. 构建项目

在构建阶段，整个项目被编译并生成产物：Android 的 APK 和 AAB，iOS 的 IPA。Android 使用 Gradle 任务（assembleDebug、bundleRelease），iOS 使用 xcodebuild 或 xcrun。构建在 CI 服务器的隔离环境中进行，保证可重复性。

# GitHub Actions 上的 Android CI/CD Pipeline 示例
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. 自动测试

构建后运行单元测试、集成测试和 UI 测试。JUnit 和 MockK 用于模块测试，Espresso 和 Compose Test 用于 Android UI，XCTest 和 XCUITest 用于 iOS。结果发布在报告中，如果关键测试失败，则阻塞管道。

5. 签名和混淆

对于发布构建，执行数字证书签名（Android 用 APK Signer，iOS 用 codesign）和代码混淆。ProGuard 或 R8 可以将 Android 的 APK 大小减少 15–30%。签名密钥存储在 CI 服务器的机密中——从不提交到仓库。

6. 交付和部署

管道的最后阶段——发布产物：将 APK 上传到 Google Play Console 内部测试，将 IPA 发送到 TestFlight 或在 Firebase Distribution 中发布。Continuous Delivery 意味着这一步需要手动确认，而 Continuous Deployment 自动执行。

7. 通知和报告

管道完成后，团队收到带有结果的通知：成功/失败、执行时间、产物链接。Slack、Telegram 或电子邮件——根据团队需要选择通知渠道。如果阶段失败，通知中包含特定错误日志的链接。

CI 和 CD 的区别

CI 和 CD 这两个术语常常被用作一个概念 CI/CD，但它们之间存在根本区别。CI（Continuous Integration）负责每次代码集成时的质量检查，而 CD（Continuous Delivery）确保代码可以发布。理解这个差异对于设计管道至关重要。

Continuous Integration — 质量控制

CI 在每次提交或合并请求时执行，包括构建、静态分析和测试。CI 的目标 — 尽早发现问题，在修复成本最低时。如果 CI 失败——代码不能进入主分支。移动项目 CI 的平均执行时间为 5–15 分钟。

Continuous Delivery — 发布准备

CD 在 CI 的基础上添加了发布准备阶段：签名、混淆、创建发布说明、检查许可证、在测试仓库中发布。CD 保证主分支中的每次提交都可以通过一次点击部署到生产环境，但发布本身需要手动批准。

构建 CI/CD Pipeline 的工具

移动应用开发的 CI/CD 工具 生态系统包括云服务、self-hosted 解决方案和专业平台。工具的选择取决于团队规模、预算和安全要求。以下是最受欢迎的选项。

GitHub Actions

GitHub 内置的 CI/CD，对公开仓库每月 2000 分钟免费限额。GitHub Actions 凭借其庞大的已有 Action 生态系统（市场）、通过 YAML 简单配置以及与 GitHub 仓库无缝集成而受欢迎。局限——免费计划不支持用于 iOS 构建的 Windows Runner。

GitLab CI/CD

Self-hosted 和云解决方案，具有强大的 YAML 配置器。GitLab CI 支持并行任务、缓存、产物和环境。在企业级市场中受欢迎，因为可以部署到自己的基础设施并完全控制数据。

Jenkins

经典开源 CI 服务器。Jenkins 通过插件（超过 1800 个）配置，支持 Groovy 格式的 Declarative Pipeline，在 Windows、macOS、Linux 环境中都可运行。需要专门的管理，但提供最大的配置灵活性。

CircleCI

以速度和简单性为重点的云 CI 服务。CircleCI 自动缓存依赖，支持 Docker 镜像用于隔离构建，并与 macOS 集成用于 iOS 构建。价格基于信用积分——适合重视性能的团队。

CI/CD Pipeline 配置示例

让我们来看一个使用 GitHub Actions 和 Fastlane 的 iOS 应用的完整 CI/CD Pipeline。Fastlane 是移动项目的自动化工具，将复杂的构建、签名和发布操作抽象为简单命令。

# Fastfile — 用于 iOS CI/CD 的 Fastlane 配置
default_platform(:ios)

platform :ios do
  desc "运行测试和 lint"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "构建发布版本并上传到 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 管理证书和配置文件，build_app 构建 IPA，pilot 将构建上传到 TestFlight。命令 fastlane release 按顺序执行所有阶段：获取证书、构建、签名、为 Beta 测试人员上传到 App Store Connect。

使用 GitHub Actions 的 iOS CI/CD Pipeline

Fastlane 与 GitHub Actions 的集成可以在向 main 分支发起 Pull Request 时自动运行完整管道。macOS 上的 self-hosted runner 对于编译 iOS 代码是必要的——GitHub 在免费计划中不提供 macOS Runner。

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 }}

CI/CD Pipeline 最佳实践

构建高效的 CI/CD Pipeline 不仅需要选择工具，还需要遵循被证明的实践。如果组织不当，管道可能成为瓶颈，减慢开发而非加快开发。以下是基于成熟移动团队经验的关键建议。

Fail fast

最快的检查（代码检查、单元测试）先执行。如果失败——管道结束，不会运行长时间 UI 测试或发布构建。Fail fast 节省 CI 时间并加快对开发人员的反馈。首次失败的平均时间不应超过 2–3 分钟。

依赖缓存

Gradle 缓存、CocoaPods 缓存和 SPM 缓存应在运行之间恢复。GitHub Actions 通过 actions/cache 支持缓存，GitLab CI 通过 cache 关键词支持。没有缓存，每次构建都会重新下载所有依赖——这会增加 3–10 分钟的管道时间。

并行执行

独立阶段（Android 和 iOS 的 Linter、不同模块的单元测试）作为并行任务运行。并行化 将管道总时间从 20–30 分钟减少到 5–10 分钟。多数 CI 服务单独计算并行任务——选择计费方案时请考虑这一点。

环境隔离

每次管道运行在干净的环境中进行：Docker 容器、虚拟机或临时 Runner。隔离 防止之前的构建影响当前构建。避免在项目之间使用共享 Runner——跨项目环境污染会导致非确定性故障。

机密安全

API 密钥、签名证书和应用商店访问令牌存储在 CI 服务器的加密仓库中。如果没有SECRET_ 前缀，切勿将机密包含在日志、产物或环境变量中。使用 Fastlane match 等工具管理 iOS 证书。