3.构建、部署、测试和报告
我们刚刚已经说明了在企业持续集成成熟度模型中存在四个维度：构建、部署、测试和报告，这四个维度是从源代码到软件产品的端到端的构建生命周期的必要元素。
3.1 构建
原始的，以开发人员为中心的持续集成是为了从构建软件中获得快速反馈。当持续集成满足企业的需求时，构建管理、项目间依赖、构建流程管控就变成关键元素。大部分的新项目开始于开发机上进行的无标准流程的构建，一些人可能在IDE中进行构建，而另外一些人可能使用构建脚本。甚至有极不成熟团队会使用其构建软件，用来进行测试部署或者产品发布部署。大部分的团队很快就不得不面对由于缺少控制所导致的问题，因此我们必须在一开始就要找更好的方法。
成熟构建的第一步是将构建流程标准化，并脱离开发机进行。使用非开发机进行构建意味着开发环境的变化不会以不可预测的方式影响构建。因为构建不再在开发空间进行，构建流程的标准化必然使得构建流程中的源代码的获取被标准化，涉及的如从一个分支获得最新的代码，或对源代码进行标记，或者其他的活动。最重要的是选择这些约定并坚持一致的执行。通过这些实践团队可以获得入门级要求的构建能力。
任何使用持续集成标准的团队，如果进一步的使构建步骤自动化进行，使得构建服务器可以发布指令，按照规则获得源代码并运行构建脚本，这样就达到了成熟度的初级等级。典型的自动构建是每日构建，某些团队甚至可以实现每日多次构建。
在成熟度的中级等级，团队开始更明确的对依赖的其他软件进行管理，比如一些子项目或者第三方库。取代了潜移默化的口头约定，中级团队采用了配置库来进行依赖关系管理，以跟踪这些库文件并在在构建时提供他们。同样的，也会通过依赖管理工具对其他构建所要依赖的构建自身进行存取。
通过这些控制方法，很容易达到自动构建并提供有价值的反馈。中级等级的团队采取了持续构建，当每个开发人员提交代码时或者依赖关系发生变化时就自动运行构建。所有的构建结果需要进行存储（在网络上或者干脆就在持续集成服务器上）、定期的清理和编号以便识别。大规模的团队也可使用分布式的设备来执行大量的并发构建。这时许多组织的需求可以得到满足了。
更正规的组织会进一步的控制构建过程从而达到高级等级。在这种环境下，团队像追踪源代码和依赖关系一样对构建过程进行追踪。对于构建过程的更改需要被批准，对于登录正式的构建服务器和构建服务器上的配置都是受控的。当这些成为一个必须遵守的要素或者当企业持续构建变成产品系统的一个部分时，高级等级的受控构建流程是他们的一个目标。对于其他的团队，中级等级已经足够了。
另外一些监管规则更为严格的组织，要求必须能够完美的对以前的版本进行再次构建。这些组织使用多种技术来保证环境的准确复制。某些组织可能会有细致的版本化的脚本，以便在开始构建之前就开始从操作系统做起来准备构建机器；某些组织则使用做好的基于快照的虚拟机，通过改变时间来生成之前的版本构建过程。在某些监管级别的团队看来，这些都是非常疯狂的而不会去采取这些步骤。而且这些对于大部分的团队来说只能增加痛苦的负担而不会有多少价值。
原文：www.urbancode.com Enterprise Continuous Integration Maturity Model（ECIMM）
翻译：OscarYang（原始发表于http://hi.baidu.com/cmmi/），转载请注明