持续交付流程成熟度

原文：

http://www.ibm.com/developerworks/cn/rational/1402_zhaojing_urbancode1/

企业当前的持续交付流程成熟度如何？有没有哪些地方能够改进和提高？下面我们一起了解企业持续交付的成熟度模型。该成熟度模型来源于 Eric Minick 和 Jeffery Fredrick 两位专家，他们拥有多年的一手资料和实际经验，形成了一套企业可以借鉴和参考的持续交付成熟度模型。（http://www.urbancode.com/html/resources/white-papers/Enterprise_Continuous_Delivery_Maturity_Model/）

企业持续交付成熟度模型说明

不同的行业和企业，对于持续交付的理解和应用场景是不尽相同的。只能寻求到他们的共同点和主要特征。为了便于描述，我们选择了 4 个通用环节，来记录和分类企业的持续交付过程，它们分别是构建、部署、测试、报告。在每一个环节中，又根据该环节所常见的一些实践，以及企业对这些实践的应用程度，形成了 5 个成熟度等级。这 5 个等级分别是基础级、起步级、中间级、高级、领先级。同时，在每个环节中，还根据实际经验，标示出了行业普遍能力以及应该达到的目标能力。有了这样的成熟度模型，企业就可以方便的衡量出自己现在处于什么位置，离行业普遍能力有什么偏差，目标能力应该是什么，从而快速找到采取什么行动去弥补差距，实现目标。如图 3。

图 3 .持续交付成熟度模型图

企业持续交付成熟度模型详述

构建环节

大部分新项目开始时，都是由开发人员在自己的机器上执行构建，而且没有一个标准的流程。一个开发人员在自己的 IDE 上进行构建而其他人可能用写好的脚本来做这件事。最糟糕的企业会容忍这样的方式做构建、测试甚至就将这样的构建发布到生产环境，如果这样，企业就连基础级也没有达到。

图 3 .持续交付成熟度模型分解图--构建环节

从空白水平到基础级：首先，需要做的是在专用环境下（如专用构建服务器）进行构建，而不要使用开发人员的机器去执行。不使用开发人员的机器去构建，可以很好的避免由于个人机器环境、个人工作空间等问题导致的构建结果不确定问题。其次，需要标准化目前的构建脚本（或流程），让其更为统一和固定。比如，如何从源代码控制系统中取到构建源，在实际中有多种实现，可以取构建分支上最新的版本，也可以取打过标签或基线的版本，也可以从某一个目录中找到。这些方法必须统一，并且形成标准规范。

从基础级到起步级（行业普遍能力级别）：有了专用的构建服务器和规范的构建脚本之后，需要考虑的是自动化。首先，构建服务器必须随时待命，等待开发人员进行自助式构建，开发人员需要指定的仅仅是代码存放的位置，而其他诸如机器（构建代理）、源代码获取规则、构建规范等都应该由构建服务器统一分配和安排。其次，这种自动化构建需要支持每日定时执行，允许一些团队或个人按照自己的需要一天一次或多次自动执行。最后，所有构建前后涉及的工件都应该被存储。包括构建源代码、构建标签、构建各种配置文件及属性、构建脚本（步骤）、构建结果、构建日志等。

从起步级到中间级（目标级别）：在这个级别，自动化已成为基础，需要让构建变得更有价值。首先，实现持续构建，并且每个开发人员和团队都可以使用该实践。也就是说，只要他们一提交代码，就可以自动触发构建过程；甚至当互相依赖的代码模块发生变化时，也能自动触发构建过程。其次，需要更为清晰的管理软件模块之间的依赖关系。不像之前使用约定俗成的方式，现在需要利用专门的工具去真正存储这种依赖关系并能在构建时跟踪和快速定位。这样，不仅能管理软件模块之间的依赖，还可以管理构建和构建之间的依赖关系，并把这些关系都存储在一起。最后，所有存储的构建（在网络存储设备上或者就在构建服务器中）都应该有机制保证定期被有效的清理或被正确版本化，便于将来快速利用。

从中间级到高级：更为规范的企业和团队希望采用更加可控的构建流程，能够把质量因素放进去。首先，此时的构建是可以跟踪的。团队可以针对任何一次构建（无论成功或者失败），跟踪到本次构建用到的源代码变更、计划的变更甚至需求的变更，同时，也能够方便的查看本次构建相关的所有依赖关系。其次，更加严格的管理。构建流程的修改、对构建服务器的访问、构建服务器的配置变更都需要审核和批准行为。另外，针对大型分布式的构建也需要提供支持，使用分布构建服务器去并发执行大量构建。高级阶段由于过于严格，所以建议应用在有遵规需求的企业或者针对于生产系统进行的构建部署上，其他企业/团队或更早期的阶段能做到中间级就已经足够。

从高级到领先级：有一些更为严苛的企业，他们要求能够在需要时针对早期的发布（构建成功后交付的结果）执行完美的重新构建。这就需要使用各种技术来确保重构时具有和当时一模一样的环境来保证成功。可以采用管理版本化的脚本，该脚本包括从准备操作系统到执行构建这样一个完整过程，也可以使用基于快照的虚拟机并对快照进行版本化管理来实现。目前大部分企业没有达到这种级别，因为要实现这样完美的效果需要承担很多额外的负担，如资产管理、人员投入、技术支持等，这对大部分企业来说投资回报率很低。

部署环节

部署就是将软件安装到一个环境中，对其进行配置或测试以保证能够被最终用户正确使用。如一个 Web 应用的部署，就是将其安装在 Web Server 上并更新数据库或者 Web Server 上的静态属性文件；而对于一个游戏应用而言，测试环境的部署是将其正确安装在测试机器上并执行，而生产环境的部署可能还要包括为软件建立 ISO 文件以便于客户安装使用。

部署流程最初始的形态也是手工过程。部署工程师拿到构建成功后的工件，把它放到目标环境中，通过运行事先准备好的安装手册来执行部署。这不仅很慢而且非常容易失败。部署工程师经常不得不在晚上或者周末进行风险极大的生产环境部署，即便是在测试系统上部署，如果测试人员正在进行测试，他们也不得不等待。更为糟糕的情况是，针对不同的环境，部署过程都不一样。即便在一个环境上部署成功，也不意味其他环境也同样顺利。如果企业是这样的现状，就连基础级也没有实现。

图 4 .持续交付成熟度模型分解图--部署环节

从空白水平到基础级（行业普遍能力级别）：在这个阶段，最重要的是脱离完全的手工操作。能够采用一部分有帮助的脚本或者完全采用脚本进行部署可以看做是一个重要的水平提升。从目前业界情况来看，大部分企业或团队都有部分的部署脚本，然而很少能实现完全的脚本化部署，尤其是在更严格的 SIT、UAT、生产环境上的脚本化部署。

从基础级到起步级：在这个级别，测试环境的部署管理统一化变得非常重要。需要为开发或测试人员提供可以让其自助部署的测试环境。他们仅需要提供待部署工件并对测试环境有访问权限，就可以提交部署并自动完成一个部署过程，而测试环境的部署步骤是统一设计并提供的。

从起步级到中间级：开始实现一键式部署。利用自动化部署工具将部署脚本固化，并采用一键式方式在一个或所有测试环境中进行自动化部署。部署工程师的工作量和风险大为减轻，测试人员也有更多的时间进行无间断测试。另外，企业开始进行部署流程的全面标准化，可以使用统一部署流程跨各个环境进行部署。环境也许仍然有细节上的差异，但是在早期能够验证部署流程的正确性，已经可以为后面的部署带来预测性的结果。对于大部分企业和团队而言，达到这个级别已经是个不错的目标。

从中间级到高级（目标级别）：在这个级别，关注点是更为严格可控的流程和生产环境。生产环境的部署也可以实现一键式，而且一旦出现问题会自动触发灾难恢复流程。同时，该级别也需要引入质量门的概念，保证跨环境的部署是严格受控的。如果是实施项目式交付，也就是生产环境的部署是在企业内部，那么应该将这个级别作为目标级别。

从高级到领先级：真正实现持续部署。可以不用手工干预的将软件构建从测试环境一步步推送到生产环境。在这个阶段，企业已经实现了自己的持续交付管道，并在管道中的每一个阶段都配有完整的自动化测试手段，一旦构建通过了所有质量门，就可以被成功、正确的自动部署到生产环境。对于一些需要快速响应变化的行业，比如互联网企业，通常变更的实现是以小时为衡量，这就要求必须具备完整的自动化部署流程、成熟的自动化测试手段、严格的环境管理和回滚流程、应用部署监控等全面的保证手段。

测试环节

持续交付管道在各个环节都离不开测试。仍然有一些企业和团队对测试不足够重视，执行构建后仅简单的测一下就部署在生产系统中。大部分企业都采用了某种程度的自动化测试--单元测试或一些测试脚本来保证应用的基本功能。能够采用和适应自动化测试的企业，已经处于基础级了。

图 5 .持续交付成熟度模型分解图--测试环节

从基础级（行业普遍能力级别）到入门级：在构建的同时可以执行快速测试，为团队提供基本的代码级质量信心。当测试失败时，开发团队可以实时得到通知以便快速修复。能够实时通知和实时反馈是这个级别的重要判断准则。

从入门级到中间级（目标能力级别）：测试多样化。不仅仅可以提供在构建时的快速代码测试，还可以提供源代码静态分析测试、自动化的功能测试。源代码静态分析可以根据企业遵规需要去设计，也不需要每次构建都执行，定期或者在里程碑阶段自动进行并对违规进行修复后才能真正发布版本。

从中间级到高级：该阶段拥有完全的测试类型和能力。每一种测试类型都能充分使用并最大化发挥其价值。定义一些质量标准，单元测试可以覆盖几乎所有代码模块并达到定义的覆盖率；功能测试能实现定义的需求覆盖率；静态代码分析运行的频率更高；引入边界测试、随机测试、安全扫描、运行时分析等测试手段。该级别对大部分企业和团队来讲，已经足够。

从高级到领先级：实现 100%代码覆盖率。也就意味着每一行代码都要被验证过。这种程度的实现需要大量的资源投入，只有对某些企业，如缺陷的修复成本极高或者需要极速交付的企业。

报告环节

报告是一种反馈机制。无论是手工报告还是自动化报告，都可以一定程度了解企业当前持续交付管道各种维度的度量信息。没有报告或者不关注报告的企业是无法进步的，因为所有的测试如果不去了解和分析其结果都是没有价值的。对报告环节的成熟度定义是根据报告的可视范围以及对其利用的程度。基本所有的构建工具都能产生一定程度的报告，开发人员在进行构建时可以看到构建的时长、日志、单元测试结果、成功或失败、趋势等信息，并能够根据这些报告进行个人工作的修正。这样的企业处于基础级。

图 6. 持续交付成熟度模型分解图--报告环节

从基础级到起步级（行业普遍能力级别）：报告在团队中可以共享。这和集中管理构建服务器、部署服务器相辅相成。团队中的每个角色--开发、测试、构建、部署工程师都可以运行并发布他们的执行结果报告：构建人员可以提供代码变更报告、源代码分析报告、单元测试报告等；测试人员可以提供最新的自动化或手工测试报告；部署人员可以生成缺陷报告、部署趋势和速度报告等。但此时报告仅能在团队中快速共享，由于是不同的工具产生，跨团队和部门的报告还需要手工实现。

从起步级到中间级：该阶段有两大重要变化。首先，关键的报告已经可以跨部门共享，这里的共享并不是指报告的互相交换，而是数据的贯通。比如测试人员可以深入到开发内部去看，这次测试的失败源于哪些变更，甚至是对哪些代码行的变更。每个人都可以清楚的了解到持续交付管道中上下游的信息，这时候沟通的成本更低，效率大为提升。其次，对于历史报告的重视。历史报告可以被存储并能用于和最新的结果进行对比。测试团队不仅想知道本次测试拥有 95%的通过率，他们还需要了解本次测试新增了哪些用例、减少了哪些用例，为未来的测试用例设计带来指导性意见。

从中间级到高级（目标能力级别）：能够利用报告观察数据趋势，让报告带来更多决策价值。中间级可能记录了每次测试失败或成功，而高级能力则可以基于这些形成趋势信息，可以通过趋势分析出哪些代码的变更更容易导致单元测试或功能测试失败。这反过来又能帮助企业决策应该在哪些代码模块设计更多的测试，甚至是否需要对代码进行重新设计。能够跨部门的根据趋势报告和其他多种报告来进行决策和校正，是持续交付管道建设的一个重要目标。

从高级到先进级：通过报告进行预测。整合各个部门或者团队的数据和信息，生成具有多种度量元的报告，并能对今后的部署带来指导和预测。比如根据里程碑 1 的缺陷数量、代码修改量、代码复杂度、构建结果等综合信息来预测里程碑 2 时的相关数据。这样的能力保证了企业可以按照可持续的、良性的节奏实现持续交付。

企业持续交付成熟度模型的意义

持续交付成熟度模型，可以作为企业的一种参考，快速判断自己当前的状态、行业普遍具备的能力，并制定符合自己的改进目标。它把一个复杂的过程，经过不同环节和成熟度等级的划分，用一些可以衡量的实践落到实处，帮助企业意识到建立自己的持续交付管道和能力，可以通过在不同的环节逐步引入不同的实践，验证这些实践并优化它们。

该成熟度模型的另一个重要意义在于，调研和实施持续交付时，企业或团队需要有一个正确的期望。级别是随着能力不断完善而逐步优化的，不能简单的认为可以通过一个自动化的工具或者平台，就能够一步登天。另外，对自己当前的能力要有正确和深刻的认识，不是所有环节的高级和领先级都是最适合自己的，盲目的去追求更好的等级，只会无谓付出更大的代价和较低的投资回报。只有真正了解自己当前的水平和现有的能力，设定并真正实现切实可行的目标，并在日常工作中注意培养团队向下一个目标迈进的能力，才能一步步优化和提升。