今天准备谈下DevOps能力成熟度模型，重点是敏捷开发和持续交付两个域。

研发运营能力一体化能力成熟度模型是国内外第一个DevOps系列标准，由中国信息通信研究院云计算开源产业联盟（OSCAR）联合多个单位行业顶级技术专家100多名共同编写制定，为了让更多的企业能复用DevOps领域领先企业积累的先进技术。

该系列标准分为敏捷开发管理、持续交付、技术运营、应用设计、安全风险管理、组织结构及系统和工具等部分，涵盖了软件开发到运维的全生命周期，如下图：

DevOps起源于2009年，主要针对敏态业务，DevOps没有发明任何技术，但所有的技术都为它所用。因为DevOps是一个概念，它从技术上升到业务层，会建议你组织结构的变革。

整个评估模型我可以看到融入了多方面的内容，核心是如下三方面

• 研发项目管理和敏捷研发方法论
• 软件工程，特别是持续集成方法论
• IT管控和治理，包括对原来ITIL思想体系融入

在这三方面以外，我们又看到整个成熟度评估里面很多评估要求的达到本身又希望你采用微服务架构思想，通过容器云来实现持续集成和交付等。这也和我们经常谈到的，微服务和容器云是实践DevOps的另外一个关键要素。

敏捷开发管理

 

如果做过CMMI或敏捷项目管理的可以看到实际上在当前DevOps成熟度模型中的敏捷开发管理还是相当粗的，而且是将软件工程域内容和过程管理内容融合在了一起，同时也可以看到其核心还是基于Scrum敏捷项目管理方法论而展开，只是更加强调了业务场景驱动和价值交付的重要性。

DevOps持续集成和交付本身就是为了更加敏捷响应需求，快速短周期的迭代交付，因此和敏捷方法论配合是自然的事情。同时也可以看到要实现敏捷，需求必须细粒度化，同时需求本身需要体现业务价值，而要做到这点核心就是基于业务场景分析出来的用户故事和用户故事地图。

用户故事地图和对Backlog清单跟踪改进

原来我们谈的就是用户故事，Product backlog和Sprint backlog，先形成产品backlog，同时评估优先级和功能点复杂度，然后将不同的用户故事分配到具体的sprint backlog里面形成当前的迭代版本。将用户故事进一步细化为不同的工作任务项，将工作任务下达到具体的人员执行。

在整个过程中基于backlog列表形成从需求到开发到测试的完整端到端跟踪和验证。

用户故事本身就是业务需求的实现，因为围绕用户故事的管理实现完整的业务价值交付。

当我们看到这些用户故事地图的时候，我们发现这种地图方式很好的解决原来backlog清单的单维度问题，形成了一种二维的可视化视图结构。将具体的用户故事内容很好的呈现在一个二维坐标体系里面，其中一个坐标是业务活动和任务，一个坐标是具体的迭代版本。

同时我们对用户故事本身也形成了完整的层次结构，即

业务活动-》业务任务-》用户故事点

对于用户故事点，我们可以看到也叫最小化用户故事，而这个在我们多年前实施scrum敏捷方法论的时候并没有这样去管理，往往用户故事点还是偏粗，而是在任务安排上对用户故事点进行了细化。而在新的模式下可以看到用户故事点更加细化，是一个最小的功能实现点。

最小化用户故事点也可能不能独立交付，但是这不影响我们细化到最小化用户故事点进行管理。这种最小化用户故事点真正解决了我们原来遇到的两个问题，即对于同一个用户故事，用户故事本身不能再进行细分的，但是用户故事本身又包括了很多扩展边界，或者说用户故事本身包含了扩展业务规则逻辑，而这些在新用户故事视图模式下都可以进行可视化呈现，并分配到不同的迭代版本进行管理。

比如对一个简单的发送邮件用户故事，我们就会存在很多的小用户故事点，比如支持发送附件，支持发送图片都是扩展故事点，而对于发生时候需要校验邮箱有效性可能就是扩展的业务规则点。这些我们都需要进行管理并跟进优先级安排到不同的迭代版本去实现。

在用户故事地图里面有一个关键行，即一级用户故事，它们组成了用户故事地图上的行走的骨骼（the walking skeleton）部分。而对于一级用户故事，我们也可以看到，正是我们原来在sprint backlog里面管理到的用户故事粒度。

而在一级用户故事上面，还有一层即user activities用户业务活动层，而这层实际上也相当关键，通过这层我们可以将我们的用户故事真正和实际的业务场景，业务流程和活动关联起来。通过这种图也可以很清晰的看到我们实现的用户故事究竟体现在哪个业务流程或业务场景中。

对于这两层的构建，实际上也是存在两种方法可以考虑。

自顶向下：从业务场景和流程分解入手，先梳理定义清楚业务活动，再细分一级用户故事。

自底向上：先头脑风暴形成一级用户故事，然后再向上抽象归类形成业务活动层。

就这两种方法来说，自顶向下分析可以确保更加完整无缺漏，而自底向上方法往往则更加快速和敏捷。具体采用哪种方法进行需要根据项目团队实际情况来综合考虑。

在形成了业务活动和一级用户故事后，剩下就是对一级用户故事进一步拆分为最小化用户故事，最小化用户故事是否作为任务直接下达需要看我们研发项目任务管理的粗细度情况，在这里并没有明确的标准和要求。如果跟踪管理的细，持续集成过程也高效快速，那么就可以到最小化用户故事，否则就到一级用户故事。

实际上在一级用户故事的拆分上，还可以借鉴我们原来用例建模的经验，将最小化用户故事分为三类故事场景，即核心用户故事，扩展故事点，业务规则逻辑故事点并分别进行管理。其中对于核心用户故事点优先级最高，必须在第一个迭代周期实现，扩展故事和规则故事点也必须要依托核心故事点而存在。

而对于敏捷开发或敏捷项目管理，如果要用一句话来总结的话就是，基于业务场景和用户故事驱动的短周期迭代和项目团队高效协同，以实现快速的业务价值交付。而这个目标下我们经常谈到的可视化看板，站立会议，燃尽图等也仅仅是实现上述目标的工具。

也正是这个原因我们看到，要进入到敏捷开发过程管理，形成基于业务场景形成具备优先级划分的细粒度用户故事至关重要，这将直接是我们后面迭代计划安排，测试用例编写，交付交付的基础。

下面我们还是根据成熟度模型里面对敏捷开发管理拆分的三个子过程域分别来谈下。

01-价值交付（需求工件，需求活动）

价值交付管理包括了需求工件和需求活动两个部分内容，体现需求管理过程中的分析，测试，验收三个阶段。价值交付管理主要体现在各个环节中实现敏捷方法探寻用户问题和诉求，业务价值，并定义有效产品功能的能力，适应需求变化的能力，快速验证反馈的能力。

01.1 需求工件

对需求和用例的管理，可以看到包括了需求内容，测试用例，测试用例验证，测试用例管理，覆盖了前面谈到的需求->测试-》验收完整线条，而里面核心又是用户故事。

01.2 需求活动

包括了需求分析和需求验收，而需求分析是将产品需求具体化，形成代办事项列表的过程，或者说需求分析重点就是要形成用户故事清单，而且估算故事点，评估优先级为后面形成迭代计划做准备。形成迭代计划后才可能对应到后面的验收是多次验收，多次交付。

对应需求工件和用户故事的形成，思考了下，更加值得参考的做法应该是

1. 基于业务场景分析梳理业务流程，识别关键业务活动，并识别一级用户故事
2. 基于识别完成的一级用户故事来进行原型设计和开发
3. 基于原型设计再进一步的分解一级用户故事，形成最小化用户故事和优先级(完整用户故事地图）

这种方法和步骤可以更好的将业务场景和流程和我们实际的业务功能实现结合在一起，将具体实现的业务功能匹配到核心业务价值实现上。这才是我们谈到的价值交付而不是单个功能点交付。

同时上面这种方法我们还看到进一步将需求分析过程和我们后续的产品规划和迭代版本计划过程紧密的结合在了一起，由于用户故事具备优先级，在进行优先级分析过程中结合到迭代版本计划安排，在故事点估算过程中分析具体的工作量，这些都为后续的版本计划安排和任务下达奠定了基础。

而对于需求的管理，里面谈到的比较粗，对于需求的追踪，需求的变更管理，需求的发布计划，需求的验证等都应该属于需求管理的范畴。只是在敏捷开发过程中的需求管理，更加强调围绕用户故事形成一条线的端到端管理，并实现价值交付的目标。

02 敏捷过程管理（价值流，仪式活动）

敏捷过程管理是产品经理，研发团队以及与产品相关的干系人围绕业务价值交付进行的软件研发过程，包括价值流和仪式活动两个部分，要求上述人员建立以尽早和持续的交付价值的软件为目标，通过高效的沟通方式，高效的可视化工作流，有效的度量和快速反馈机制，实现软件研发业务价值最大化。

02.1 价值流

将软件产品转化为业务价值的能力，包括按照用户地图按需交付可用的软件，同时包括了交付质量管理，交付度量，和持续的价值流跟踪。也就是说这里面入口是用户故事地图，然后是可视化的交付全流程的跟踪和反馈，其次是在整个过程中还需要围绕价值交付建立有效的度量和评估机制。

02.2 仪式活动

通过建立价值流动的管控机制，可视化的管理价值流程，控制流动节奏，不断提升价值交付效率。包括各类计划会议，评审会议等。这个可以进一步参考敏捷过程管理中的一些最佳实践。

简单来说敏捷过程管理核心是可视化，管控机制，度量机制，高效的协同和反馈机制建立。所有的这些机制建立都又是围绕价值交付服务。

03 敏捷组织模式（敏捷角色，团队结构）

敏捷组织模式是指团队在研发过程中的角色定义，角色能力以及之间的协作，团队结构的工作方式，团队间的协作模式等方面的要求，主要从敏捷角色和团队结构两个方面进行定义。

03.1 敏捷角色

指产品经理，敏捷教练和团队之间的职责分工，能力提升和协助方式，角色都能够以价值交付为目标，持续的提升交付效率。

敏捷教练在深刻的理解敏捷的价值观的基础上，同时需要具备丰富的敏捷技术实践经验，以及拥有基于团队的实际情况采用合适的敏捷实践的能力。这里面实际包括了需求分析和拆分，用户故事地图，需求影响分析，故事点故事，需求优先级评估，迭代计划安排等一系列的敏捷实践。

产品经理是对产品的ROI负责，负责梳理产品需求，规划产品功能列表，确定优先级，参与规划活动，并验证最终的交付成功。对于scrum里面强调的product owner更加强调面向市场和客户，只是参与而不是具体去执行敏捷开发过程中的具体事务类活动。

敏捷教练重点是引导团队进行敏捷转型，驱动敏捷实践的运转。可以全职，也可以兼职。

03.2 团队结构

团队结构在研发过程中以最小化的功能团队，以共同的价值观，通过可视化的方式，紧密合作，实现业务价值的快速交付。团队足够小，其各个团队相互独立，能够独自完成交付。

对于团队架构，实际上在devops过程实践里面本身是对团队结构有要求的，而这个在传统的敏捷方法论里面是不涉及的。比如我们经常谈到如果拆分为两个独立的微服务模块，那么两个模块涉及到的前端开发，设计，数据库人员完全是分离的，能够实现独立管理和协同。

持续交付

 

首先我们看下持续集成的定义，即持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

从这个定义里面可以看到重点在于集成两个字，即多个开发人员的代码每天要进行一次集成，如何检验集成成功？即我们说的执行了自动化的编译构建，并运行自动化的测试。

而在DevOps里面更加强调持续交付，这个和持续集成的区别就是持续交付的整个生命周期过程更长了，面向的是最终客户，最终的生产环境，因此不是简单的集成成功就完事，更加重要的就是向客户，向生产环境的交付是成功的，是可以持续进行的。这是两者最大的区别。

我最近在细读DevOps成熟度模型，再次感觉整个内容粗看很完整，但是细看感觉就很乱，其体系化和严谨程度和CMMI，PMBOK等比较起来差距很大。出来的很仓促，而且很大的一个感觉就是参与编写人员很多不是来自于一线DevOps项目实践。我一直强调，很多体系和模型的建设，一定是需要大量多样性实践后才能够完成核心通用价值的抽象。

01 配置管理

配置管理是对所有与项目相关的产物，以及它们之间的关系都被唯一定义，修改，存储和检索的过程，保证了软件版本交付生命周期过程中所有交付产物的完整性，一致性和可追溯性。配置管理是持续交付的基础，是保障持续交付正确性的前提，良好设计的配置管理策略，可提高组织协作效率，改善产品价值交付流程。

配置管理分为了版本控制和变更管理两个子内容，实际上对于配置管理的内容，完全可以参考CMMI二级里面的配置管理过程域，内容相当来说更加细化和完整。

对于版本控制首先要谈的的就是不仅仅是源代码，而是整个软件交付过程中涉及到的源代码，配置文件，数据库脚本，工具环境，数据，产品相关文档等都应该纳入到版本控制系统中进行管理。

所有的上述内容都应该对应到具体的版本，同时所有的变更都应该针对相应的版本进行，有变更也一定涉及到版本变化。

其次版本控制里面的一个重点就是我们常说的分支策略和集成策略，究竟应该定义几个分支？分支如何向主干合并，频率又如何，如何管理冲突都是应该考虑的问题。

在DevOps最佳实践里面可以看到，一定是不需要对开发，测试，生产，Bug等都构建出来不同的分支，太多的分支本身也会导致我们管理复杂度的增加。

那么持续交付的过程中，分支如何建设是一种比较好的方案？

初步思考来说，至少应该是建立开发和生产两个分支，生产版本稳定性不高则再增加Bug分支，即一个版本所有的测试都通过准备向生产交付的时候，开发环境分支代码打标签和基线，然后将代码Deliver到生产分支。这个时候开发分支可以开始下一个迭代版本的开发和变更，仍然是进行持续集成。

这种方式可以解决我们实际中的如下几个问题

1. 生产环境被破坏需要重新部署但是镜像本身也丢失，那我们可以在生产分支重新构建并部署
2. 生产环境出现Bug需要修复，我们直接在生产分支修改Bug后进行持续集成，单独起一个Bug验证环境
3. 将Bug修改同时在生产分支和开发分支进行修改

可以看到，如果我们不希望做第3步，那么还需要启用Bug分支，然后朝开发和生产分支进行Deliver操作。具体是否启用Bug分支需要看本身生产环境版本的稳定程度。

以上是针对一个项目的情况，但是如何我们一个软件产品面向前方多个项目，每个项目都可能存在定制开发的时候如何处理？这个也是我们开发团队经常会遇到的很现实的问题。

那我们来看下如果现在需要支撑A，B，C三个项目的软件定制化需求开发。实际上我们需要在主干分支上拉取三个独立的分支出来进行定制化开发，各项目定制的内容仅仅适用于各个项目本身。

1. 一个共性功能的添加？ 需要在主干分支完成，然后Deliver到三个独立分支。
2. 一个Bug修改？如何A项目发现共性Bug，A-Bug分支修改，然后Devlier主干，再Deliver到B和C分支。

因此也可以看到，定制化的项目越多，我们实际上管理起来就越复杂。如何制定更好的分支管理策略是其一，更加重要的是如何划分好微服务模块，让共性模块尽量共性化提供公共能力，即对应基础共性模块不存在面对各个独立项目需要独立起分支情况，所有项目都用一个分支，一套代码来支撑。

变更管理是指软件系统中的所有变更都可以追溯变更的详细信息记录，并向上追溯变更的原始需求，流转过程等所有关联信息。主要包括变更过程，变更追溯和变更回滚三方面。可追溯性是版本回滚的历史依据和实施基础，建立良好的版本可追溯性可实现对任一版本完整环境流程的自动化，精确回滚，快速重现问题和恢复正常环境。

变更过程从变更请求发起开始，一直到变更影响分析，变更活动执行，变更验证关闭要形成闭环的流程，同时所有的变更都涉及到对配置项的修改，需要进行对应，才可能实现变更的全流程可追溯。

那我们再来看下变更的回滚，可以看到如果一个小版本有3个变更修改，如果都要回滚相对容易，我们可以直接退回到上一个基线版本，但是如果只回滚里面一个变更对代码文件的修改，相对来说就不容易，就还是需要人工去处理和识别具体需要回滚的内容。

02 构建与持续集成

构建是将软件源代码通过构建工具转换为可执行程序的过程，一般包含编译和链接两个步骤，将高级代码语言转化为可执行的机器代码并进行相应的优化，提升运行效率。

构建实践是关注软件代码到可运行程序之间的过程，通过规则，资源和工具的有效结合，提升构建质量和构建速度，使构建成为一个轻量级，可靠可重复的过程。构建最终的产物采用清晰的版本进行标识，构建产物可以追溯，可回滚。

构建实践本身包括了构建方式，构建环境，构建计划和构建职责四个部分的内容。

对于构建实践本身最基本的要求就是通过构建脚本实现构建过程自动化，同时有专门的构建环境和服务器。在三级强调构建脚本复用和可管理性，构建环境配置的标准化；在四级强调构建过程的可视化编排，构建资源的动态分配和回收，基于容器化的分布式集群的应用。

对于Java项目，我们一般会采用Jekins进行持续构建和集成。

Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具，起源于Hudson（Hudson是商用的），主要用于持续、自动的构建/测试软件项目、监控外部任务的运行（这个比较抽象，暂且写上，不做解释）。Jenkins用、构建工具结合使用。常用的版本控制工具有SVN、GIT，构建工具有Maven、Ant、Gradle。

持续集成是软件工程领域中的一种最佳实践，即鼓励研发人员频繁的向主干分支提交代码，频率为至少每天一次。每次提交都触发完整的编译构建和自动化测试流程，缩短反馈周期，及时修复问题，从而保证软件代码质量，减少大规模代码合并的冲突和问题。

该过程主要包括了集成服务，集成频率，集成方式和反馈周期四个方面的内容。

对于持续集成，一方面是实现编译构建过程的自动化，一方面是实现测试过程的自动化，同时两者之间能够做到高效协同。对于其它持续集成的内容，在上篇文章已经做了详细描述，再次不再展开。

对于持续集成过程和交付过程中会使用到大量的开源工具技术进行集成，其中包括了配置管理，编译构建，自动化部署，自动化测试等各个生命周期过程，具体如下：

03 测试管理

测试管理是一个过程，通过该过程，所有和测试相关的方法，流程，人员都被定义。在产品投入到生产环境运行之前，通过测试过程验证产品的需求，尽可能地发现软件中的缺陷，从而提高软件产品的质量。测试管理分为测试分层策略，代码质量管理和自动化测试三个维度进行表达。

测试分层策略

我们来谈下有哪些测试分类的方法，在持续集成里面我们当然更加会强调自动化测试，因此可以理解为人工测试和自动化测试两类；也可以离开为代码级测试，接口测试和前端测试分离。也可以理解为功能测试和非功能测试两类。

当然也可以看到，在微服务架构下，我们希望我们本身的开发也是分层的，即中台模块+服务接口+前台功能，即我们通常说的前后端分离，在这种前后端分离的情况下，可以更加方便我们进行测试分层设计和自动化测试。只要是厚中台+薄前台模式，那么就越容易实现测试过程的自动化。

越是持续集成自动化承担越高，那么自动化测试的比重就会越大。

可以看到首先在架构设计上就要做到前后端分离，中台+服务+前台，这种分离后可以更加方便后面进行后端代码和接口的自动化测试工作。

可以看到在测试分层策略里面的四到五级描述里面，我们看到TDD测试驱动开发方面的内容，比如先写测试代码再写实现代码或者两者同时在进行等。其次，我们还是要将在整个devops最佳实践里面，不仅仅开发过程是持续增量进行的，对于测试过程本身也是持续增量进行的，两者必须匹配。

或者理想状态应该是没有独立的测试周期，开发完成的阶段往往就是测试也配套完成的时间点。

代码质量管理

是软件研发过程中保证代码质量的一种机制，即在代码变更后，需要对代码进行检查，分析，并给出结论和改进建议，对代码质量数据进行管理，并可以对代码质量进行追溯。主要包括了质量规约，检查方式，反馈处理三方面的内容。

代码质量管理即我们常说的代码静态检查，其基于我们制定的代码质量规约进行。质量规约是指对软件代码质量的要求和规范，其中包含了编码规范，复杂度，覆盖率，以及安全漏洞，合规性要求等多个方面的内容。其中检查方式即包括了我们传统手工方面的检查和CodeReview，也包括了运行相关的自动化检查工具进行检查。

自动化测试

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程，在预设条件下运行系统或应用程序，执行测试并评估测试结果，以达到节省资源和人力，提高测试效率和准确性，主要包括了自动化设计，自动化开发，自动化执行和自动化分析。

对于自动化测试可以看到，对于服务接口和代码级的自动化测试相对来说比较容易实现，但是对于前端和UI级的自动化测试相对来说就比较困难些。因此对于前期实践，我们也是建议先实现接口服务和代码级的自动化测试，再来靠前端UI的自动化测试。

对于性能测试由于可以提前录制脚本，相对来说自动化测试实现起来比较容易。不论是那种类型的自动化测试都可以看到，实际上可以看到如下几个关键点。

1. 自动化测试代码或脚本的编写，可以是人工编写，也可以通过录制生成。
2. 测试数据的产生问题，执行自动化测试前往往都涉及到测试数据的产生和使用，参考测试管理过程域
3. 自动化测试脚本能够重复执行的要求，这点必须要做到，确保每次持续集成都能够重复运行测试脚本

到了自动化测试的第四级开始，可以看到增加了对独立的自动化测试平台的要求，同时也增加了对测试结果分析和度量的要求，即通过测试结果的度量分析来进一步改进测试效率，提升代码质量。

4.部署和发布管理

部署和发布泛指软件生命周期中，将软件应用系统对用户可见，并提供服务的一系列活动，包括系统配置，发布，安装等。整个部署和发布过程复杂，往往涉及到多个团队之间的协同和交互，需要良好的计划和演练来保证部署发布过程的正确性。

部署偏技术实践，即软件代码，应用，配置和数据库变更到测试和生产环境的过程。而发布偏业务实践，是指将部署完成的应用软件功能正式对用户可见的过程，提供线上服务的过程。即部署完了不一定就马上对业务和用户可见，而只有发布和配置完了才对用户可见，这样也就更好理解灰度发布的概念了。

部署和发布模式

部署和发布模式关注交付过程中的具体实践，将部署活动自动化并前移到开发阶段，通过频繁的演练和实践部署活动，成为研发日常工作的一部分，从减少最终部署的困难和不确定性，可靠可重复的完成部署发布任务。

最基本的要求是整个部署流程标准化和规范化，同时通过自动化的部署脚本进行部署操作。在三级就要求部署过程实现全自动化，同时应用和环境做为部署的最小单位，应用和配置进行分离。在四级要求部署过程灵活可编排可配置，可以一次自动部署多环境，可以支持灰度发布。

建立持续优化的部署监控机制，部署前能够进行自动化的测试，部署失败能够自动回滚。

部署流水线

部署流水线是DevOps的核心实践，通过可靠，可重复的流水线，打通端到端的价值交付，实现交付过程中各个环节活动的自动化和可视化。部署流水线通过将复杂的软件交付流程细分为多个阶段，每个阶段层层递进，提升软件交付质量的信息，并且在流水线过程中提供快速反馈，减少后端环节浪费。

注意在三级里面流水线过程强调了打通软件交付过程中的各个环节，建立全流程的自动化能力，并根据自动化测试结果保证软件交付质量。在四级强调了可视化的部署流水线覆盖整个软件交付过程，每次变更都会触发完整的自动化部署流水线作业。

对于可视化的部署流水线，我仍然坚持我的观点，即一定有一个顶层流水线是不仅仅是简单的到持续集成过程完成，而是覆盖到整个从sit到uat，从uat到生产的环境迁移过程。简单来说，到生产的环境迁移本身就是一个持续交付的过程。

到生产的交付本身可以是独立的子流水线，因此我们在流水线设计上面支持分层是相当重要的一个功能。如果是两个独立的流水线，那么一定存在断点，但是完整的持续集成和交付过程一定是从需求和变更开始端到端驱动的，而不是随意可以触发执行的。

5.环境管理

环境做为DevOps持续交付过程中最终承载，包括环境的生命周期管理，一致性管理，环境的版本管理，环境管理是用最小的代价来达到和确保一致性的终极目标，主要包括环境类型，环境构建，环境依赖和配置管理几个部分的内容。

对于大型项目来说，我们可以看到会包括了DEV开发环境，SIT集成测试环境，UAT用户验收测试环境和PRD生产环境四套环境，更复杂的往往还有预生产发布环境，生产克隆环境等。

对于DEV开发测试环境的作用主要是方便开发测试阶段的多个微服务模块之间的接口联调，这些到了SIT集成测试阶段做显然是不合适的，如果不具备开发测试环境就需要开发人员机器连接到SIT环境的接口服务进行联调，这种情况显然也不太合适。同时对于DEV开发测试环境也方便我们去运行自动化测试脚本进行自动化测试。

对于SIT集成测试和UAT测试，实际重点都会偏黑盒测试了，至少应该确保有一套黑盒测试环境。

在三级里面就已经强调需要有独立的开发测试环境，同时环境的准备能够达到小时级完成，同时又以应用为中心，有服务级依赖的配置管理能力，比如依赖的关联服务，数据库服务，缓存服务等。在四级强调建立全面的测试和灰度环境，环境的构建可以通过容器化快速交付，而且达到分钟级。

环境是独立的配置管理对象，环境依托于具体的虚拟化资源或容器资源，同时不同环境有不同的差异化配置文件，配置文件依赖于不同的环境对象。

一个大的应用往往会分为多个微服务模块，每个微服务模块完全独立管理，因此都可以做到独立的定义环境和环境配置变量信息。大应用和多个微服务模块间本身也是一种松耦合的关系。

一个是环境的准备和建立可以做到快速，比如我们持续集成已经正常运行，我们可以快速的准备一套演示环境给客户使用，同时也要做到环境和资源松耦合，环境可以做到快速的销毁以回收资源。

6.数据管理

系统开发过程中为了满足不同环境的测试需求，以及保证生产数据的安全，需要人为准备数据庞大的测试数据，需要保证数据的有效性以适应不同的应用程序版本。另外应用程序在运行过程中会产生大量数据，这些数据和应用本身的生命周期不同，做为应用最有价值的内容需要妥善保存，并随应用程序的升级和回滚进行迁移。

测试数据管理

测试数据应该满足多种测试类型的需求（手工测试，自动化测试），覆盖正常状态，错误状态和边界状态，测试数据应该同时满足测试效率和数据量的要求，测试数据的输入需要受控，并运行在受控环境中，保证输出的有效性。为了模拟生产环境情况，往往需要采用仿生产数据，使用时候需要注意安全和脱敏。

数据来源：最基本是自己手工输入，其次是生产环境导出再导入测试环境，处理过程中需要清洗和脱敏。再四级开始强调了需要有能力能够通过代码或api接口调用来自动生产满足需要的测试数据。

数据覆盖：在二级只强调了测试数据覆盖主要场景，包括正常，异常错误和边界场景。而到了三级，强调需要建立体系化测试数据，进行数据依赖管理，覆盖全部测试分层策略要求的测试类型。

数据独立性：在二级强调了测试数据有明确的备份恢复机制，同时实现测试数据复用和保证测试一致性。在三级开始强调测试用例的执行不依赖其它测试用例执行所产生的数据。减少测试数据间的依赖关系。

数据变更管理

数据变更管理是指应用程序升级和回滚过程中的数据库结构和数据的变更，良好的变更策略应保证应用版本和数据库版本兼容匹配，以应对应用的快速扩容缩容等线上场景。通过应用变更和数据变更的解耦，减少系统变更的相互依赖，实现灵活的升级部署，主要包括了变更过程，兼容回滚和数据监控。

注意整个变更里面实际强调了以下几个关键点

1. 应用部署和数据变更部署解耦，相互独立，数据变更又包括了结构变更和数据本身变更
2. 数据变更应该具备向下兼容性和具体的回滚方法

对于数据变更向下兼容需要分开讨论，首先是对于数据库结构的变更，原则上需要完全做到向下兼容，即数据库结构在变化后不进行回滚，向下兼容，比如拓展了字段或长度等。其次是数据本身的更新或初始化，如果是新增增量初始化数据往往并不需要回滚，但是如果是对已有数据进行update操作，往往就需要配合应用程序的回滚一同进行回滚操作。

那么我们在部署失败的时候的回滚就需要重点去考虑，前者是镜像回滚，后者是需要运行事先准备好的回滚脚本进行数据内容的回滚才行。

对于整个数据管理过程域，实际设计的不太合理，按道理测试数据管理应该纳入到测试管理这个过程域，而对于数据变更管理本身应该纳入到大的变更管理过程域更加合理。

7. 度量和反馈

DevOps基于精益思想发展而来，其中持续改进是精益思想的核心理念之一。

DevOps主张在持续交付的每一个环节建立有效的度量和反馈机制，其中通过设立清晰可量化的度量指标，有助于衡量改进效果和实际产出，并不断迭代后续改进方向。另外设立及时有效的反馈机制，可以加快信息传递速率，有助于在初期发现问题，解决问题，并及时修正目标，减少后续返工带来的成本浪费。度量和反馈可以保证整个团队内部信息获取的及时性和一致性，避免信息不同步导致的问题，明确业务价值交付目标和状态，推进端到端价值的快速有效流动。

度量指标

度量指标的拣选和设定是度量和反馈的前提和基础，科学合理的设定度量指标有助于改进目标的达成。在拣选度量指标时需要关注两个方面，即度量指标的合理性和度量指标的有效性。

合理性方面依托于对当前业务价值流的分析，从过程指标和结果指标两个维度来识别DevOps实施结果，以及整个软件交付过程的改进方向。

有效性方面一般遵循SMART原则，即指标必须是具体的、可衡量的、可达到的、同其他目标相关的和有明确的截止时间，通过这五大原则可以保证目标的科学有效。

度量驱动改进

度量驱动改进关注软件交付过程中各种度量数据的收集，统计，分析和反馈，通过可视化的度量数据客观反映整个研发过程的状态，以全局视角来分析系统约束点，并在团队内部分享，帮助设定客观有效的改进目标。实际里面有两个关键内容。

一个是度量信息的分类分解和可视化呈现，比如强调通过可视化看板来实时展示度量数据，报告可以多维度实时展示，同时还支持自动生成数据趋势图和趋势分析。其次就是度量发现的问题要有问题跟踪和反馈机制，形成问题闭环和持续改进。