英文原文：The Continuous Delivery Maturity Model

持续交付的原则和方法，正在迅速地被越来越多的人认可为一种真正的业务敏捷的成功策略。对于许多组织结构，问题不再是“为什么要采用”，而是“如何采用”：持续交付如何起步，以及组织机构应该进行哪些调整，才能保证得到可以接受的成果。本文介绍的这个成熟度模型，目的在于给出一个框架以及对几个关键方面的理解，这些方面是你在组织中采用持续交付时需要重点考虑的。

为什么要有这个成熟度模型？

持续交付的中心思想就在于着眼全局，去考虑影响软件开发和发布的方方面面。不幸的是，对于任何正常规模的，比较重要的业务，这些影响因素都会包括相当多的步骤和活动。从软件开发到发布的端到端过程往往冗长而笨重，牵扯到许许多多的员工、部门和障碍，使得持续交付的实现看起来力不从心。我们从哪里开始呢？我们是不是什么 都要做，有哪些部分可以省略？在哪些部分我们能得到最显著、最快速的效果？这些都是在你开始接触持续交付的实现时，不可避免会出现的问题。

这就是我们为什么要创造持续交付成熟度模型，给出结构和理解持续交付及其核心部件的实现。这种模型的灵感主要来源于我们在几个持续交付实施项目中结合起来的经验，也来自于根据这个主题选定的书籍，论文和博客文章，其中 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的方式去完成内部的沟通。这样每个元件都能够被独立的部署和发布。基于架构的成熟元件中，每个元件是一个自我保持可发布的单元，具有业务价值；你将会完成小的、高频率的发布和整个短的发布周期。在这个层面，对于业务而言，很容易去快速的发布新的特性、监测和确认预期的业务结果；所以从应用去推动业务模块的技术将会变得越来越重要，它将成为整个设计和架构的一部分。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务