| DevOps-持续交付-能力成熟度自评表 | |||||||||||
| 项目名称 | 请填写：XX公司XX项目 | 目标级别 | 请填写：X级，如3级 | ||||||||
| 能力域 | 能力子域 | 能力项 | 能力子项 | 1级 （初始级：管理散乱无序） |
2级 （基础级：自动化/脚本化、小范围） |
3级 （全面级：系统化/工具化、规范化、大范围） |
4级 （优秀级：深度规范化、服务化、按需交付） |
5级 （卓越级：持续改进与数据化、智能化） |
自评 | 和X级要求的差距 X级为参评单位预期要达到的能力级别 |
问题记录与改进思路 请记录针对标准的疑问和针对不足的改进思路 |
| 持续交付 | 配置管理 | 版本控制 | 版本控制系统 | 源代码分散在研发本地自行管理 | 1)
使用统一的版本控制系统 2) 将全部源代码纳入版本控制系统管理 |
1)
将配置文件、构建和部署等自动化脚本纳入版本控制系统管理 2) 有健全的版本控制系统管理机制，包括： 代码库命名规范 备份与可用性保障机制 权限模型 3）专人专岗管理版本控制系统 |
1)
将数据库变更脚本和环境配置等纳入版本控制系统管理 2) 版本控制系统相关操作以自动化的方式实现，而非手工操作，说明：如Tag创建、分支拉取等，无需人工手动在版本控制系统中操作 3) 有针对版本控制系统的度量与监控机制，说明：包括代码库大小，代码推送频率与时间分布，日志等（更加关注版本控制的业务数据的度量，而非版本控制系统的CPU等监控） |
1)
将软件生命周期的所有配置项纳入版本控制系统管理 2) 可完整回溯软件交付过程满足审计要求 3) 持续优化的版本控制系统 |
|||
| 分支管理 | 无 | 多条分支长期并行存在且分支合并到主干的周期长 | 1）短周期分支 2）分支频繁地向主干合并 说明：分支合并到主干的冲突少，分支生命周期为几天，合并耗时在小时级 |
1)分支策略满足持续交付需求，可灵活适应产品交付 2)主干随时可进行指定版本进行测试和发布 3)特性代码可按需合并到主干进行验证和发布 |
1)
持续优化的分支管理机制 2) 可以针对不同业务和技术要求，选用不同的分支策略，在指定时间发布 |
||||||
| 制品管理 | 构建产物分散在研发本地自行管理 | 1)
使用统一的制品库管理构建产物 2) 有清晰的存储结构 3) 有唯一的版本号 4) 通过统一的制品库地址进行构建产物分发 说明：统一、专业的制品库工具（如Nexus、Harbor等）在项目中成熟运用 |
1)
将依赖组件纳入制品库管理 2) 将所有交付制品纳入制品库管理，比如：测试报告 3) 制品库读写有清晰的权限管控制度 说明：制品管理范围全面，包括依赖、测试报告、版本包等，制品公库管理也遵守规范 |
1）对制品库完成分级管理 2）已建立体系化的制品库管理策略，包括：备份与恢复机制、策略管理，制品库完整性与一致性保障机制 说明：制品库分级是指制品库需要有类似SNAPSHOT,STAGING,RELEASE的分级划分，制品需要层层晋级才可以发布（SNAPSHOT->STAGING-> RELEASE），实现制品的质量门禁，为后续制品在不同仓库类型中晋级提供基础 |
持续优化的制品管理机制 | ||||||
| 单一可信数据源 说明：单一可信数据源是一种信息数据模型和关联模式，保证每个数据元素只存储一份，确保数据的一致性。 |
无 | 开发测试部署环节所用到的源代码来源于统一版本控制系统 |
版本控制系统和制品库作为单一可信数据源，覆盖生产部署环节。 说明：生产部署只从单一可信的版本控制系统或制品库下载部署包或配置文件等，不会从其他任何渠道获取。 |
单一可信数据源覆盖本地研发环境 说明：不只生产环境采用单一可信数据源，研发环境也遵守该原则，研发环境使用工具、数据都有统一来源 |
1)
单一可信数据源贯穿整研发价值流交付过程 2) 在组织内部开放共享，建立知识积累和经验复用体系 |
||||||
| 变更管理 说明：该变更是指需求、代码等内容 |
变更过程 | 1)
无变更过程 2）变更信息分散在每个系统内部，缺乏信息的有效共享机制 |
1)
建立代码基线 2) 记录代码变更管理信息 3) 针对重点变更内容进行评审 说明：代码和变更信息关联，并且代码有Code Review等变更评审机制，代码有良好的版本基线管理 |
1)
所有配置项变更由变更管理系统触发 2) 针对每次变更内容进行评审，并使用自动化手段（再讨论合理性） 说明：代码等所有配置项的修改，必须强制有需求/缺陷作为变更源头，并做好需求/缺陷与配置项版本的对应，实现统一变更管理。配置项变更需要自动化的评审，比如自动化代码扫描和构建作为评审方式，再结合人工的代码审查 |
1)
使用统一的变更管理系统 2) 变更管理过程覆盖从需求到部署发布全流程 3) 建立变更的分级评审机制 说明：变更管理系统（如JIRA、Redmine等）贯穿需求到部署的全过程与角色，研发和运维团队采用统一系统，而非各自独立，互不连通。不同类型或级别的变更会有不同类型的评审机制。 |
可视化变更生命周期，支持全程数据分析管理 | |||||
| 变更追溯 | 无 | 1)
有清晰定义的版本号规则 2) 实现制品和代码基线的关联，可追溯指定版本的完整源代码信息 说明：制品和代码Tag是对应的，可以根据制品版本找到代码Tag，反向亦然 |
实现版本控制系统和变更管理系统的自动化关联,信息双向同步和实时可追溯 | 1)
变更依赖关系被识别和标记 2) 实现数据库和环境变更信息的可追溯 说明：需求、计划、任务、代码、用例、缺陷、制品包、发布计划等的关系； 数据库和环境信息的修改基于变更管理系统发起和跟踪，而非单独的管理或无管理 |
实现从需求到部署发布各个环节的相关全部信息的全程可追溯 | ||||||
| 变更回滚 说明：该回滚是指需求延期发布或撤销时，需要同步修改需求状态、移除代码、重做制品包等，主要用于需求未发布前回滚，而非生产变更回滚 |
无 | 手工实现回滚 | 1)
实现变更管理系统和版本控制系统的同步回滚，保证状态的一致性 2）回滚操作实现自动化（全自动化是否合理，部署和发布分离,数据库和历史数据的回滚需要人工干预，可以调整为关注代码级的回滚，数据库的挪到第4级，整体标准中的第4级会更多关注数据库） 说明：是指基于需求级别的回滚机制，需求撤销后，代码也同步自动化移除 |
自动化回滚全流程的所有变更，包括变更依赖 | |||||||
| 构建与持续集成 | 构建实践 说明：关注软件代码到可运行程序之间的过程 |
构建方式 | 采用手工方式进行构建 | 采用脚本实现构建过程自动化 | 1)
定义结构化构建脚本，实现模块级共享复用 2) 构建脚本由专人专岗统一维护 说明：构建脚本实现复用，比如Jenkins中的global pipeline libraries实现构建模块化，构建脚本由专业人员统一维护 |
1)
实现构建方式服务化，可按需提供接口或用户界面，将构建能力赋予整个研发团队 2) 研发团队可以按场景实现构建过程可视化编排 说明：构建方式以Web或其他方式提供构建能力给研发团队，随时自行构建，构建过程包含多场景（代码扫描、自动化测试、安全等）并且可以灵活编排 |
持续优化的构建服务平台，持续改进服务易用性 | ||||
| 构建环境 | 使用研发本地设备构建 | 有独立的构建服务器，多种任务共用构建环境 | 1)
构建环境配置实现标准化 2) 有独立的构建资源池 |
实现构建资源动态弹性按需分配与回收，如搭建基于云服务虚拟化和容器化的分布式构建集群 | 持续改进构建环境以提高构建效能 | ||||||
| 构建计划 | 构建任务不定期执行 | 1）实现每日自动构建 2）根据发布策略细分构建类型，比如发布构建、测试构建 |
1)
实现定期自动执行构建和代码提交触发构建 2) 明确定义构建计划和规则，并在研发团队内共享 说明：需实现代码提交自动化触发构建过程，以保证对代码的持续验证 |
实现按需制定构建计划 说明：各个团队可以自行定制构建计划，实现构建的服务化 |
同上 | ||||||
| 构建职责 | 无专人专岗负责构建 | 构建工具、环境与计划由专人负责维护并有权限管理 | 构建工具和环境由专门团队维护并细分团队人员职责 说明：由专业团队负责管理 |
构建实现自服务，团队接口人可自主按需执行 说明：构建无需专业团队干预，团队负责人可以自行构建 |
将构建能力赋予全部团队成员，并按需触发构建实现快速反馈 | ||||||
| 持续集成 | 集成服务 | 无持续集成服务 | 搭建统一的持续集成服务 | 组建专门的持续集成团队，负责优化持续集成系统和服务 | 1)
实现持续集成服务化和自助化，研发团队可自行使用持续集成服务 2) 具备集成队列管理能力，队列资源和优先级可控 |
持续优化和改进团队持续集成服务，实现组织交付能力提升 | |||||
| 集成频率 | 长期本地开发代码，集成频率几周或者几月一次 |
采用团队定期统一集成的策略，代码集成频率几天或者几周一次 | 研发人员至少每天向代码主干集成一次 | 1）研发人员具备每天多次向代码主干集成的能力，可按需集成 2）任何变更（代码，配置，环境）都会触发完整的持续集成流程 |
任何变更（代码，配置，环境）都会触发完整的持续集成流程 | ||||||
| 集成方式 | 代码集成作为软件交付流程中的一个独立阶段 | 在部分分支上进行每天多次的定时构建 | 每次代码提交触发自动化构建，构建问题通过自动分析精准推送相关人员处理 说明：构建问题需要相对精准的推送给问题直接负责人，而不是抄送邮件组，导致问题无人解决 |
1)
每次代码提交构建触发自动化测试和静态代码检查 2) 测试问题自动上报变更管理系统 3) 测试结果作为版本质量强制要求，如：采取质量门禁等方式强化主干代码质量 |
实现持续集成分级和自动化测试分级，满足不同模块和集成阶段的差异化需求 | ||||||
| 反馈周期 说明：是指集成问题发现和修复时间 |
每次集成伴随大量的问题和冲突，集成期间主干长期不可用 | 集成问题反馈和解决需要半天或者更长时间 | 集成问题反馈和解决可以在几个小时内完成 说明：集成问题反馈是从代码提交到发现构建失败的时间，集成问题解决是指开发修复代码并执行再次流水线后展示成功的时间 |
集成问题反馈和解决控制在30分钟以内完成 | 集成问题反馈和解决控制在10分钟以内完成 | ||||||
| 测试管理 | 测试分层策略 | 分层方法 说明：分层方法是测试体系按照不同的测试对象，类型进行分类聚合的方法，每一层对应了特有的测试需求。 |
只进行用户/业务级的UI测试 | 1)
采用接口/服务级测试对模块/服务进行覆盖全面的接口测试； 2) 采用代码级测试对核心模块的函数或类方法进行单元测试； 3) 对系统进行基本的性能测试 |
1)
采用代码级测试对模块的函数或类方法进行覆盖全面的单元测试； 2) 系统全面的进行性能、容量、稳定性、可靠性、易用性、兼容性、安全性等非功能性测试 |
1)
采用测试驱动开发的方式进行代码级、接口级测试； 2) 采用探索性测试方法对需求进行深入挖掘测试 |
采用验收测试驱动开发的方式进行用户/业务级的UI测试 | ||||
| 分层策略 说明：分层策略是指基于测试分层策略对每部分的测试比重和投入，以及覆盖度等的划分策略。 |
无测试分层策略 | 1)
已建立测试分层策略 2) 测试设计以对用户/业务级UI测试为主，辅以少量的接口/服务级测试 |
1)
测试设计以对接口/服务级测试为主，兼顾用户/业务级测试辅以少量的代码级测试 2) 对非功能性测试进行全面系统的设计 |
1)
测试设计以对代码级测试为主，兼顾接口/服务级和用户/业务级测试 2) 对探索性测试进行全面系统的设计 3) 测试分层策略的各层测试具有交叉互补性 |
定期验证测试分层策略，是否完整、有效，持续优化策略 | ||||||
| 测试时机 | 测试在软件交付过程中在开发完成后才介入 | 1)
测试在持续交付过程中的介入时间提前到开发的集成阶段 2) 接口/服务级测试在模块的接口开发完成后进行 |
1)
测试在持续交付过程中的介入时间提前到开发的编码阶段 2) 代码级测试在模块的函数或类方法开发完成后进行 |
1)
代码级测试在模块的函数或类方法开发过程中同步进行和完成； 2) 接口/服务级测试在模块的接口开发过程中同步进行和完成 |
1) 在需求阶段进行用户/业务级测试设计 2) 在需求特性开发、交付整个过程中同步进行并完成测试 |
||||||
| 代码质量管理 | 质量规约 | 具备初始代码质量规约，规约停留在个人级 | 1)
建立团队级代码质量规约 2) 规约范围覆盖部分代码质量指标，如：代码规范、错误和圈复杂度、重复度等质量指标 |
1)
建立组织级代码质量规约 2) 建立完整的质量规约，将安全漏洞检查、合规检查纳入规约 3) 建立强制执行的质量门禁体系 4) 建立规约固定更新机制 说明：质量规约需要具备定期的更新机制，保障规约的适用性 |
1)
建立公司级代码质量规约 2) 可根据业务需要灵活扩展和定制 |
定期验证代码质量规约的完整性和有效性，持续优化 | |||||
| 检查方式 | 代码质量检查采用人工方式进行评审 | 代码质量检查采用自动化结合手工方式进行 | 代码质量检查完全自动化，不需要手工干预 | 对代码质量检查发现的部分问题自动提出修改建议，支持可视化 | 具备企业级的代码质量管理平台，以服务的形式提供对代码质量的检查、分析 | ||||||
| 反馈处理 | 无代码质量检查结果处理机制，存在大量技术债 | 对代码质量检查结果给出反馈，只处理部分检查结果 | 根据代码质量检查结果反馈及时处理，根据质量规约维持一定的技术债 | 1)
团队在研发阶段主动解决技术债 2) 整体技术债呈下降趋势 |
1)
对代码质量数据进行统一管理 2) 可有效追溯并对代码质量进行有效度量 |
||||||
| 自动化测试 | 自动化设计 说明：自动化设计是指测试分层中各种测试类型的自动化设计方法（包括用例+工具平台），用于指导自动化测试工作的有效执行。 |
无 | 对用户/业务级的UI测试进行自动化设计 | 1)
对接口/服务级测试进行自动化设计 2) 对代码级测试进行自动化设计 |
对性能、稳定性、可靠性、安全性等非功能性测试进行自动化设计 |
对故障和测试进行复盘，对遗漏的测试用例进行补充，不断优化和完善，持续提升覆盖率 | |||||
| 自动化开发 | 自动化测试脚本与工具分散管理 | 1)
设置专人专岗统一管理自动化测试脚本与工具 2) 使用版本控制系统对自动化测试脚本进行有效管理 |
1)
建立统一的自动化测试框架，统一管理自动化测试用例 2) 自动化测试脚本开发采用数据驱动、关键字驱动等方法； 说明： |
1)
建立自动化测试自服务平台 2) 优化自动化测试执行效率 3) 自动化测试资源池化 |
持续优化的自动化测试平台 | ||||||
| 自动化执行 | 1)
手工测试为主，自动化程度低 2) 测试执行以周为单位 |
1)
对用户/业务级UI测试采用自动化测试 2) 自动化测试的执行效率较低，以天为单位 |
1)
对接口/服务级与代码级测试采用自动化测试 2) 自动化测试由流水线自动化触发 |
1)
有组织级的统一自动化测试平台，和上下游需求、变更管理系统打通； 说明：测试用例统一管理且和变更管理系统中的需求关联 2) 可以根据需求选择关联的自动化测试用例执行； 3) 可以将由于版本原因导致的失败用例和缺陷关联 |
定期验证自动化执行策略，持续优化测试执行效率和资源利用率 | ||||||
| 自动化分析 | 手工对测试结果进行分析判断 | 对自动化测试结果具备一定的自动判断能力，存在一定的误报 | 对自动化测试结果具备较强的自动判断能力，误报少 说明：关注自动化测试结果的准确率是否有机制保障和持续提升，比如饼图分析自动化测试结果失败原因与类型，持续优化自动化解测试 |
自动化测试数据模型标准化，和上下游需求、缺陷等研发数据关联，可以对自动化测试效果进行度量分析。例如：需求测试覆盖率、测试通过率和测试效率等。 说明：关注自动化测试结果与需求、用例、代码的关联分析与度量 |
对自动化测试结果可以智能分析，自动分析失败用例的失败类型及原因，可以自动向缺陷管理系统提交缺陷 | ||||||
| 部署与发布管理 | 部署与发布模式 | 部署方式 | 运维人员手工完成所有环境的部署 | 1)
运维人员通过自动化脚本实现部署 2) 部署过程部分自动化 |
部署和发布全部实现自动化 说明：关注部署和发布的全部过程均实现自动化 |
1) 部署发布服务化，实现团队自助一键式多环境自动化部署 2) 同时支持数据库自动化部署 说明：部署能力以服务（如Web功能）提供给团队，可以自助完成多环境（测试、预发布、生产等）的部署，包括数据库的自动化部署 |
持续优化的部署发布模式和工具系统平台 | ||||
| 部署过程 | 部署过程存在较长的服务中止时间 | 部署过程通过流程文档实现标准化 说明：部署过程采用文档进行描述和规范化，部署人员基于文档进行操作 |
1)
使用相同的过程和工具完成所有环境部署 2) 一次部署（每次部署）过程中使用相同的构建产物 说明：不同环境的部署过程和工具要是一样的，比如预发布和生产的部署过程，包括移除集群，部署，加入集群等操作需要保持一致。部署的软件包要遵守单一制品原则，各个环境采用同一个包，不同环境适配不同的环境变量，不会重复构建。 |
部署过程可灵活响应业务需求变化，通过合理组合实现灵活编排 |
持续部署，每次变更都触发一次自动化生产环境部署过程 | ||||||
| 部署策略 | 1)
采用定期部署策略，部署频率以月为单位 2) 单次部署包含大量需求 |
1)
采用定期部署策略，部署频率以周为单位 2) 应用作为部署的最小单位 3）应用和数据库部署实现分离 4）实现测试环境的自动化部署 |
1)
采用定期部署策略，具备按天进行部署的能力 2) 应用和环境整体作为部署的最小单位 3) 应用和配置（的部署分离）进行分离 |
1)
采用按需部署策略，具备一天部署多次的能力 2) 通过低风险的部署发布策略保证流程风险可控，如：蓝绿部署，金丝雀发布 |
团队自主进行安全可靠地部署和发布 | ||||||
| 部署质量 | 1)
部署整体失败率较高 2) 部署无法实现回滚，生产问题只能在线上修复，修复时间不可控 |
1)
部署失败率中等 2) 实现应用部署的回滚操作，问题可及时修复 |
1)
部署失败率低（指标的定义） 2) 部署活动集成自动化测试功能，并以测试结果为部署前置条件 3) 每次部署活动提供变更范围报告和测试报告 |
建立监控体系跟踪和分析部署过程，出现问题自动化降级回滚 | 持续优化的部署监控体系和测试体系，部署失败率维持在极低水平 | ||||||
| 部署流水线 | 协作模式 | 1)
整个软件交付过程严格遵循预先计划 2) 存在复杂的部门间协作和等待 3) 只有在开发完成后才进行测试和部署 |
通过定义完整的软件交付过程和清晰的交付规范，保证团队之间交付的有序 说明：基于规范和流程进行协作，大多是采用邮件或线下的方式，但是相对顺畅有序 |
团队间交付按照约定由系统间调用完成，仅在必要环节进行手工确认 说明：协作是基于变更管理系统或OA系统等实现信息化管理 |
团队间依赖解耦，可实现独立安全的自主部署交付 说明：基于微服务的架构下，各个服务团队可以自主独立交付，不存在版本火车等多个服务或应用需一起发布的情况 |
持续优化的交付业务组织灵活响应业务变化改善发布效率 | |||||
| 流水线过程 | 软件交付过程中的大部分工作通过手工方式完成 | 软件交付过程中的各个环节建立自动化能力以提升处理效率 说明：构建、测试、扫描、部署等均实现基本的自动化 |
打通软件交付过程中的各个环节，建立全流程的自动化能力并根据自动化测试结果保障软件交付质量 说明：构建、测试、部署等过程基于流水线实现贯通，不再是独立的（包括流程独立、数据独立） |
1)
建立可视化部署流水线，覆盖整个软件交付过程 2) 每次变更都会触发完整的自动化部署流水线 |
持续部署流水线驱动持续改进 | ||||||
| 过程可视化 | 1)
交付过程中的信息是封闭的 2) 交付状态追溯困难 |
1)
交付过程在团队内部可见，信息在团队间共享 2) 交付状态可追溯 |
1)
交付过程组织内部可见 2) 团队共享度量指标 |
1)
部署流水线全员可见 2) 对过程信息进行有效聚合分析展示趋势 说明：全员是指整个公司级均可以查看，而不是封闭的，全员关注质量与进度 |
部署流水线过程信息进行数据价值挖掘，推动业务改进 | ||||||
| 环境管理 | 环境管理 | 环境类型 | 环境类型只有生产环境和非生产环境的划分 |
建立功能测试环境 | 建立标准的研发环境 说明：研发环境采用云环境或者自动化配置工具进行标准化的配置，比如工具包的版本等等都是统一的 |
建立全面的测试与灰度环境包括：开发环境，技术测试及业务测试环境以及灰度发布环境等等 | 根据业务与应用的需要，弹性分配各类环境 | ||||
| 环境构建 | 1)
人工创建环境 2) 环境准备时间长，需要几周完成 |
1)
环境构建通过自动化来完成 2) 环境准备时间以天为单位 |
1)
环境的构建通过自服务的资源交付平台来完成 2) 环境准备时间小时级 |
1）环境的构建可以通过容器化快速交付 2）环境准备实现分钟级 |
环境根据业务及应用架构弹性构建 | ||||||
| 环境依赖与配置管理 | 1)
无依赖管理 2) 环境的管理为操作系统的交付方式 |
通过配置管理工具实现操作系统级别的依赖管理，比如说操作系统版本、组件版本、程序包版本等等 | 以应用为中心，有服务级依赖的配置管理能力，比如：依赖的关联服务，数据库服务、缓存服务、关联应用服务等等 | 环境和依赖配置管理实现代码化描述 说明：如基础设施即代码，基于代码的方式描述环境信息和依赖信息，类似Dockerfile等 |
环境依赖和配置可以做到实例级的动态配置管理能力，根据业务和应用架构弹性变化 | ||||||
| 数据管理 | 测试数据管理 | 数据来源 | 测试时手工创建临时数据 | 导出部分生产环境数据形成基准的测试数据集 | 导出部分生产环境数据并清洗敏感信息后形成基准的测试数据集 | 每个测试用例专属的测试数据都可以通过模拟或调用应用程序API的方式自动生成 | 所有的功能、非功能测试的测试数据，均可通过模拟、数据库转储或调用应用程序API的方式自动生成 | ||||
| 数据覆盖 | 测试数据覆盖部分测试场景 |
1)
测试数据覆盖主要场景，包括：正常类型，错误类型以及边界类型 2) 进行初步的分类分级，满足不同测试类型需要 |
建立体系化测试数据，进行数据依赖管理，覆盖全部测试分层策略要求的测试类型（注明引用内容的序号） | 1)
测试数据覆盖安全漏洞和开源合规等需求场景 2) 建立定期更新机制 |
持续优化的持续数据管理方式和策略 | ||||||
| 数据独立性 说明：数据独立性是指测试数据在测试执行各阶段的完整性和一致性，不会受到其他任务执行结果的影 响。 |
无 | 1)
测试数据有明确备份恢复机制 2) 实现测试数据复用和保证测试一致性 |
1)
每个测试用例拥有专属的测试数据有明确的测试初始状态 2) 测试用例的执行不依赖其他测试用例执行所产生的数据 说明：基于需求场景的测试是可以存在测试用例之间的数据依赖，即前置用例的输出成为后置用例的输入 |
对测试数据分级，形成元数据和测试用例专用数据 | 同上 | ||||||
| 数据变更管理 说明：数据变更管理主要是指应用程序升级和回滚过程中的数据库结构和数据的变更 |
变更过程 | 1)
数据变更由专业人员在后台手工完成 2) 数据变更作为软件发布的一个独立环节，单独实施和交付 |
1)
数据变更通过文档实现标准化 2) 使用自动化脚本完成数据变更 |
将数据变更纳入持续部署流水线，经人工确认后自动完成 | 1)
应用程序部署和数据库变更解耦，可单独执行 说明：重点考虑应用与数据库的版本前后兼容性 2) 数据变更随应用的部署自动化完成，无需专业人员单独执行 说明：数据库版本和应用版本可以向前向后兼容，各自独立发布，且工具平台具备研发或应用运维人员可以发布数据库变更的能力，无需专业DBA参与每次发布 |
持续优化的数据管理方法，持续改进数据管理效率 | |||||
| 兼容回滚 | 没有建立数据库版本，数据库和应用存在不兼容风险 | 建立数据库和应用的版本对应关系，并持续跟踪版本变更 | 每次数据变更同时提供明确的回滚机制，并实现进行变更测试，如：提供升级和回滚两个自动化脚本 | 数据变更具备向下兼容性，支持保留数据的回滚操作和零停机部署 | 同上 | ||||||
| 数据监控 | 数据变更结果需要访问数据库进行验证 |
收集和分析数据变更日志，实现变更问题快速定位 |
针对不同环境和危险程度对数据变更建立分级监控机制 说明：如DROP或DELETE等操作需要有不同的监控级别，生产和测试环境的监控范围也不同 |
对数据变更进行监控，自动发现和修复异常变更 说明：采用全自动化数据库变更管理，对变更效果进行监控，如出现查询异常延迟等可以自动发现和修复 |
持续监控和优化数据变更机制 | ||||||
| 度量与反馈 | 度量指标与数据管理 | 度量指标定义 说明：度量指标是度量体系的基础 |
在持续交付部分阶段定义度量指标 | 在持续交付各个阶段定义度量指标，度量指标仅限于部门内部 | 建立跨组织度量指标，进行跨领域综合维度的度量（需说明：度量指标的用户与作用） | 1)
整个团队共享核心业务度量指标 2) 建立基于能力成熟度模型的完整度量体系（补偿度量指标体系） |
持续优化的度量指标，团队自我驱动持续改进 | ||||
| 度量指标类型 | 无 | 度量指标以结果指标为主，如变更频率，需求交付前置时间，变更失败率和平均修复时间 | 度量指标覆盖过程指标，客观反映组织研发现状（可以列举需要覆盖的领域指标） | 度量指标覆盖探索性指标，并展示趋势，预测潜在问题，并及时预警 说明：探索性指标是指趋势与预测，比如：每个迭代的缺陷数量趋势、测试的需求覆盖率，缺陷严重级别的分布等 |
建立度量指标的有效反馈机制，并持续优化度量指标分类 | ||||||
| 度量数据管理 | 度量数据是临时性的 | 度量数据采用抽样方法收集 | 1）持续收集度量数据 2）历史度量数据有明确的管理规则 |
对历史度量数据进行有效的挖掘分析 | 同上 | ||||||
| 度量指标更新 | 无 | 度量指标的设立后变更周期较长 | 1)
度量指标可以按照需求定期更新 2) 度量指标的优先级在团队内部达成一致 |
建立完整的度量体系和成熟的度量框架并持续更新 | 度量指标可基于大数据分析和人工智能自动识别和推荐动态调整指标优先级 | ||||||
| 度量驱动改进 | 内容和生成方式 | 度量报告通过手工方式生成 | 1）度量报告以自动化方式生成 2）度量报告具有标准格式定义 |
度量报告进行分类分级并按需生成内容 | 建立跨组织级统一的数据度量平台 度量报告基于平台定制化生成，支持多种类型，如表格、看板等 说明：增加多类型的图表展示，比如代码提交趋势图，构建成功率，部署成功率，构建耗时趋势等 |
持续优化度量方法，度量平台和度量展现形式 | |||||
| 数据时效性 | 数据和度量报告的时效性存在差异 | 数据报告可展现最新状态 | 通过可视化看板实时展示数据 | 通过可视化看板聚合报告内容多维度展示实时状态支持自动生成数据趋势图和趋势分析 | 同上 | ||||||
| 覆盖范围 | 仅部分人员可查看报告 | 团队内部成员均可查看报告 | 全部团队成员均可查看报告 | 实现报告精准范围推送，支持主动订阅 说明：度量报告可以根据订阅或角色主动推送关注报告的人或角色 |
同上 | ||||||
| 反馈改进 | 度量反馈问题解决周期较长 |
度量反馈的问题录入系统跟踪，并定期实施改进 | 度量反馈问题纳入研发迭代的待办事项列表，作为持续改进的一部分（工作量占比） 说明：通过度量发现的不足，如技术债务升高、团队提交频率不稳定、自动化测试失败率较高等问题纳入迭代的改进列表，持续改进 |
建立度量问题持续改进机制 团队预留工作时间用于解决度量反馈问题 识别有效改进并扩展到整个组织，作为企业级知识体系积累保留 |
通过数据挖掘实现跨组织跨流程数据度量分析，分析结果作为业务决策的重要依据，帮助组织持续改进价值交付流程 | ||||||
| 使用说明： A：自评等级中，3-代表有部分未达到3级技术要求；3代表全部满足3级技术要求，以此类推； B：在统计结果表中可以查看自评结果分布情况，以判断能力成熟度分布； C：本表格基于DevOps标准即研发运营一体化能力成熟度模型第3部分：持续交付内容整理而成； D：灰色字体是对标准的解释说明内容； |
|||||||||||