cicd

CI/CD 流水线模式与部署策略

持续集成、持续交付和持续部署是一系列自动化实践，彼此逐步递进，减少代码变更从提交到交付给用户之间的人工操作。

CI 与 CD 与 CD

实践	自动化内容	进入下一阶段的门槛
持续集成	在每次提交时合并、构建和测试代码	合并前必须通过自动化测试
持续交付	打包制品并将其逐步推送到各个环境	部署到生产环境前需人工批准
持续部署	打通从提交到生产环境的完整流程，无需人工操作	由自动化质量门禁取代人工批准

持续集成是基础。如果集成不够可靠、速度不够快，交付和部署都无法持续进行。从这里开始。

---

流水线设计原则

优秀的流水线能为开发者提供快速、可信的反馈，并避免有问题的代码流向用户。

原则	含义
快速反馈	先运行成本最低、速度最快的检查——先执行 lint 和单元测试，再执行集成测试和构建
尽早失败	在首次失败时停止流水线——上游检查失败时，不要在下游阶段浪费时间
可复现性	使用相同输入的每次流水线运行都必须产生相同输出——固定依赖版本，并使用不可变的基础映像
幂等性	重新运行流水线阶段应安全，并产生相同结果
隔离性	每次流水线运行都在干净的环境中执行——运行之间不共享状态
默认安全	在运行时注入密钥，绝不将其存储在源代码中——尽早扫描漏洞

---

部署策略概览

策略	停机时间	回滚速度	基础设施成本	复杂度	适用场景
蓝绿部署	零	即时（切换流量）	生产环境的 2 倍	低	重大版本发布、规避风险的团队
金丝雀发布	零	快速（将流量路由回原版本）	1 倍 + 少量金丝雀实例	中	数据驱动的团队、高流量服务
滚动部署	零（配置激增部署时）	慢（反向滚动部署）	1 倍（复用现有资源）	低	无状态服务、频繁的小型变更
重建部署	有（短暂）	慢（完整重新部署）	1 倍	最低	开发/预发布环境、无法同时运行两个版本的有状态应用
功能标志	零	即时（关闭开关）	1 倍	中	渐进式发布、A/B 测试、主干开发

没有一种策略适用于所有情况。许多团队会组合使用多种策略，例如通过金丝雀发布搭配功能标志，控制哪些用户可以看到新功能。

---

环境管理概览

典型的发布路径会将制品逐步推送到越来越接近生产环境的各个环境：

dev -> staging -> production

原则：

• 制品不可变 - 只构建一次，并在所有环境中部署同一制品。绝不要针对每个环境重新构建。
• 配置分离 - 特定于环境的值（数据库 URL、API 密钥、功能开关）应存放在制品之外。
• 环境一致性 - 预发布环境应尽可能在基础设施、数据形态和规模上与生产环境保持一致。
• 临时环境 - 针对每个拉取请求启动隔离环境，以便测试和评审；PR 关闭后再将其销毁。

---

快速参考：流水线反模式

反模式	问题	修复方法
为每个环境重新构建制品	预发布环境与生产环境使用不同的二进制文件	只构建一次，并将同一制品逐级晋级
长时间运行的单体流水线	反馈缓慢，开发者需要频繁切换上下文	并行化各阶段，将流水线拆分为专注于特定任务的多个流水线
在源代码管理中存储机密	凭据泄露，违反合规要求	使用机密管理器，在运行时注入机密
手动配置环境	配置漂移，出现“在我的机器上能运行”的问题	使用基础设施即代码和容器化构建
没有回滚计划	部署失败时导致服务中断时间延长	自动化回滚并定期测试
跳过预发布环境	直到为时已晚才发现仅在生产环境出现的错误	始终至少通过一个预生产环境逐级晋级

---

参考文件

参考资料	内容
流水线设计	流水线阶段、并行化、缓存、单体仓库模式，以及包含多种格式示例的机密管理
部署策略	蓝绿部署、金丝雀发布、滚动部署、功能标志、零停机迁移和回滚策略
环境管理	环境晋级、基础设施即代码、临时环境、制品版本管理和健康检查

---

与其他技能的集成

情况	推荐技能
部署的监控与可观测性	microservices
流水线中的安全扫描	security
CI 流水线的测试策略	testing
部署期间的 API 版本管理	api-design