4. 持续交付与持续部署
在持续集成（CI）之后，软件交付进入更关键的阶段——持续交付（Continuous Delivery）与持续部署（Continuous Deployment），二者常被统称为 CD。它们共享同一条自动化发布流水线，但在“是否自动进入生产”这一决策点上存在本质差异。理解这一差异，是设计可靠发布体系的前提。
一、核心原理：持续交付与持续部署的边界
持续交付强调：每一次通过质量门禁的变更，都具备随时可发布到生产的能力，但最终是否发布由人工决策触发。它交付的是“可发布状态”，保留业务与合规上的审批控制。持续部署则更进一步：只要变更通过全部自动化验证，就自动发布到生产环境，无需人工干预。二者的关系可以概括为：持续部署是持续交付的严格子集，前者要求后者全部能力，并额外要求极高的自动化测试覆盖与快速回滚机制。
在 SDV（软件定义汽车）场景中，车载软件受功能安全与法规约束，通常采用持续交付而非持续部署，即制品可自动构建、测试、签名，但上车发布需经过审批与灰度策略控制。
二、发布流水线设计：从提交到上线的自动化链路
一条完整的发布流水线通常包含以下阶段：代码提交触发构建 → 单元测试与静态检查 → 制品打包与版本标记 → 制品入库 → 部署到测试环境 → 集成/验收测试 → 安全与合规扫描 → 部署到预生产环境 → 生产发布（人工或自动）。每个阶段都应设置质量门禁，失败即阻断并通知责任人。
# 典型发布流水线阶段（GitLab CI 风格）
stages:
- build # 编译、单元测试
- package # 生成制品、版本号、签名
- publish # 推送至制品库
- deploy-test # 部署测试环境
- verify # 集成/验收测试
- deploy-prod # 生产发布（manual 或 auto）设计要点：阶段之间保持幂等与可重入；制品一次构建、多处部署，避免“构建一次、部署多次”带来的环境漂移；生产发布阶段应支持蓝绿或金丝雀策略。
三、环境管理与制品库管理
环境管理要求开发、测试、预生产、生产环境在配置上保持一致性，差异仅通过环境变量或配置中心注入。常见做法是使用基础设施即代码（IaC）描述环境，确保可重复创建与销毁。制品库则负责存储构建产物（如二进制、容器镜像、OTA 包），并保证版本唯一、可追溯、可签名。制品库应支持不可变存储，禁止覆盖已有版本。
| 管理对象 | 核心要求 | 常见工具/实践 |
|---|---|---|
| 环境 | 配置一致、可重复创建、隔离 | IaC、配置中心、命名空间隔离 |
| 制品库 | 版本唯一、不可变、可追溯、签名 | Nexus、Harbor、Artifactory |
| 发布策略 | 可灰度、可回滚、可观测 | 蓝绿部署、金丝雀发布 |
四、蓝绿部署与金丝雀发布：降低发布风险的两类策略
蓝绿部署维护两套完全相同的生产环境（蓝与绿），当前流量指向蓝，新版本部署到绿并验证通过后，通过负载均衡一次性切换流量到绿。优点是切换快、回滚简单（切回蓝即可）；缺点是资源成本翻倍。金丝雀发布则先将新版本发布给一小部分用户或节点（如 5% 流量），观察指标正常后逐步扩大比例，直至全量。优点是风险可控、资源占用低；缺点是需要精细的流量治理与监控能力。
五、案例与误区复盘
某车企 OTA 平台最初采用“全量直接发布”，一次版本缺陷导致大量车辆功能异常，回滚耗时数小时。复盘后引入制品库版本锁定、预生产环境验证与金丝雀发布策略，将发布风险显著降低。常见误区包括：把持续交付等同于持续部署、制品库允许覆盖旧版本、环境配置靠手工维护、发布后缺乏可观测指标。避免这些误区，才能让 CD 真正成为稳定交付的基石。