企业持续集成成熟度模型简介之一——构建
本文是我在软件开发2.0大会 上与大家探讨的内容。如前文所述，该模型起源于CITCON 北美的一个讨论，并由Eric和Jeffrey Fredrick 分析总结，并发布于这里 。由于内容较多，将做为一个系列发布。（Jeffrey Fredrick 目前是开源持续集成工具CruiseControl的开发和维护者之一）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
当今软件开发领 域的自动化推广相当显著，软件也越来越多的由大规模、分布式的团队开发完成，而严格的企业管理需求也是十分常见的。由此表现出来的敏捷软件开发和持续集成 与企业开发项目的现实之间的碰撞也越来越显著。在软件开发的整个生命周期中，我们对自动化的投入在不断增加。在这方面的先行者已经跨过了团队级别的持续集 成，而将他们的自动化成果与端到端的方案结合在一起了。这些在企业级持续集成方面的投入使得他们可以应对需求的变化，并快速交付高质量的软件，而且得到事 半功倍的效果。尽管自动化有这么多的好处，但，对于自动化的采纳情况却并不均衡。比如，很多团队仍旧在手工、缓慢且高风险的部署中挣扎着；而某些团队却可 以在一天内进行多次高效且足够安全的生产环境部署。其实，有很多方法或途径来改善我们的开发自动化，但是从哪里开始呢？
企业的多样性
当创建这篇指导 书时，我们遇到的挑战就是：不同企业（甚至同一个企业的不同团队）都不具有统一性。医疗设备系统的某些需求可能就要比做游戏难，也可能比在电子商务网站上 增加新功能要难，也可能会比创建一个内部SOA应用要难。因此，单一的成熟度模型不可能适应全部情况。因此，我们选择了企业持续集成的四个维度来衡量成熟 度，它们分别是构建、部署、测试和报告。我们将每一个维度上所对应的实践归入某一等级之下，并解释为什么需要采纳(或不采纳)这些实践。通过这个模型，你 可以了解业内在企业持续集成方面的平均水平，并可以据此反思，在哪些方面做得高于行业平均水平，还有哪些方面做得不足。这个模型所反映出来的评估尺度完全 基于几年来数百个团队持第一手经验以及本领域的一些报告。为了解释如何使用这个模型，我们创建了三个有不同需求的企业案例。我们会分析他们的状况，并展示 他们如何使用成熟度模型来计划哪些改进会给他们带来最高的投资回报率。
成熟度模型中的级别
在整篇文章中， 企业持续集成不同维度的成熟级别会以相同的方式来阐述。级别分为：入门、新手、中等、进阶和疯狂。为了解释这些级别，下面我们举例说明各级别之间的关系。 实例的出发点为：该过程为完全手工的，即某个工程师必须要手工执行一系列冗长且易出错的步骤来达到“将某个手工过程自动化”这一目标。那么对于这个“自动 化某个过程”，它的成熟度模型如下所示：
团队最初是入门 级，因为他们已经写了一些辅助脚本，用于该过程中那些特别慢或问题较多的部分进行了自动化。这种自动化的益处在于节省时间且减少错误。为了进一步提高，团 队将所有辅助脚本串接起来，实现了整个过程的单一脚本自动化，即达到了中级。而这个单一脚本的回报就是：这个操作过程可以很容易交给别人去做。当团队打算 提高到进阶级时，需要用某个应用软件来调用执行该脚本。这个应用软件可能在后台执行的，但一定是每次都在正确的条件、时机和位置上运行的。比如，这个应用 软件可能只需要用户点一下鼠标，或者只需要在某个特定的时间调用这个脚本，自动传入一些参数来执行。
当然，进阶级或者疯狂级的定义都会随着时间的推移而改变。在持续集成诞生时，“代码提交后自动触发构建”就被认为是疯狂的，而在今天只能算是中级中的一个活动而已。
构建、部署、测试和报告
在我们的成熟度模型中，包括了四个维度，它们分别是构建、部署、测试和报告。这四个维度覆盖了整个端到端的构建生命周期，即从源代码直到产品。
构建
那种原始的以开 发人员为中心的持续集成是为了从构建软件中得到快速的反馈。而当持续集成进入企业视角后，构建管理、项目之间的依赖以及构建过程上的管理控制都成为至关重 要的元素了。大多数新项目一般在开始时，都是在开发机器上执行构建的，而且没有一个标准的过程。一个开发人员可能习惯于在他自己的IDE上进行构建，而另 一个人可能写了一个构建脚本来做这件事。那些最不成熟的团队还会将那些使用这种过程构建出来的二进制文件部署并测试，甚至将其发布到生产环境中。这种因缺 乏控制所导致的问题很快就显现出来了。因此，我们一开始就要找更好的方法。
成熟构建的第一步就是让构建过程标准化，并在非开发机器上进行正式的构建。使用非开发者机器进行构建意味着这种构建不会因开发者的机器环境发生了变 化而导致污染。因为正式构建已经不在开发者的机器上进行，所以我们必然是每次都从某个固定的源文件控制中得到代码，并遵守一定的规则：比如每次都从某个分 支签出最新版本，或者是打过某种标签的源代码等等。因些做到了这些之后，该团队就达到了入门级。
入门级的团队进一步采取行动，将构建步骤实现自动化执行。即构建服务器将指挥机器、按源代码签出规则得到源代码，并执行那些构建步骤，从而提供了初步受控的构建过程。典型的是：这些自动构建每日执行，尽管某些团队可能会一天执行两次以上。此时的团队就提高到了新手级。
而对中级的团队来说，他们开始更明显地关注并管理对于其它软件的依赖（包括子项目或第三方库）。中级使用依赖 管理库来追踪这些库文件，并在构建时提供这些库文件，而不是使用某种口头约定方式。同样地，那些可能被其它构建所引用的构建也会通过依赖管理工具将其自身 放在这个库中以便其它构建来引用。达到这一级别的控制后，自 动构建就是很容易做到的了，而且也提供更有价值的反馈。中级团队采纳了持续构建（即每个开发人员提交时就自动构建或当依赖发生变化时）。所有的构建结果都 被保存（可能放在一个网络服务器上，或干脆就在持续集成服务器上），并进行周期性的清理并标签以方便识别。规模大一些的团队将使用分布式构建设施来并行处 理数量众多的构建。此时，对于很多组织来说，可以说满足了他们的需求。
对于更正规的组 织（比如企业级）将会进一步做到进阶级，以控制构建过程。在这种环境下，团队象追踪源代码和依赖的变化一样，对构建过程的变化也进行记录跟踪。修改构建过 程需要经过批准，对于登录官方构建机器，修改构建服务器配置等都是严格控制的。对于那种“服从是一个要素”的地方或那种将企业持续集成已成为一个生产系统 的地方，应该将进阶级的受控构建过程做为目标。而对于没有这方面要求的其它团队来说，中级也就可以接受了。
另外，某些组织 的管理控制规则更加严格，且要求必须能够完美地重新构建从前的发布版本（比如需要拿到与一年前的某次构建产物一模一样的产物）。这些组织将使用各种各样的 技术来确保每个环境的可重复性。一些可能会有缜密细致地被版本控制化的脚本，在开始运行构建之前从安装操作系统开始来准备构建机器。另一些可能使用做好的 虚拟机镜像来做类似的事情。我们把这种控制级别定义为疯狂级。因此，一些团队可能不需要达到这种方式。因为可能负担太大而收益太少。
