移动开发中的 CI/CD 与自动化：是什么、如何运作以及为何需要

什么是 CI/CD？

Continuous Integration

持续集成（Continuous Integration）是移动应用 CI/CD 自动化的基础。这是一种每个开发者每天多次将代码合并到共享仓库的实践。每次推送后，CI 服务器自动构建项目并运行测试。如果测试失败，构建被视为损坏，团队立即修复问题。CI 可防止「在我的机器上能运行」的情况，即一个开发者的代码破坏了另一个开发者的代码。

构建管道（Build Pipeline） — 每次推送时执行的一系列步骤：代码检查 → 单元测试 → 调试 APK/IPA 构建 → 集成测试 → 发布构建。每个步骤只有在前一步成功后才运行。构建产物 — APK、IPA、AAB、测试报告 — 被保存并可下载。

持续交付与持续部署

持续交付（Continuous Delivery） — 代码自动构建和测试，但由人决定是否发布到生产环境。持续部署（Continuous Deployment） — 每个成功的构建自动发布到生产环境。对于移动应用，通过 TestFlight 或 Internal Testing 的 CD（交付到商店）更为常见，因为发布的最终决定由开发者或经理做出。暂存环境（Staging） — 尽可能接近生产环境的环境，用于在发布前测试构建。

GitHub Actions 和 GitLab CI

GitHub Actions

GitHub Actions 是 GitHub 上用于自动化移动应用的内置 CI/CD 系统。Actions 使用 YAML 配置（.github/workflows）来定义管道。移动开发有现成的 actions 可用：actions/setup-java、用于 Android 的 gradle-build-action、用于 iOS 的 xcodebuild-action。GitHub Actions 为私有仓库提供每月 2000 分钟的免费额度。

示例：Android 工作流包括代码检出、JDK 17 设置、Gradle 依赖缓存、运行 lint 和单元测试、APK 构建以及产物上传。对于 iOS — 检出、Xcode 设置、pod install、运行 XCTest、归档和 IPA 导出。GitHub Actions 与 GitHub Releases、Slack 和 Telegram 集成以发送通知。

GitLab CI

GitLab CI 是 GitLab 中的内置 CI/CD 系统，通过 .gitlab-ci.yml 配置。GitLab CI 使用运行器（runners）— 执行任务的代理。对于移动开发，您可以使用共享运行器（Android 用 Linux）或自己的运行器（iOS 用 macOS）。GitLab CI 支持并行作业、产物、环境以及生产发布的手动审批。

用于移动应用的 Bitrise

为什么选择 Bitrise？

Bitrise 是一个专注于移动应用自动化的 CI/CD 平台。Bitrise 为 Android、iOS、Flutter 和 React Native 提供现成的 Steps：Gradle Runner、Xcode Archive、Flutter Test、CocoaPods Install。Bitrise 自动配置 iOS 的代码签名（通过 Codesigndoc），并提供预装了 Xcode、Android SDK、Flutter 和其他工具的虚拟机。

Bitrise 的优势：通过可视化 Workflow 编辑器轻松设置、支持并行构建、与 Firebase Test Lab、App Store Connect 和 Google Play Console 集成。Bitrise 为个人项目提供每月 90 分钟的免费额度。在 IT Sectr，我们为所有移动项目使用 Bitrise — 与手动设置 GitHub Actions 相比，它显著简化了 CI/CD。

Fastlane：移动构建自动化

什么是 Fastlane？

Fastlane 是一个用 Ruby 编写的用于 iOS 和 Android 的移动应用自动化工具。Fastlane 由现成 actions 系统（超过 200 个）和通过 Fastfile 描述场景的 DSL 组成。Fastlane 解决了每个移动开发人员手动执行的任务：代码签名、截图生成、上传到 TestFlight 和 Google Play、证书和配置文件管理。

Fastlane 的关键组件

Lane — Fastfile 中的命名场景。示例：lane :release do — 发布版本的操作链。Match — 通过加密的 Git 仓库安全存储和同步证书与配置文件的工具。Gym — 构建和归档 iOS 应用（xcodebuild 的包装器）。Pilot — 在 TestFlight 中上传和管理构建。Deliver — 将应用和元数据上传到 App Store Connect。Snapshot — 自动生成所有语言的截图。Screengrab — 为 Android 自动生成截图。

Android 的 Fastfile 示例：lane :beta 调用 gradle（assembleRelease），然后调用 firebase_app_distribution 分发给测试人员。对于 iOS：lane :beta 调用 match（下载证书）、gym（归档）和 pilot（上传到 TestFlight）。Fastlane 可以在本地和 CI 服务器上运行 — 使其成为任何移动项目中的通用工具。

Canary Release 和 Feature Flags

Canary Release

Canary Release 是一种 CI/CD 自动化策略，用于在全面发布前将新版本应用推送给一小部分用户（1–5%）。在 Google Play Console 中，这通过分阶段发布（Staged Rollout）实现：您向 5% 的用户发布更新，监控崩溃和指标，如果没有问题则增加比例。在 App Store Connect 中 — 通过自动更新的分阶段发布（Phased Release for Automatic Updates）。

A/B 测试 — 在随机用户组中比较一个功能的两个版本。在移动开发中，A/B 测试通过 Feature Flags、Firebase Remote Config 或服务器端逻辑进行。Canary Release 和 A/B 测试最小化了推出新功能时的风险。

Feature Flags

Feature Flag（功能开关）— 在不部署新代码的情况下有条件地启用功能。Feature Flag 是代码中的一个检查：if (featureFlag.isEnabled()) { /* 新代码 */ } else { /* 旧代码 */ }。标志通过服务管理：LaunchDarkly、Split.io、Firebase Remote Config。Feature Flags 允许开发人员将代码合并到 main，即使该功能尚未准备好面向用户。

LaunchDarkly — 最流行的 Feature Flags 管理平台。LaunchDarkly 为 iOS、Android、Flutter 和 React Native 提供 SDK。您可以针对特定用户、细分群体、地区或一定比例的用户启用功能。Feature Flags 还用作 kill switch — 在不发布新版本应用的情况下立即禁用有问题的功能。