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