可编程网络自动化

376

｜

第

10

章

10.3.1

　同行评审

当我们谈论传统软件意义上的同行评审时，通常说的是应用程序的源代码。开发人员会向

一些源代码文件提交包含差异的补丁，补丁会以某种方式发布到代码审查系统中，审查员

会查看该补丁并提供意见或批准。

将管道这部分用于网络自动化时，我们并没有偏题太远。本书的其他几章（比如第

5

章和

第

6

章）

提倡网络自动化采用“基础设施即代码”的方法，在这种方法中，所有相关的配

置信息都按照开发人员对待源代码的方式来处理。在我们的例子中，不会出现

Java

代

码，

可能会有

Y

AML

文件或

Jinja

模板。它们都只是文本文件，我们同样可以对其执行自动化

测试。

如果维护过任何形式的生产环境

IT

基础设施

，那么你应该参加过变更批准委员会

（

Change

Approval Board

，

CAB

）。你可能负责填写表单，在其中描述要进行的配置变更，

然后参加漫长的电话会议，做一番精心措辞的简单发言，以求让审批人员满意。这套流程

在现代

IT

中根深蒂固

，但它并不能

真正

将风险降到最低，也无法在相关技术团队之间提

供透明度。这都是老派的做法了。

在谈论用于网络的

CI

时

，我们会从同行评审的概念着手，这可能看起来与上面描述的情景

类似，但还是有一些根本区别。在

CI

中

，如果你想做出变更，那么只需在

Git

中创建一个

新分支并进行改动即可。通过在作为

CI

管道组成部分的

Git

仓库中执行配置

，不需要事先

请求许可，因为在完成评审及合并入

master

分支之前，变更并不会被推送到生产环境。

这种新模式有一些颇具吸引力的好处。在同行评审方面，现在无须再“描述”要做的变 ...