可编程网络自动化

持续集成

｜

371

图

10-3

看起来应该非常熟悉。全世界的网络工程师一直都是这么做的。可能他们并不是部

署软件，而是在部署基础设施的关键变更，这往往比其他基础设施变更具有更大的“爆炸

半径”。通过

SSH

会

话登入路由器来修改配置，其风险不亚于编辑生产环境中的应用程序

源代码。

相比之下，

CI

只提供了一处地方可供人推送变更

，那就是

CI

管道——尤其是管道中被称

为

同行评审

（

peer review

）的第一部分

。这是一长串自动化步骤（比如自动测试和健全性

检查）中的第一步。为了使变更应用于产品环境，它们

必须

毫无例外地通过这条管道，如

图

10-4

所示。

开发人员

持续集成管道

同行评审 自动测试 自动部署 产品

推送代码

图 10-4：将软件部署到 CI 管道

再次重申，

CI

的目的是在提高速度的同时维护（或改善）稳定性。这是通过创建进行变更

的单一入口点来实现的。如果变更没有经过一系列测试，以确保其经过技术同行评审，避

免再次出现之前犯过的错误，那么就无法改动基础设施。

有些组织雇用了被称为

发布工程师

（

release engineer

）的专家来管理

CI

管道。

这些人熟悉版本管理工具（如

Git

）、测试工具、服务器搭建和同行评审系统。

他们负责维护管道的完整性，使开发人员无须再为此劳心。他们的目标是自

动化从笔记本计算机到最终产品环境的流程（故称为“发布”工程师）。

聘请专门的发布工程师并不总是那么容易，但是如果可以，并且你的团队足

够强大的话，能配有发布工程师自然再好不过了。

我们已经介绍了

CI

的基础知识，现在来深入了解一些你可能会碰到的组件和相关的概念 ...