持续交付的原则和方法，正在迅速地被越来越多的人认可为一种真正的业务敏捷的成功策略。对于许多组织结构，问题不再是“为什么要采用”，而是“如何采用”：持续交付如何起步，以及组织机构应该进行哪些调整，才能保证得到可以接受的成果。本文介绍的这个成熟度模型，目的在于给出一个框架以及对几个关键方面的理解，这些方面是你在组织中采用持续交付时需要重点考虑的。
为什么要有这个成熟度模型？
持续交付的中心思想就在于着眼全局，去考虑影响软件开发和发布的方方面面。不幸的是，对于任何正常规模的，比较重要的业务，这些影响因素都会包括相当多的步骤和活动。从软件开发到发布的端到端过程往往冗长而笨重，牵扯到许许多多的员工、部门和障碍，使得持续交付的实现看起来力不从心。我们从哪里开始呢？我们是不是什么 都要做，有哪些部分可以省略？在哪些部分我们能得到最显著、最快速的效果？这些都是在你开始接触持续交付的实现时，不可避免会出现的问题。
这就是我们为什么要创造持续交付成熟度模型，给出结构和理解持续交付及其核心部件的实现。这种模型的灵感主要来源于我们在几个持续交付实施项目中结合起来的经验，也来自于根据这个主题选定的书籍，论文和博客文章，其中 Jez Humble 和 David Farley 的开创性著作持续交付（http://www.amazon.com/dp/0321601912?tag=contindelive-20）和Eric Minick 与 Jeffrey Fredricks了不起的白皮书 企业持续交付模型（http://www.urbancode.com/html/resources/white-papers/Enterprise_Continuous_Delivery_Maturity_Model/） 是值得特别表扬的两个。有了这个模型，我们的目标更广泛了，扩展出超越自动化的概念，突显了你要在整个组织之间成功实施持续交付所需考虑的所有关键方面。
一种结构化的尝试
敏捷开发这场十年前开始的旅程，到今天终于在工业界站稳了脚跟。现在的业务***开始逐渐接受这个事实：软件开发有“敏捷”这么一种新的思考方式。这种思考模式的转移，如果你不介意这么叫的话，最终会不可避免地将工业界分裂为两派：一派在竞争中艰难挣扎，另一派则有能力保持敏捷，IT 组织反应快速而高效，能提供可靠的业务保证，从而在竞争中立于不败之地。在昂贵、缓慢、不可预知而过时的流程面前，IT 再次推动了革新。进入这个新领域的方法有很多，在此我们主要介绍一种结构化的尝试，以期获得***的结果。尽管敏捷方法一般被认为***从组织内部成长起来，我们发现这种尝试仍有局限性。组织的某些部门还不够成熟，无法适应和调整，因此阻碍了开发，形成了顽固不化的组织边界。要想让整个组织一起改变，***方法是建立一个稳固的平台，这个平台需要具有一些重要的先决条件，确保组织向正确的方向发展。平台需要采用特定的工具、原则、方法和实践方式，我们归为关键的5类：文化与体制，设计与架构，构建与部署，测试与证明，信息与报告。将持续交付模型根据自然的推进过程结构化为这5类，可以给你提供一个坚实的基础，来进行快速的改革并获得可接受的成果。
创建成熟度模型是为了强调这五个基本类别，并让你掌握公司的成熟度。当计划持续交付实现时，你的评估讲给你提供很好的基准并帮助你确定最快、***效率的初步行动。这个模块会指明哪个实践必不可少，哪个应该归位高级或者专家级的以及从一个基本迁移到下一个需要什么条件。
五个级别
这个模型定义了五个成熟度级别：基础、初级、中级、高级和专家级。它是基于我们可见的，现在大部分机构采用的基础级别附近的一个典型的工业平均水平为基点校准的。一些机构在某些类别达到初级，另一些（模型外）低于基础级别，但平均来说，基础级别是很多机构的典型起点。中级级别是指一个能让你受益于更大影响的持续交付实践的成熟度级别。高级级别包括那些可以产生更高实质性价值和影响的实践。***的成熟度级别：专家级包含对某些希望或需要专注特定实践的机构非常重要的实践。
层级并不是需要顺序通过的强制的阶段，但是它们可以做为评估和计划的基础。无论试图保持总体的成熟度水平公平多什么重要，一定要牢记大的变化可能会在组织里引起批评和大家的不情愿，因此推荐通过渐进的方法来推进层级的发展。
五个域（分类）
模型已经定义 了五个域（分类），这些分类代表了在实施持续的发布时需要考虑的核心的角度。每个分类都有它自身的成熟度的连续性，但是一个组织一般是逐步达到某些域（分类）的成熟度而不是只有一个或两个域（分类），因为它们上彼此关联，一定程度上相互影响的。
文化与组织
当目标是创建一个稳定的持续发布环境时，组织和它的文化是需要考虑的重要的角度，这个环境会受到它们的影响。
基本阶段
典型的组织在基本阶段，开始在后台日志进行优化工作，定义了一些流程，这些流程进行了简单的文档化，开发人员习惯了经常提交版本控制。
初始阶段
进入初始阶段，项目团队是稳定的，组织逐步开始移除测试之间的边界。大量的后台日志自然而然的合并到每个团队，基本的敏捷方法已开始应用，相对健壮的团队已共同体会到了糟糕的事情发生时的痛苦。
中间级
在中间级你将会收获一个扩展性更好的团队合作，数据库管理员、配置管理员和运维人员开始成为团队的一部分，或者至少团队频繁的与他们沟通。多个流程已经稳定，所有的变更、问题、新功能、紧急修复等都依照相同的方式进入生产环境。决策分散到项目团队，组件的所有者已经定义了，这些使得项目团队可以高质量的构建，可以为持续的生产和过程改进制定计划。
高阶级
在高阶级，团队有了能力和信心，它需要自始至终为产品的变更负责。持续的改进机制是适当的，例如成立了专门的工具团队通过改进工具和自动化来为其它团队提供服务。在这个阶段，功能的发布可以与实际的布署相分离，这会给项目产生不同的角色。一个项目可以关注于一个或多个团队的产品需求，当所有的或者相当数据的需求已被验证并布署到生产环境，项目组应当计划并组织针对不同用户的实用版本。这种关注的分离优化了项目打包和发布功能的的灵活性，同时使得开发团队更好的跟进产品，因为他们不需要累加变更，不需要因协调项目的发布而等待。
专家级
在专家级，一些组织选择花费很大的努力形成完整的跨职能的团队，这些完全是自发的。因为有极短的迭代周期和相当成熟的发布通道，这样的组织有信心适应相当严格的从策略到产品推进的失败率要求。
设计和架构
你的产品和服务的设计和架构将对持续发布产生至关重要的影响。如果从一开始，一个系统的构建是依照持续的发布通道，有一个快速的发布心态，那么这个过程会相当的平滑。然而，超前完成重构整个系统对于大多数组织而言并不是一个理想的选择，这就是为什么我们要把这个分类包括到成熟度模型中的原因。
基本级
通常一个组织会有一个或者多个包含了开发、构建和发布的完整功能的遗留系统。在基本级的许多组织会有一个多样的技术栈，但是已经开始巩固这些技术方案和平台，这对于从已花费在自动化上的许多努力来获取***的价值来说是相当重要的。
开始
在开始阶段，系统的单片结构就采用将系统分成模块的方法解决的。模块给开发、构建和部署提供了很好的结构，但是不能像元件一样单独的发布。做这些也将会驱动一种API的管理方式去描述内部的独立性，也将会影响运用结构方式去管理第三方的库。在这个阶段，运用版本控制数据库的改变的重要性也将会揭示这一点。
中间层
移动中间层将会导致固定的架构基础。这样做是为了当采用抽象方式的分支和其他的技术特性能够隐藏（隐藏的目的是减小仓库的分支，去确保真正的持续性集成）时候，能够提供持续性的交付。这一层的工作是模块化，它将用于鉴定和分割模块成元件，元件是具有自我保持和分开部署的特点。在这个阶段，它很自然会开始分散的迁移、特设管理应用和运行时间配置到版本控制中，将它视为像其他代码一样的应用中的一部分。
高级
在高级阶段，你将会把整个系统分成自我保持的元件，采用严格的基于API的方式去完成内部的沟通。这样每个元件都能够被独立的部署和发布。基于架构的成熟元件中，每个元件是一个自我保持可发布的单元，具有业务价值；你将会完成小的、高频率的发布和整个短的发布周期。在这个层面，对于业务而言，很容易去快速的发布新的特性、监测和确认预期的业务结果；所以从应用去推动业务模块的技术将会变得越来越重要，它将成为整个设计和架构的一部分。
专家级
在专家级，一些组织进一步引入了基于架构的组件和评估尽可能多的削减共享基础架构的完善性，这样就可以把基础架构做为代码把它与应用组件关联起来。这将导致相对于源代码控制、操作系统，系统完全是可以重写的，可以直接重用到应用程序。这样降低了工具和一些技术的复杂性和成本。例如对生产环境的灾难恢复变得相当容易。不必有一个单独的流程，灾难恢复只是简单的从通道中像抽取其它版本一样，抽取它的上一个版本。与此同时虚拟化使得搭建测试和生产环境相当的灵活，只需要很少的人力成本。构建 & 部署
对于持续交付而言，构建和部署无疑是核心。在这个过程中，很多工具和自动化被应用进来；一旦持续交付被论及，这个过程也是最常被认知的。乍看起来，一个典型且成熟的交付方式是非常具有压倒性优势的；但鉴于组织中当前构建和部署的成熟程度不同，该交付方式的复杂程度或大或小。从这个层面来说，我们将描述一个有逻辑的成熟的过程，为不同的部分和环节提供结构知识来方便理解。
基础
基本上，你将会拥有一套代码库，它是受版本控制的、被脚本化构建的，同时它定期运行在一个专用的构建服务器上。部署的过程是个手工或者带有部分脚本和基本记录的半手工过程。
初学者
初学者水平介绍了为了更快的反馈而进行频繁的轮询构建，为了更易于依赖关系管理而将构件存档。标签和版本的构建是结构化的，不过手册和部署的过程，连同文档、脚本和工具，正在逐渐变得更标准化。
中间级
在中间级水平上，构建通常会在源代码控制系统的每一次提交中被触发，即尝试把一项细节提交到一个特定的构建中。标签和版本的构建是自动化的，部署的过程在所有环境中是标准化的。构件或者发布包只被构建一次，且被设计成可以部署在任何环境中。标准化的部署过程还将包含一个为自动化数据库部署（或者迁移）提供的源码。这个源码中包含大量的数据库修改和脚本运行时配置的修改。一个基本的交付通道恰好涵盖了从源码控制到生产的各个阶段。
高级
在这个阶段，它也可能成为向外扩展的构建所必需的，这里说到的构建是在多台机器上为了并行处理和特定的目标环境所进行的构建。零当机部署的技术可以是重要的，包括自动化过程中获得更好的灵活性和在发布时降低风险和成本。在这个层次上，你可以探索那些能够使更复杂的数据库更改和迁移变的自动化的技术，来完全避免数据库更新时的手工惯例。
专家级
专家级的实践特征之一是无接触的持续布署到产品，每条命令都可以自动化的运用到产品中。专家级实践的另一个特点是把架构做为代码，进一步的虚拟化，使得构造过程不仅布署了人工的部分，还完成了虚拟机，该虚拟无须停掉下层通道，直接替换现有的虚拟机。
#p#
测试与验证
测试无须质疑对于任何一软件开发都相当重要，它绝对是实现持续发布的至关重要的重要部分。与构造与布署类似，这个类别的成熟度包括了工具与自动化。然而，同样重要的还有持续的增量的对应用的测试覆盖，这构成了快速发布的可信度。通常测试包括了用不同方式依照需求验证期待的功能，但是我们同样需要强调验证预期的发布的版本特征的业务价值的重要性。
基本阶段
在基本阶段的成熟度模型中，开发团队或者开发组织通常会实践单元测试，有一个或多个专用的测试环境，这些环境与本地的开发机器是分离的。这些系统和整体层测试都会由一个单独的部门执行，在开发代码冻结后持续的开展一个长期的、冗长的测试周期内执行。
初始阶段
在进入初始阶段后你将自然而然的开始研究渐近的自动化，通过自动化使现存的人工的集成测试快速的反馈，使得回归测试更易于理解。为了精准的测试，组件必须在与产品类似的环境中布署和测试，这个环境要包括所有必需的依赖条件。
中间阶段
初始阶段中你把自动化测试的范围扩大到功能测试，包括了比单元测试更大的组件，但是会使用桩来实现它的外部依赖，例如数据库或其它后台服务。当你在一个高度基于组件的架构中工作或者好的完整的集成测试的实施相当困难或者运行频度太慢时，这些测试是相当有价值的。在这一阶段你将可能开始把接收测试的一些部分逐步的自动化。集成测试是一些特殊的组件，接收测试是扫描大量的组件并跨越多个系统。
高级阶段
高级阶段的实践包含完全自动化的验收测试和从需求中可能直接产生结构化的验收标准，需求的详述是通过案例和特定领域的语言来完成的。这意味着没有测试手册用来测试或者验证，验证就是需要通过验收，但是典型的处理还是会包含许多探索性测试。通过这种探索性测试反馈到自动化测试中，不断地改进测试的覆盖率和质量。如果你关联测试的覆盖率与更改的可回溯性，你就能实践基于风险的测试，为指导探索性测试带来更好的价值。在高级阶段，许多机构可能会持续关注自动化的性能测试和针对安全的扫描。
专家阶段
这样的表述可能看起来很特别，验证期待的商业结果是一个专家级的实践过程，但是这很实在的东西。现今，一个自然而然的开发和发布过程，很少会去做这样的一个验证。当组织，文化和工具已经达到一个成熟的阶段，验证改变所带来的商业价值变得更为自然而然，并且相关业务标准的反馈是高效化的和易操作的。以一个新特性的实现为例，必须包含有效的方法通过确认相关指标去验证期待的商业结果是推进还是拉低了应用的效果。完成的定义必须被扩展到当发布的特点和更改的效果被商业分析之后。
信息和上报
任何的商业过程都包含一个特殊的可以被上报的信息集合。软件的开发和发布过程也不例外，并且在这个领域的信息集合包含一些特定的概念包括组件，需求，版本，开发者，发布，开发环境等等。当采用持续交付模型时，我们希望在这个分类里针对重要的处理能显示正确的信息。信息必须简洁，切题和易于理解，还要在对的时间，对的人，为了获得完全的速度和可能的灵活性促进持续交付。除了通过开发和发布新特性来让信息直接被用于实现业务需求，同样重要的是获取信息需要测量过程的本身,并不断改进它。
基本阶段
在基本阶段，在分类中最重要的是为当前的过程建立一个基础的指标，这样你就可以评估和跟踪。在这个阶段通常是手动去做并且需求是由个体决定。有趣的指标例如：循环周期，交付日期，发布个数，紧急修复个数，事件个数，每次发布的特性个数，集成测试期间发现的bug等等。
初级阶段
在初级阶段，开始衡量进度并跟踪绩效，有助于更好地了解哪里需要进一步改善，以及获得的改善是否是期望的结果。在这个阶段获得的报表包括代码的静态分析，并且这个报表必须是周期性的，才能保证用***的报表来辅助决策或者发现哪里需要改进。
中级阶段
到了中级阶段，你必须建立一个通用的信息模型，用来标准化所有概念的含义，以及定义好它们之间的联系。模型经常能回答类似的问题： 什么是组件？ 改变组件有什么需求？不仅模型可以自动构建，测试和部署，并且你能建立可追溯性和信息透明度，自动生成发布信息和测试计划。对事件的自动报告和反馈也实现在这个阶段，同时这个阶段也会存储关于构建和其他事件的历史报告。这些报告能为管理层提供信息，进而调整流程和优化工作流和工作量。
高级阶段
在高级阶段，当你开始频繁发布和加工时，生产和服务变得足够成熟。例如：商业指标被自然地设置成图形化，这个时候，人们可以得到特定的实时信息，而且这些信息是他们特定需要的。在这个阶段，实时图形和其他的报告手段通常是随着时间的推移反映整体趋势。作为静态代码分析和单元测试覆盖报告的辅助，在这个阶段你可能会开始关注动态测试覆盖和来自产品的分析信息，类似运行时环境，例如：当运行自动化集成测试的时候。
专家阶段
至此，在这个分类中，专家阶段通常包含改进的实时信息服务，它提供动态的自助实用信息和自定义的控制面板。这样你就可以通过不同的组织边界交叉引用和关联报告及指标。这样，信息就能让你开阔针对持续改进的视角以及更易于验证改变所带来的商业结果预期。
跳转到开始的行程
每个公司都是独特的，当涉及到改变工作方式，如实施持续交付时，都会遇到特定的挑战。成熟度模型给你了一个起点和计划公司向持续交付转型的基础。根据该模型评估您的组织之后，你需要设定目标，并确定哪些实践会给您的组织***的结果。如果有一些实践你不想采取，你需要分析不采取他们的后果。决定实施策略是同样重要的，例如你能从小事开始利用淡季在已存在的过程中一次提高一件事情。然而，从我们的经验，你将有一个更好的成功实施的机会，如果你跳转到开始的行程，有一个专门的项目有明确的命令和积极的目标例如降低循环时间。一个典型的持续交付实施项目需要的技能和能力是根据成熟度模型的分类和实践，以实现一套让组织能持续成长和完善的工具、方法和实践的坚实平台。
（点击放大图片）
关于作者
Andreas Rehn 是一个企业架构师，也是持续交付，开发运维，系统开发敏捷和精益方法的积极倡导者。在软件开发许多学科有丰富的经验，并对信息和管理的理论与实践流程有深刻的理解。他致力于帮助客户实现持续交付，并采用高效的和现代的软件开发新方法改造他们的业务。
Tobias Palmborg 认为持续交付描绘了Scrum，极限编程和敏捷宣言曾打算的愿景。持续交付不只是关于自动化发布渠道，而是在一种艺术形态状态里，如何获得类似从面粉到面包的完整变更的流程 。他是一个欧洲***的在线游戏公司的前主管。Tobias目前正在为几个客户实施持续交付的项目。
Patrik Boström 是Diabol的创始人之一。 高级开发人员，有大型系统的操作经验的架构师。他坚信持续交付和开发运维是敏捷和精益运动演化的自然的一步。要改变我们今天看系统开发的方式，要变化到下一个级别，我们将更多的时间在开发功能而不是手工做重复性的任务的级别。从下一级别中可以想像和理解从构思到它发布并带来商业价值的道路。
英文原文：The Continuous Delivery Maturity Model
译文链接：http://www.oschina.net/translate/continuous-delivery-maturity-model
