Continuous Delivery（CD）：是什么，与 Continuous Deployment 有何区别

什么是 Continuous Delivery

Continuous Delivery (CD) — 这是 Continuous Integration 的扩展，为版本准备的所有阶段增加了自动化：构建发布版本、用证书签名、混淆、检查应用商店的元数据以及部署到 staging。该术语由 Jez Humble 和 David Farley 在《Continuous Delivery》（2010）一书中引入，他们在书中正式确立了一种实践，使团队能够将发布变得可预测且低风险。

软件交付的演进

在采用 CD 之前，发布是一个事件：团队聚集在一个房间里，完成一份 20 项的检查清单，手动运行脚本，并祈祷不会出问题。Continuous Delivery 将发布从一个事件转变为一个过程：代码的小改动可以在几分钟内交付给用户，而不是几周。Amazon、Netflix 和 Etsy 在 2010 年代率先采用 CD——如今这是产品团队的标准。

CD 的商业价值

快速交付功能是竞争优势。如果竞争对手在几天内发布新功能，而您需要几个月，市场会选择竞争对手。DORA 指标显示：精英团队（使用 CD）的发布时间不到 1 小时，低水平团队（不使用 CD）则需要 1 周到 1 个月。CD 还大幅降低了风险：小改动比每季度一次的大版本更难搞砸。

CD vs CI vs Continuous Deployment

CI、CD 和 Continuous Deployment 这些术语经常被混淆，但它们之间有明确的界限。理解这些差异有助于正确设计流水线，并选择符合团队成熟度和业务需求的自动化水平。

Continuous Integration

CI 是构建 CD 的基础。CI 保证每次提交都能通过构建和测试。没有 CI 就不可能实现 CD：如果代码未经验证，就不能发布。CI 检查正确性，CD 检查是否准备好投入业务使用。

Continuous Delivery

CD 在 CI 的基础上增加了准备发布版本、检查元数据、签名以及部署到 staging 或应用商店进行 beta 测试的阶段。关键区别——是否发布到生产环境由人来决定（经理、产品负责人）。CD 使发布变得「一键完成」——简单且安全。

Continuous Deployment

Continuous Deployment 是完全自动化：每个通过 CD 流水线所有阶段的变化都会在没有人工确认的情况下自动发送到生产环境。Continuous Deployment 适用于 SaaS 产品和 Web 服务，但在移动开发中很少使用，因为应用商店的政策（App Store Review、Google Play Review 需要手动提交）。

移动应用的 Continuous Delivery

移动应用的 CD 具有使其区别于 Web 和后端流水线的特点。移动版本要经过应用商店（App Store Review、Google Play Review），这增加了时间和流程上的障碍。CD 自动化了在提交审核前所有可以自动化的部分，以最大化一次通过审核的机会。

为在 Google Play 发布做准备

Android CD 流水线包括：构建 AAB（Android App Bundle）、使用发布密钥签名、通过 R8/ProGuard 混淆、检查 APK 大小和 multidex 类、生成发布说明。使用 Gradle product flavors（free/paid、dev/staging/prod）可以从一个流水线管理多个配置。

为在 App Store 发布做准备

iOS CD 需要通过 Fastlane match 使用证书签名、检查图标的合规性（App Store 要求——1024×1024 px）、验证元数据（名称、描述、关键词）、检查没有私有 API。技术验证通过 altool --validate-app 完成，无需上传到 App Store Connect，从而提供快速反馈。

# Fastfile — 面向 iOS 和 Android 的完整 CD 流水线
platform :ios do
  desc "iOS CD — 准备版本并上传到 TestFlight"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "Android CD — 构建 AAB 并上传到 Google Play Console"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

Fastlane 的 deliver_to_testflight 收集截图、通过 match 获取证书、构建 IPA 并上传到 TestFlight。面向 Android 的 deliver_to_internal lane 通过 Gradle 构建 Release AAB，并将其上传到 Google Play Console 的内部轨道。两个流水线都在测试通过后从 CI 启动。

CD 流水线的组成部分

CD 流水线 由一系列连续的阶段组成，每个阶段都增加对版本已准备好交付给用户的信心。阶段分为技术类（构建、签名）和产品类（检查元数据、截图、描述）。跳过任何一个阶段都会增加应用商店拒绝发布的风险。

版本管理

CD 的关键组成部分是自动版本管理。Version bump（Android 的 versionCode 和 versionName，iOS 的 CFBundleVersion 和 CFBundleShortVersionString）基于 Git 标签或商店中的上一个版本执行。Fastlane increment_version_number 和 Gradle 命令（versionCode auto-increment）自动化了这一步骤。

商店元数据

Google Play Console 和 App Store Connect 要求：应用描述、关键词、类别、评分、隐私政策链接。CD 包括检查元数据是否存在且正确。Fastlane deliver 和 supply 自动将描述、截图和图标与构建一起上传。

门禁检查

在提交审核之前，流水线会执行门禁检查：检查构建大小（超过 200 MB 的 APK 会被 Google Play 拒绝）、所有本地化的存在、发布构建中没有调试符号、检查 ProGuard mapping 文件以解码崩溃日志。如果任何一项检查未通过，流水线会阻止发布。

CD 的自动化测试

对 CD 的信任程度与自动化测试的质量成正比。如果测试没有捕获回归，发布可能会破坏生产环境，团队就会失去对 CD 的信心。移动 CD 需要三层测试金字塔，并根据平台特点进行适配。

单元测试

单元测试隔离地检查业务逻辑。代码覆盖率对于关键模块（身份验证、支付、网络工作）应至少达到 70%。CI 在每次推送时运行单元测试，如果测试失败，CD 流水线会被阻止直到修复。

集成测试

检查组件之间的交互：带有真实 API（或 mock 服务器）的网络层、数据库、文件系统。Android 的 Room DAO 测试、iOS 的 Core Data 测试——都是集成测试的例子。它们比单元测试慢（1–5 分钟），在 CD 阶段执行，而不是在每次提交时由 CI 执行。

UI 和截图测试

截图测试（snapshot testing）将应用的屏幕与参考图像进行比较。如果代码更改改变了 UI，测试就会失败，开发人员需要检查更改是否符合预期。Android 支持 Roborazzi 和 Paparazzi，iOS 支持 Point-Free 的 SnapshotTesting。截图测试在发布前作为 CD 流水线的一部分执行。

Continuous Delivery 的最佳实践

实施 Continuous Delivery 不仅需要工具，还需要改变团队文化。以下实践基于 Google、Spotify 和 Uber 移动团队多年的经验，并适用于任何规模的项目。

功能开关

新功能的代码被交付到生产环境，但隐藏在开关后面。Feature flags 可以在功能准备好向用户展示之前就发布代码，并在出现问题时立即禁用它。库：LaunchDarkly、Firebase Remote Config、Unleash。Feature flags 是移动项目中实现 CD 的必要条件。

Staging 环境

在发送到生产环境之前，构建会被放到 staging——一个与生产环境相同但带有测试数据的环境。QA 工程师通过 TestFlight 或 Internal Testing 轨道安装的 staging 构建来检查功能。如果 staging 通过，构建就会获得批准，可以提交到商店进行审核。

发布说明和变更日志

CD 根据提交消息自动生成发布说明。Conventional Commits（feat:、fix:、chore:）和语义化版本格式的 Git 标签可以解析变更历史。Fastlane changelog_from_git_commits 收集最后两个标签之间的更改，并为应用商店格式化它们。

发布后的监控

CD 不会在发布后结束——发布后启动监控：崩溃率、Android 的 ANR 率、启动时间、支付失败频率。如果指标超出正常范围，CD 流水线应自动回滚发布或通知团队。工具：Firebase Crashlytics、Sentry、New Relic。

// 使用 Firebase Remote Config 实现 CD 的 Feature Flag 示例
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// 在代码中使用
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}