当今软件开发领域的自动化推广相当显著，软件也越来越多的由大规模、分布式的团队开发完成，而严格的企业管理需求也是十分常见的。由此表现出来的敏捷软件开发和持续集成与企业开发项目的现实之间的碰撞也越来越显著。在软件开发的整个生命周期中，我们对自动化的投入在不断增加。在这方面的先行者已经跨过了团队级别的持续集成，而将他们的自动化成果与端到端的方案结合在一起了。这些在企业级持续集成方面的投入使得他们可以应对需求的变化，并快速交付高质量的软件，而且得到事半功倍的效果。尽管自动化有这么多的好处，但，对于自动化的采纳情况却并不均衡。比如，很多团队仍旧在手工、缓慢且高风险的部署中挣扎着；而某些团队却可以在一天内进行多次高效且足够安全的生产环境部署。其实，有很多方法或途径来改善我们的开发自动化，但是从哪里开始呢？

　　企业的多样性

　　当创建这篇指导书时，我们遇到的挑战就是：不同企业（甚至同一个企业的不同团队）都不具有统一性。医疗设备系统的某些需求可能就要比做游戏难，也可能比在电子商务网站上增加新功能要难，也可能会比创建一个内部SOA应用要难。因此，单一的成熟度模型不可能适应全部情况。因此，我们选择了企业持续集成的四个维度来衡量成熟度，它们分别是构建、部署、测试和报告。我们将每一个维度上所对应的实践归入某一等级之下，并解释为什么需要采纳（或不采纳）这些实践。通过这个模型，你可以了解业内在企业持续集成方面的平均水平，并可以据此反思，在哪些方面做得高于行业平均水平，还有哪些方面做得不足。这个模型所反映出来的评估尺度完全基于几年来数百个团队持第一手经验以及本领域的一些报告。为了解释如何使用这个模型，我们创建了三个有不同需求的企业案例。我们会分析他们的状况，并展示他们如何使用成熟度模型来计划哪些改进会给他们带来最高的投资回报率。

　　成熟度模型中的级别

　　在整篇文章中，企业持续集成不同维度的成熟级别会以相同的方式来阐述。级别分为：入门、新手、中等、进阶和疯狂。为了解释这些级别，下面我们举例说明各级别之间的关系。实例的出发点为：该过程为完全手工的，即某个工程师必须要手工执行一系列冗长且易出错的步骤来达到“将某个手工过程自动化”这一目标。那么对于这个“自动化某个过程”，它的成熟度模型如下所示：

　　团队最初是入门级，因为他们已经写了一些辅助脚本，用于该过程中那些特别慢或问题较多的部分进行了自动化。这种自动化的益处在于节省时间且减少错误。为了进一步提高，团队将所有辅助脚本串接起来，实现了整个过程的单一脚本自动化，即达到了中级。而这个单一脚本的回报就是：这个操作过程可以很容易交给别人去做。当团队打算提高到进阶级时，需要用某个应用软件来调用执行该脚本。这个应用软件可能在后台执行的，但一定是每次都在正确的条件、时机和位置上运行的。比如，这个应用软件可能只需要用户点一下鼠标，或者只需要在某个特定的时间调用这个脚本，自动传入一些参数来执行。

　　当然，进阶级或者疯狂级的定义都会随着时间的推移而改变。在持续集成诞生时，“代码提交后自动触发构建”就被认为是疯狂的，而在今天只能算是中级中的一个活动而已。

　　构建、部署、测试和报告

　　在我们的成熟度模型中，包括了四个维度，它们分别是构建、部署、测试和报告。这四个维度覆盖了整个端到端的构建生命周期，即从源代码直到产品。

　　构建

　　那种原始的以开发人员为中心的持续集成是为了从构建软件中得到快速的反馈。而当持续集成进入企业视角后，构建管理、项目之间的依赖以及构建过程上的管理控制都成为至关重要的元素了。大多数新项目一般在开始时，都是在开发机器上执行构建的，而且没有一个标准的过程。一个开发人员可能习惯于在他自己的IDE上进行构建，而另一个人可能写了一个构建脚本来做这件事。那些最不成熟的团队还会将那些使用这种过程构建出来的二进制文件部署并测试，甚至将其发布到生产环境中。这种因缺乏控制所导致的问题很快就显现出来了。因此，我们一开始就要找更好的方法。