持续交付成熟度模型-让构建成熟

让构建成熟，首先要作的就是让构建流程标准化而且不要在开发的机器上执行官方构建。不使用开发的机器作构建，意味着开发环境的改变不会对构建形成一些不可预料的污染。由于构建再也不在开发人员的工做空间执行，标准构建流程会有一部分定义怎样从版本控制系统获取源代码以用来构建。这些用来构建的代码可能来自于某个分支的最新代码，或者某个打标签的源代码，或者其余。最重要的是这个约定会一直被执行。有了这些实践，团队就达到了构建能力的 Base 级别。

任何一个开始标准持续集成的团队都会再往前一步，将执行构建的步骤自动化，做为自助构建或者每晚构建的一部分。构建服务器会描述构建机器，源代码规则以及执行这些构建步骤，提供一个Beginner级别的受控的构建流程。一般这些自动构建被配置为天天执行，但也有部分团队会配置为天天两次或者更多。

在Intermediate 级别，团队开始管理其余软件的依赖，例如子工程和三方库。团队再在使用约定的地方，取而代之的是使用依赖管理库来管理这些工程依赖包，供每一次构建使用。一样的，其余构建依赖的构建产物也会放在依赖库中，以便依赖管理工具能够访问到。全部的构建产物都会被存储起来（在网盘上或者就在CI服务器上）按期清理，编号，以便于识别。

达到这种程度的控制，自动构建便很容易达到并且能够提供有效的反馈。达到Intermediate的团队采起持续编译，自动构建会在开发提交代码或者当依赖发生改变的时候被执行。较大的团队会使用分布式基础设施来处理大量的并发构建。

更加规范的团队将控制他们的构建流程。在这种环境下团队将跟踪构建流程的改动和源代码及依赖的改动。修改构建流程须要批准，所以访问官方构建机器和构建服务器的配置是受限的。在那些须要遵照制度或者企业持续交付变成了成产系统的团队中，中级控制构建流程应该做为其目标；对于其余团队而言，配置的安全性是可选的。

更大的组织或者那些寻找更快集成测试的团队会期待作到Advanced级别。随着天天构建次数的增长以及团队的多样化（例如须要Linux 和Windows构建机器），一个单独的构建机器再也不够用。能够自动选择机器和负载平衡的集群就是必须的。At scale, traditional polling of source control systems looking for changes may place a performance strain on the ECD server as well as the source control system.在这种状况下轮询就应该被SCM在企业持续交付服务器上触发构建的事件来代替，也可能经过webservice来触发。

一些规范性规则更加严格而且指出组织必须可以执行之前版本的完美重建。这些组织将使用多样的技术来保证精确的环境复制。有些当心翼翼的将准备编译机器的脚本用版本管理起来,这些脚本所作的事情包括了从操做系统一直到运行构建以前。另一些使用基于虚拟机的快照，这些快照是实例化的，而且有本身的时钟修改直到运行某个版本的构建的过程。咱们将这种级别的构建流程控制归类为Extreme级别。在某些管理级别，团队会极力作到这些。然而，这些没有提供太多价值的步骤对大多数团队来讲将会是痛苦的负担.

另一些公司致力于使某些开发流不被“破坏”。他们使用封闭的提交策略来执行构建和测试任何提交源代码的机会。若是有改变会致使build失败，他们会拒绝这些提交。这种极端策略能够提供一个稳定的签出区域，可是也减缓了集成，同时引入了提交队列和竞态条件.