如何设计出优秀的CI/CD 部署流水线？

关注我，每天收获一个新技能!

部署流水线（Deployment Pipeline）是持续交付1.0中的核心模式。

它是对软件交付过程的一种可视化呈现方式，展现了从代码提交、构建、部署、测试到发布的整个过程，为团队提供状态可视化和即时反馈。

虽然部署流水线的设计因受到软件架构、分支策略、团队结构以及产品形态的影响，每个产品的部署流水线均有所不同，

但是，其都有一个共同点，就是在每个节点的出口，都有一个质量门禁。而质量门禁正是反馈的关键。如果没有高质量的门禁，则无法形成反馈环。

本章将重点介绍产品团队设计和使用部署流水线的基本原则，以及企业开发部署流水线平台工具链时，需要构建的平台能力要求，以及相关子系统的服务逻辑架构。

下面内容来自于畅销书《持续交付2.0》一书的第七章。

1．一次构建，多次使用

当某个部署流水线的一次运行实例构建出制品（如二进制软件包），如果需要，它就应该直接被用于该流水线后续阶段的构建过程，而不是在后续阶段中被再次重复构建。

如果该部署流水线实例触发了下游流水线，并且下游流水线也使用该制品，那么，部署流水线工具应该确保它来自上游部署流水线的同一个实例。只有这样，我们对该制品的质量信心才能随着部署流水线的前进而增加。

例如，在图7-4中，构建号为521的部署流水线实例中，其内部发布阶段所用的软件包就是同一构建号521的提交构建阶段生产出来的二进制产物。

2008年GoCD的所有代码和构建安装脚本及配置信息都保存在同一个代码库中。每次触发部署流水线后，如果该实例后续各阶段需要前面阶段的构建产物，则均从构建产物仓库中取出，而非再次重新构建。

即使有同一个部署流水线的多个实例正在同时运行，每个实例中后续各阶段所用的制品和源代码也应与同一部署流水线实例前面阶段的版本和出处保持一致。

2．与业务逻辑松耦合

部署流水线工具应该与具体的部署构建业务相分离。我们不应该为了方便实现自动化，而将软件代码的构建和部署过程与所选择的部署流水线工具紧耦合，例如将一些软件部署时所用的脚本或所需信息由部署流水线平台保存。相反，我们应该提供单独的脚本，并将其放入该产品的代码仓库中。这样就可以轻松对这些脚本的修改进行跟踪和审核。

也就是说，仅仅将部署流水线平台工具视为任务的调度者、执行者和记录者，它只需要知道部署流水线中各种任务触发与调度流程，而不必知道我们如何构建和部署软件。

3．并行化原则

在部署流水线的设计中，我们也应该尽可能考虑并行化。在GoCD的部署流水线中，很多阶段都有并行任务。例如，提交构建阶段中有5个自动化测试任务，它们各自包含不同的测试用例，在不同的计算节点上运行。简而言之，应该尽早提供质量反馈信息，从而及时修正发现的问题。

如果任何资源都是无限且免费使用的，那么我们希望每一次变更都会同时触发所有类型的测试，而且所有自动化测试用例都是并行执行。如此一来，整体的反馈时间就会大大缩短。

4．快速反馈优先

在资源不足的情况下，部署流水线应该让那些提供快速反馈的任务尽早执行。例如GoCD的部署流水线中，单元测试放在了端到端功能自动化测试和性能自动化测试的前面。这是反馈速度与反馈质量之间的一种权衡。为了确保能够更快地得到反馈，我们可能会冒一些风险，优先执行那些运行速度快的自动化验证集合，而将那些运行较慢、消耗资源较多的自动化验证集合放在后面执行。

5．重要反馈优先

对于反馈机制，不能只因其执行速度慢，就把它放在后面执行。这一条与前面看似矛盾，但在某些情况下却是必要的质量手段。

例如，软件安装包的安装测试虽然运行速度比单元测试速度慢，但其反馈更加真实有价值，也应该放到流水线的前面阶段来执行，以免所有的单元测试都通过以后才发现软件无法部署启动。

1．立即暂停原则

立即暂停原则是指当部署流水线运行时，某个环节一旦出了问题导致执行失败，团队应该立即停下手中的任务，安排人员着手开始修复它，而不是放任不管。并且，在问题被修复之前，除因修复这个问题而提交代码以外，禁止其他人再向代码仓库提交新的代码变更。

立即暂停原则是质量内建理念的具体体现，它借鉴丰田生产系统中的stop the line原则。在丰田汽车生产线上，无论什么原因，只要操作者无法高质量地完成他的工作任务，他就可以拉下警示灯，让整个生产线停下来，直到问题被解决，详见第4章的相关内容。

GoCD团队在实践部署流水线时，也采用了类似的做法。为了不妨碍团队其他成员提交代码，若提交构建阶段失败，提交者在10分钟内无法修复问题的话，应该回滚代码。

2．安全审计原则

角色协作时，如果要传递代码或软件包，那么它们应该来自受控环境。受控环境是指对该环境的一切操作均被审计，并且在该环境中的任何组件（如源代码、二进制代码包或者已安装的程序）均已通过审计。每个部署流水线实例（以唯一实例编号为标识）的任何环节均应使用部署流水线所提供的制品，其产生的任何产物也应该接受受控管理。例如，测试人员不应该私自拉取代码，自己手工构建软件包进行测试，也不应该接受开发人员通过各种方式（如即时通信工具）传递的软件包进行测试。每个角色对交付物进行验证时，都应该确保该交付物来自公共受信源，即统一的版本控制仓库或制品库。

尽可能早地对部署流水线产物进行安全审计，包括在构建过程中所使用的第三方软件包以及企业内其他团队提供的类库或软件服务。

重磅推荐

《持续交付2.0》

硅谷顶级互联网公司的产品研发方法。

在未来十年里，

快速提升工程生产力，打造有战斗力的团队，

应对激烈的市场竞争，

这一本书就够了~

《持续交付2.0：业务引领的DevOps精要》

扫码购买

京东 77.5元

本书“重新定义”了持续交付，增补了组织管理和架构两个维度，辅助以真实案例，对诸多持续交付的原则和实践加以解读，并对持续交付过程中的取舍原则加以论述。 

持续交付2.0是实现组织战略目标的组织能力，并引入双环模型理论，以及基础工作原则、组织原则和架构原则；

通过多个互联网公司案例的解读，阐述如何根据组织的当前状况，应用原则，并对最佳实践进行取舍，快速达到组织能力目标。

关于作者

乔梁

持续交付2.0 创始人

专注于软件企业组织管理

DevOps顶级大神

著有《持续交付2.0》

译有《持续交付》《软件沉思录》

关注公众号查看其他原创作品