18、持续交付、部署与分支模型：基础设施变更管理的最佳实践

持续交付、部署与分支模型：基础设施变更管理的最佳实践

1. 持续交付（CD）概述

持续交付（CD）是在交付管道中增加了一个步骤，即在单元测试通过后，将基础设施配置部署到测试环境进行集成或端到端测试。具体来说，当有人将更改推送到源代码控制时，管道工作流会在测试环境中验证这些更改。一旦集成和端到端测试通过，管道可以在将更改部署到生产环境之前等待手动批准。

1.1 为何选择 CD 而非 CI

CD 整合了之前编写的所有自动化测试，并且其交付管道将测试作为质量关卡。团队成员在审查更改时，会更有信心判断测试是否验证了更改的实现。

1.2 CD 的问题与解决办法

CD 应该涉及对代码进行小而频繁的更改，并自动推送到测试环境，在推送到生产环境之前等待手动批准。然而，等待手动批准的更改会像交通堵塞一样累积。手动批准步骤会累积一批更改，可能会引入一些问题，例如当将大量更改推送到生产环境时，系统处理和部署这些更改需要时间，还可能因为某些更改冲突而导致意外失败，团队可能需要花费数天时间来排查是哪些更改组合导致了失败。

为了缓解手动批准带来的风险，可以采取以下措施：
- 尽快批准更改，实施更短的手动批准反馈周期。
- 限制一次批准的更改数量。

2. 持续部署

持续部署是指在测试环境通过后，自动将更改部署到生产环境，移除了手动批准步骤。要实现持续部署，必须对测试有足够的信心，因为这意味着管道需要添加更多的集成和端到端测试来验证系统。

2.1 持续部署的优势

自动部署可以防止更改积压。基础设施更改通常需要数小时，并且可能影响未知的依赖