让构建成熟，首先要做的就是让构建流程标准化并且不要在开发的机器上执行官方构建。不使用开发的机器做构建，意味着开发环境的改变不会对构建造成一些不可预料的污染。因为构建不再在开发人员的工作空间执行，标准构建流程会有一部分定义怎样从版本控制系统获取源代码以用来构建。这些用来构建的代码可能来自于某个分支的最新代码，或者某个打标签的源代码，或者其他。最重要的是这个约定会一直被执行。有了这些实践，团队就达到了构建能力的 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失败，他们会拒绝这些提交。这种极端策略可以提供一个稳定的签出区域，但是也减缓了集成，同时引入了提交队列和竞态条件.
原文：http://haisha.iteye.com/blog/2238017