前言

我们的持续集成和自动化实践成熟度如何？我们在哪里可以得到针对我们的具体问题和需求最需要改进的地方？其他组织如何解决这些一样的问题？这个指南将帮助你回答这些问题。敏捷软件开发和持续集成同目前企业的大规模、分布团队和严格管理的开发需求的现状之间发生碰撞已经很普遍了，这些导致了在软件开发整个生命周期内的自动化工作量急剧扩大。具有顶级执行力的组织已经跨越了团队级别的持续集成工作，开始尝试企业级别的端到端自动化集成解决方案，这使得企业可以以更低的成本更快的交付具有更高质量的产品。尽管有这些优点，但是业内的自动化实践依然是参差不齐的，很多团队仍然在缓慢且高风险的手工部署中挣扎，而某些团队却可以在一天内进行多次高效且足够安全的产品部署。路漫漫其修远，从哪里开始呢？

1.企业多样性

当我们创建这个指南时面临的一个挑战是：一个企业，甚至是一个企业的不同团队之间都具有很大的差异性。医疗设备的需求肯定和游戏制作、电子商务站点增加功能或者创建内部的SOA的需求有很大的差异。单一的成熟度模型不是万能的，因此我们选择了企业持续集成的四个维度（构建，部署，测试和报告）作为一个整体来衡量其成熟度。对于每一个维度，我们通过实践活动的分类来识别对应的等级，并说明每个组织为什么要（或者不要）采纳他们。通过这个模型，你可以了解目前的行业平均水平，并且知道哪些实践你应该继续坚持，哪些实践你已经落后。这个判定标准来自于相关领域内近年来的数百个团队的第一手经验和报告。我们还创建了三个案例来演示如何应用这个模型来满足企业不同的需求，并展示他们如何利用成熟度模型来计划改进以获得最好的投资回报率。

2.成熟度等级

在这篇文章中，企业持续集成各个维度的成熟度等级将会以相同的方式描述。成熟度等级一般情况下都是由低向高的，在这里我们使用五个等级：入门、初级、中级、高级、资深。为了便于理解这些等级，我们先看以“自动化”为例的典型例子：工程师为了完成一个目标，必须执行一个冗长且易错的完全手动执行的过程，以此为起点我们映射其自动化流程的成熟度等级如下所示：

作为团队的起点是入门等级，他们开始创建一些简单的脚步来自动运行某些特别慢或者有问题的部分。自动化的好处包括节省时间和减少错误。团队为了进一步的提高达到中级等级，他们在单一脚本里实现了整个过程的自动化。脚本化的结果是流水线化的过程很容易交给其他人执行。团队为了进一步提高达到高级等级，他们将使用某个程序自动调用脚本来替代手工执行该脚本。这个程序可能在后台运行，每次都通过正确的“开关符”，在正确的位置执行相同的脚本；这个程序可能有简单的“一键”触发界面，也可能通过定时器自动传入参数运行。

成熟度的高级等级对绝大部分的过程来说是极好的，因此也是我们推荐的目标。在大部分的团队中，许多工程过程还仅仅在辅助脚本自动化这个级别，因此初级是业内的平均水平。团队缺少辅助脚本不仅仅是思想的缺失，而且落后于整体水平。

虽然资深等级的元素只有一个，但是实现它还是很昂贵的，然而他却是某些团队的目标。换句话说，大多数组织将实现资深等级，而少数人则不会。例如，资深等级的实践在某些复杂条件过程需要时会被自动激活调用。这个等级对于大部分的过程是不合算的，但是在某些场景下却是必须的。

当然，我们认为的高级或者资深级别都会随着时间而改变。在持续集成刚刚开始时，当代码提交后自动触发构建被认为是疯狂的，但是现在持续集成工具的发展已经普遍支持“回滚”而不再需要牺牲大量的时间和质量，现在它只是中级的一个活动而已。

3.构建、部署、测试和报告

我们刚刚已经说明了在企业持续集成成熟度模型中存在四个维度：构建、部署、测试和报告，这四个维度是从源代码到软件产品的端到端的构建生命周期的必要元素。

3.1 构建

原始的，以开发人员为中心的持续集成是为了从构建软件中获得快速反馈。当持续集成满足企业的需求时，构建管理、项目间依赖、构建流程管控就变成关键元素。大部分的新项目开始于开发机上进行的无标准流程的构建，一些人可能在IDE中进行构建，而另外一些人可能使用构建脚本。甚至有极不成熟团队会使用其构建软件，用来进行测试部署或者产品发布部署。大部分的团队很快就不得不面对由于缺少控制所导致的问题，因此我们必须在一开始就要找更好的方法。

成熟构建的第一步是将构建流程标准化，并脱离开发机进行。使用非开发机进行构建意味着开发环境的变化不会以不可预测的方式影响构建。因为构建不再在开发空间进行，构建流程的标准化必然使得构建流程中的源代码的获取被标准化，涉及的如从一个分支获得最新的代码，或对源代码进行标记，或者其他的活动。最重要的是选择这些约定并坚持一致的执行。通过这些实践团队可以获得入门级要求的构建能力。

任何使用持续集成标准的团队，如果进一步的使构建步骤自动化进行，使得构建服务器可以发布指令，按照规则获得源代码并运行构建脚本，这样就达到了成熟度的初级等级。典型的自动构建是每日构建，某些团队甚至可以实现每日多次构建。

在成熟度的中级等级，团队开始更明确的对依赖的其他软件进行管理，比如一些子项目或者第三方库。取代了潜移默化的口头约定，中级团队采用了配置库来进行依赖关系管理，以跟踪这些库文件并在在构建时提供他们。同样的，也会通过依赖管理工具对其他构建所要依赖的构建自身进行存取。

通过这些控制方法，很容易达到自动构建并提供有价值的反馈。中级等级的团队采取了持续构建，当每个开发人员提交代码时或者依赖关系发生变化时就自动运行构建。所有的构建结果需要进行存储（在网络上或者干脆就在持续集成服务器上）、定期的清理和编号以便识别。大规模的团队也可使用分布式的设备来执行大量的并发构建。这时许多组织的需求可以得到满足了。

更正规的组织会进一步的控制构建过程从而达到高级等级。在这种环境下，团队像追踪源代码和依赖关系一样对构建过程进行追踪。对于构建过程的更改需要被批准，对于登录正式的构建服务器和构建服务器上的配置都是受控的。当这些成为一个必须遵守的要素或者当企业持续构建变成产品系统的一个部分时，高级等级的受控构建流程是他们的一个目标。对于其他的团队，中级等级已经足够了。

另外一些监管规则更为严格的组织，要求必须能够完美的对以前的版本进行再次构建。这些组织使用多种技术来保证环境的准确复制。某些组织可能会有细致的版本化的脚本，以便在开始构建之前就开始从操作系统做起来准备构建机器；某些组织则使用做好的基于快照的虚拟机，通过改变时间来生成之前的版本构建过程。在某些监管级别的团队看来，这些都是非常疯狂的而不会去采取这些步骤。而且这些对于大部分的团队来说只能增加痛苦的负担而不会有多少价值。

3.2 部署

部署是将软件移动到它被测试、被用户存取或者准备好交付给客户的过程。对于WEB应用来说，部署可能意味着在一组WEB应用服务器上安装应用程序并更新数据库或者静态内容服务器。对于一个视频游戏控制台，部署可能是在测试服务器进行安装；而产品部署则可能是生产一个ISO母盘交付给发行商。

部署工作在最初时一般都是手工进行，部署工程师一般从指定的位置获得构建结果，然后把它们移动到目标机器上并运行安装流程。手工部署过程漫长而且非常容易部署失败。工程师们常常被迫在晚上和周末进行加班以便进行高风险的产品部署或者测试部署，因为这些系统平常被测试人员所使用，不能被干扰。更糟糕的是在不同的环境中进行部署往往使用不同的过程，在一个环境中成功的部署并不能保证在其他环境中成功部署。

一个团队从完全的手工流程过渡到使用一定量的辅助脚本或者完全脚本化的过程是一个重要的改进。整个行业中，大部分的团队会有一些辅助脚本，但还是达不到完全的脚本化部署，特别是在一些受控环境下。

中级等级的团队擅长为了测试目的进行的部署，他们一般通过“一键部署”的方式以完全脚本化的部署来实现部分或者完全的测试环境部署。这样做使得部署工程师的工作负荷大大减少，并且减少了测试团队等待部署的时间。如同持续构建是中级等级的构建团队的特征一样，第一次的测试环境自动部署是部署维度在成熟度中级等级上的一个标志。通常会在成功的持续构建完成后或者每天定时的周期性的动态进行部署而不中断测试。

中级等级团队的最后一个标志是他们在规范不同环境下的部署方面进展不错。虽然可能还有一些环境的变化，或者两种类型的部署，但在生命周期早些时候建立的成功部署能够良好的预测未来的部署。对于许多团队来说，达到这个成熟度等级是他们不错的目标。

高级等级的团队则将注意力转向受控环境或者产品环境，产品部署（发布）通过“一键部署”进行，并且产品发布成功后会自动触发生成灾难恢复使用的版本。任何在内部环境中进行产品部署的团队都应该考虑达到高级等级：在所有环境中具备一个一致的部署过程，这样在进行产品发布时可以明显的减少最后时刻失败的可能性。高级等级的团队另外一个特征是能够将通过质量检查的产品完全自动的部署到测试环境中，比如一个通过测试经理批准的构建能够自动的安装到压力测试环境中。

资深等级团队则实施“持续部署”，即可以进行完全无人工干预的自动产品部署：一个构建完成后则自动部署到测试环境中。当这些通过“管道”进行时，构建在每个阶段都进行自动化的测试，当其通过所有的质量检测后，则立刻进行产品部署。某些.com程序可以在提交源代码一个小时内完成一个重要的变更发布，显然这些还需要非常成熟的自动化测试、版本回滚和监控机制。在一个快节奏的环境中，新功能的尽快部署不仅是一个核心竞争力，而且也可以缓解功能变更带来的高风险。

3.3 测试

持续集成和不同等级的自动化测试是紧密相关的，这在Martin Fowler具有影响力的文章（译注：Continuous Integration ，http://martinfowler.com/articles/continuousIntegration.html，）和Steve McConnell更早期关于每日构建和冒烟测试实践的文章中都有提及。在企业持续集成的范围内，多种类型的自动测试和手工测试都会被考虑到，尽管这样，许多团队在测试方面依然十分薄弱。他们执行一个构建，然后进行一些基本的操作后就进行了发布；这些导致应用程序总是出现同样的错误，新功能只进行了简单的测试。团队在测试方面比较成熟的话，就会很快发现问题，这样在生产率和信心方面都会有所提升。

大部分团队都有一定形式的自动化测试，也许是一些小的单元测试套件或者一些测试脚本来确保应用程序基本的功能能够运行。这些基本的自动回归测试可以较早的、容易的发现基本问题。入门级别的团队通常都是刚刚开始适应自动化测试。

要达到初级等级，就必须在每次构建时都执行一系列的快速测试。这些测试使得团队有信心相信在任何时间应用程序都是可以工作的，当测试失败时，开发团队可以接到通知以便其在遗忘相关问题前修复缺陷。对于失败的响应对于这个成熟度等级是很重要的：一个团队如果对失败不能及时响应，他们就不能达到测试成熟度的初级等级。

中级等级的团队会扩展这种快速、构建时的测试。成熟的测试有一个显著特征就是有不同形式的测试集合。一个中级等级的团队不但有快速的构建时测试，而且也有自动的功能测试，他们也会在持续集成系统上运行一些静态的源代码分析。静态分析不必在每个构建时运行，但是可以在发布前周期性的进行，并修复发现的严重问题。

高级等级的特征是能够进行完整的测试。每个类型的测试其提供的信息都是有限的，单元测试提供系统中所有较复杂代码的覆盖度；功能测试覆盖系统中所有重要的功能点；边界和随机测试也会被使用。静态代码分析频繁运行，由工具进行的动态分析和安全扫描则可以对测试缺失的部分提供有效补充。为了便于得到尽快的反馈，根据范围和要求，测试可以分布在多个系统上并行运行。

达到高级等级需要极大的投入，但对一个缺陷成本比较高并需要高速前进的团队来说仍然是值得的。对于没有这些需求的项目来说，中级等级更合适于他们。

极端情况下，一些团队追求100%的测试覆盖度，尽管100%覆盖度的定义在变化，但是其意味着至少每一行都要被测试到是不变的。在多数应用中，存在一个收益平衡点（译注：按原意是“收益递减点”，即经济学中的“收益递减规律”造成的转折点，这是一个比较有意思的话题，简单的理解可以看看这里：http://zhidao.baidu.com/question/75514610.html?si=4），在这里对某些晦涩的代码行进行自动化测试的收益远小于对其创建自动化测试的成本。团队追求100%的覆盖度听上去似乎在做一些浪费的测试，但是设定一个极端的界限却可以消除“创建测试是有价值的，但是很困难”这样的借口。达到并保持100%覆盖度的目标也会成为一个自豪和动力的源泉。对于发现他们忽略了某些重要测试的高级等级团队来说，追求100%的覆盖度也许是可行的，但是对于大多数团队来说，这有点疯狂。

3.4 报告

长久以来持续集成工具就致力于报告最近的构建状态，报告也是企业持续集成中的一个被广泛关注的关键元素。在企业持续集成中，报告覆盖了组织中相关软件的质量和内容信息，同时也提供了对企业持续集成过程的度量。

一个团队没有报告就相当于“瞎子”。如果没有人可以看到测试结果，测试就是无用的；同样的，没有进行抽取和信息整合的大量数据使用起来是非常困难的，也是一样无用的。成熟的团队则通过不断提升报告的可视化程度来获得更多、更有用的信息。

在构建生命周期中使用到的许多工具都会产生报告，一个入门等级的团队通常基于工具生成的、供个别人阅读的报告来采取行动。在这个等级，如果团队中的其他人需要基于从源代码控制、测试工具、源码分析、缺陷管理或其他工具产生的信息来采取行动时，必须同报告负责人进行接触然后才能获得相关信息。

当团队提升到初级等级时，每个小组（开发、测试、发布）等都可以公布相关的信息。构建服务器可能提供关于代码改动、源代码分析、单元测试和编译错误的信息，测试团队会提供最近的自动化测试和手工测试报告，发布工程师会监控生产环境构建的时长、缺陷记录以及其他和发布速度相关的信息。每个小组基本都是独立工作，跨领域的信息传递都是依靠手工进行。虽然许多公司有不同水平的展现能力，但这个级别是业界的平均水平。

处于中级等级的团队会有两个大的变化。第一，团队的跨领域信息已经可以被互相访问，如测试人员可以从开发人员那里得知上个QA版本至今更改了哪些文件，或者开发人员测试的结果等；开发人员可以知道QA正在测试的内容以及测试的结果。每个参与构建生命周期上的人都可以获得对他们有用的最新报告的总结信息。更高的信息透明化，使得关于基础数据的沟通成本明显减少，从而将更多的精力放在基于报告中相关信息的举措上。

第二，有了历史报告。组织不仅有关于最近活动的信息，而且有过去的报告，这样就可以检索以前的发布信息同当前的发布进行对比。团队不仅知道最近的构建有95%的测试通过率，也知道新增了多少的新测试，哪些测试已经删除，以前的构建通过了多少个测试，以及95%的通过率同以前相比是更好了还是更糟了？团队应该更高兴还是要迅速采取行动解决问题？

一个高级等级团队不仅获得历史报告信息而且可以进行趋势分析。中级等级团队仅对每个测试失败进行记录，而高级等级团队则可以通过报告找到最常失败的测试，进一步的，他们还可以发现当哪些文件更改后，会使得单元测试失败以及测试小组运行的功能测试失败。通过薄弱环节的识别，可以帮助团队决定哪些代码需要进行附加测试或者进行重构。在专门的报告中，从不同领域获得的历史数据会被进行汇总、交叉引用和抽取，而且高等级团队能够实实在在的进行阅读并采取对应的措施。生成这些具有可实施性跨领域的报告是每个企业持续集成系统的目标。

当一个团队从初级向高级成长时，在上下文中进行当前的反馈时，会用相关的历史数据进行补充反馈。逻辑上的下一步是资深等级，它是针对未来的报告。一个资深等级的团队，会有大量的面向客户软件发布的相关数据，这使得产品部署后的缺陷报告和技术支持都可以被检索到。通过这些信息，我们可以生成关于发布所期望的支持工作量的预测报告。团队能够通过以往发布和当前发布的数据对比，估算出交付第一周后客户缺陷的数量。通过建立模型，他们能够问出比简单的“我们的特性都完成了吗？”更有趣的问题。

案例一：El Emeno投资公司：平衡敏捷和控制

El Emeno投资公司的团队为有价证券的交易者开发交易系统。快速实现新功能能够给他们带来核心竞争力，然而法律方面的需求要求对发布的产品要进行严格的控制和审计。

在实施企业持续集成之前，团队发现在提供交易者期望功能方面的优势和安全审计流程缓慢之间处于矛盾状态。不管开发人员实现一个交易者需要的功能是如何的快速，实际上的发布都需要数个签字，手工部署和一个漫长的测试循环。作为弥补，发布工程师被要求加班到深夜或者周末加班来完成部署以及文档准备，陷入了“加班--疲劳--犯错--纠正--再加班”的恶性循环。

因此，El Emeno在实施企业持续集成时将自动化和可追踪的部署放在第一优先级上。安全的“一键部署”将加快部署过程，同时提供安全性和可审计性。El Emeno努力达到部署的中级等级，以尽可能快的减轻发布工程师的压力。他们实现了常见的早期测试环境自动部署，解放了发布工程师的双手。

下一步是扩展到产品发布自动部署。因为产品部署的敏感性，在最初实施企业持续集成系统时进展缓慢。一个面向指定角色人员的、满足速度和可审计性业务需求的、进行限制的产品部署系统，克服了运营方面的阻力。实现高级的部署成熟度证实解决这个问题是值得的，因为当进行产品部署时不但产生的错误少了，而且延迟也少了。

为了支持中级和高级的部署，El Emeno建立了构建产品仓库来提供需要的可追踪性。其他的中级构建实践（例如配置库依赖、集群构建和持续构建）不在关键路径上，被放在后面来考虑。初级的构建成熟度，再加上一个可靠的工件配置库是一个不错的开始。

当审计检查和用户测试的质量不高时，团队知道错误的代价是昂贵的。一旦部署流程可以流水化，团队将优先建设测试相关的基础设施。基本的自动化回归测试将在每个构建后自动运行，以此替代测试工程师进行的手工冒烟测试。这些使得他们更多的执行探索性测试，以使他们能够发现用更少的时间发现更多的缺陷。

随着企业持续集成系统的实施，团队公认有机会在生命周期早期发现软件安全问题。在实施企业持续集成之前，所有的发布都是在生命周期后期进行安全评审。在弄清楚自动功能测试如何使得他们在开发周期内更早捕捉到缺陷后，团队决定让安全检查工具也这样。现在他们每天都使用静态分析工具进行安全扫描，虽然安全扫描通常被认为是一个高级技术，但对金融领域内的El Emeno来说却是一个很自然的事情

对于El Emeno来说，维护开发历史记录来提供一个清晰的构建日志，同变更历史记录和测试结果一样都是高优先级的。在企业持续集成实施之前，这些信息就是存在的，但是由几个不同领域的工具分散提供。当持续集成系统提供了整合的数据后，El Emeno发现他们的合作更加有效而且用时更少。当他们第一次进行企业持续集成审计时，他们能够向审计师出示任一选择部署的完整日志，构建的变更历史，自动测试的结果以及清晰的安全扫描记录。对此审计师十分满意。

El Emeno还尝试挑战更敏捷的维护控制。对于他们来说，企业持续集成是一个构建生命周期内完全端到端的可追踪的解决方案。这不需要十分复杂的自动化构建，但是需要成熟的部署和报告能力。

案例二： All-Green联合系统：大规模Scrum

All-Green联合系统在整个企业实施Scrum。All-Green不是一个软件公司，但是组织内部有一个大型的全球IT小组，开发和管理着大量关键的业务应用程序。开发人员、分析人员和测试人员组成全功能的Scrum团队，同时有一个独立的QA团队测试应用集成并协调发布工程师进行发布管理。

在企业持续集成之前，All-Green的Scrum团队发布报告是一个瓶颈：发布流程是之前的传统开发流程中的缓慢并需要仔细处理的发布流程。应用之间的sprints不同步，并且发布团队有一个来源于上一个sprints的未部署变化的backlong。

如果一个有5～10人的Scrum团队去管理All-Green内使用的大系统是力不从心的。在All-Green内，他们使用“scrum of scrums”的方式来进行大系统开发，虽然每个Scrum团队都在同一地点，但是整个项目是做分布式管理的。这些分布式的团队发现保持代码库的有效是很困难的，因为一个团队的改变往往会破坏另一个团队。另外，每个团队拥有自己的度量，但是在Sprint中却难以获得进度反馈，而且很难更好的决策出哪些故事应该在Sprint中完成。

通过评估企业持续集成，All-Green确定了两个主要的优先级，第一，改进Scrum团队之间的协作；第二，加快发布流程以便于每个Sprint都可以发布变更，同时更快的完成新功能。

在谈到构建时，All-Green中的每个Scrum团队首先进行团队级别的持续集成，再进行企业级别的集成，这个变化使得从构建角度来看，将所有团队的构建系统进行了统一以便共享。虽然有些团队仍然运行他们本地的持续集成系统，但是企业通过进行生产和协调团队活动来系统的生产软件。

如果Scrum团队之间存在二进制依赖，就在构建系统中集成一个官方的工件配置库，这样的组件共享机制比临时方法（如通过邮件进行）更平稳的、更透明。对于All-Green而言，像他们的“scrum of scrums”实践一样，他们在大系统中实施“build of builds”巧妙的构建了一个依赖树。现在变更仅在通过本地测试后才在团队之间共享，这样使得整个系统很少出现构建失败。更进一步的，如果出现了构建失败，他们能够快速的找到引入错误的团队以便他们更快的修正错误。通过如此多的团队和构建，All-Green拥有了一个分布式的构建网格。大量的机器集群使得团队在维护他们的系统时能够享受更快速的反馈。从构建角度来看，这样的系统使得All-Green的团队稳稳的处于成熟度等级中级。

All-Green中的测试成熟度是不同的，所有的团队随时间的推移不断的开发自动化的回归测试套件。他们更关注于开发新功能的功能测试，因此原有的遗留应用相对很少被测试，最新的应用有综合的自动化功能测试。遗留应用一般都是重要而经常变化，在All-Green中，更加快速的发布周期需要在“鲁棒”自动化测试上进行附加投资，对于“scrum of scrums”团队来说是通过单元测试对跨团队的边界进行额外的增强测试。

另外一个在Scrum团队间进行协调的关键元素是报告。在企业持续集成之前，即使在Scrum团队中数据都是停留在开发、测试和产品支持等各工具领域。All-Green使用他们的企业持续集成系统来打破这些阻碍，以便于他们能够在Sprint内或者跨Sprint进行端到端的数据相关性和趋势分析。这种改进报告满足了“scrum of scrums”，减少了协调开销。甚至单一的团队也通过相关的故事更了解他们的进度，并对他们的测试结果进行承诺。All-Green关于报告成熟度的另一方面是提供了全流程的包括发布团队的统一视图。

为了加快发布过程，All-Green开始在各种测试环境中自动部署。标准化团队之间的流程是我们的第一步，然后在所有的环境中遵循它；在完成所有的测试环境之后，产品的一键部署使得All-Green消除了他们的发布bakclog。在All-Green中的一些新应用具有广泛的自动化测试，并同其他的产品系统是非耦合的。这些应用都达到了持续部署的资深等级，实现了产品发布的完全自动化部署。

对于All-Green，企业持续集成通过小规模Scrum团队共同的有效工作提升了效率。不同的开发团队可以在大型系统的自动化构建中进行协作，构建、测试和开发团队能够使用共有的系统来深入了解其他人的活动。

案例三：Diversity Handhelds：嵌入式电子通信公司

Diversity为移动设备开发软件平台，这家私营公司提供产品给硬件制造商合作伙伴。Diversity必须针对不同的掌上电脑操作系统和硬件配置提供构建，一个典型的产品可能需要满足30种不同的硬件配置。

在实现企业持续集成之前，Diversity针对单独的配置进行构建和测试。由于非活动配置没有规则的进行构建，所以与工具链的冲突可能过一段时间才能够发现。这使得诊断问题的引入点是非常困难的。仔细的手工追踪有助于Diversity保留每个发布给客户的构建内容的轨迹，但是找到这些信息对于技术支持来说却是一个挑战。

当他们实施企业持续集成时，Diversity确定了几个关键优先级，最紧迫的是精心安排和管理由具备专用编译器的构建服务器和工具链组成的构建。

为了处理这个问题，Diversity实现了企业持续集成系统，使得他们可以通过一个智能构建集群进行分布构建。他们的构建集群可以检测到哪些机器上安装了哪些工具链，并进行负载均衡。在某些实例中，构建在虚拟机中进行，企业持续集成系统能够旋转适当的附加镜像文件。

因为需要跟踪发布给客户的构建，Diversity现在使用软件库来管理他们的构建工件。这样大量减少了为了发布而生成材料和发布版本说明书所需要的工作量，也减少了由同步组件所引起的错误。

因为测试的挑战性隐含了工作量的规模，中级等级的测试是Diversity的底线。在有效的模拟器中运行的自动测试，以及在最重要和代表性平台上运行的良好的冒烟测试，现在都已经具备。为了工作的效率，Diversity实现了面向模拟器和目标设备的自动部署。单元测试和静态分析作为测试的一部分随不断的构建一起运行。Diversity以后想要提升到高级等级的测试，以最大限度的利用自动化测试，确保他们的手工测试成本最优。

对于Diversity而言，高级等级的报告也是适用的。作为一个产品公司，历史发布信息是高度相关的。再加上跨领域的大型构建、数据整合和提供趋势报告，可以有助于关键资源的投入。是否对历史状态进行严格控制由项目规模所决定。对于Diversity，中级等级的报告是绝对必须的，高级等级应该积极争取。

Diversity通过数个跨平台和工具链的构建系统来生产可重复的、一致的构建。这些构建通过有效的发布构建基本报告而被追踪。被自动部署支持的自动化测试，保持高质量的跨平台特性，同时减少下一代设备交付所需要的发布时间。

补充：