研发运营一体化能力成熟度模型 第3部分:持续交付过程

云玉环

2018/05/13 发布于 技术 分类

第九届 GOPS 全球运维大会将于2018年4月13日-14日在深圳召开。大会为期2天,侧重方向是 AIOps、运维自动化和 DevOps。

文字内容
1. 技 术 标 准 研发运营一体化能力成熟度模型 第 3 部分:持续交付过程 The DevOps capability maturity model Part 3: Continuous delivery process (征求意见稿) 2017 年 11 月 18 日
2. YDB XXXXX—XXXX 目次 目次...................................................................................I 前言..................................................................错误! 未定义书签。 研发运营一体化.........................................................................1 1 范围 ...............................................................................1 2 规范性引用文件 .....................................................................1 3 术语 ...............................................................................1 下列术语和定义适用于本文件。 .........................................................1 3.1 AB 测试 ab test ..............................................................1 3.2 制品 artifact ...............................................................1 3.3 代码复杂度 code complexity ..................................................1 3.4 部署流水线 deployment pipeline ..............................................1 4 缩略语 .............................................................................2 5 综述 ...............................................................................2 6 配置管理 ...........................................................................2 6.1 版本控制 ....................................................................2 6.2 版本可追溯性 ................................................................3 7 构建与持续集成 .....................................................................4 7.1 构建实践 ....................................................................4 7.2 持续集成 ....................................................................5 8 测试管理 ...........................................................................5 8.1 测试分层策略 ................................................................6 8.2 代码质量管理 ................................................................6 8.3 自动化测试 ..................................................................7 9 部署与发布管理 .....................................................................8 9.1 部署与发布模式 ..............................................................8 9.2 持续部署流水线 ..............................................................9 10 环境管理 ..........................................................................9 11 数据管理 .........................................................................10 11.1 测试数据管理 ..............................................................10 11.2 数据变更管理 ..............................................................11 12 度量与反馈 .......................................................................12 12.1 度量指标 ..................................................................12 12.2 度量驱动改进 ..............................................................13 I
3. 前言 YDB XXXXX—XXXX 研发运营一体化是指在 IT 软件及相关服务的研发及交付过程中,将应用的需求、开发、测试、部 署和运营统一起来,基于整个组织的协作和应用架构的优化,实现敏捷开发、持续交付和应用运营的无 缝集成。帮助企业提升 IT 效能,在保证稳定的同时,快速交付高质量的软件及服务,灵活应对快速变 化的业务需求和市场环境。 本标准是“研发运营一体化能力成熟度模型”系列标准的第 3 部分,该系列标准的结构和名称如 下: § 第 1 部分:总体架构 § 第 2 部分:敏捷开发管理过程 § 第 3 部分:持续交付过程 § 第 4 部分:技术运营过程 § 第 5 部分:应用架构 § 第 6 部分:安全管理 § 第 7 部分:组织结构 本标准按照 GB/T 1.1-2009 给出的规则起草。 本标准由中国通信标准化协会提出并归口。 本标准起草单位: DevOps 时代社区、高效运维社区、中国信息通信研究院、深圳优维科技有限公 司、中兴通信股份有限公司 本标准主要起草人:石雪峰、张乐、景韵、王津银、鞠炜刚、萧田国、栗蔚 II
4. 研发运营一体化 总体架构及能力成熟度模型 1 范围 本标准规定了研发运营一体化的持续交付过程及能力成熟度模型。本标准中的研发运营一体化包括 IT软件及服务的需求、开发、测试、部署和运营五个环节,并实现敏捷开发、持续交付和技术运营的顺 序闭环集成。 本标准适用于企业在实施IT软件开发和服务过程中实现研发运营一体化架构,提升IT效能。 2 规范性引用文件 下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件,仅所注日期的 版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。 [1] GB/T 32400-2015 信息技术 云计算 概览与词汇 [2] GB/T 32399-2015 信息技术 云计算 参考架构 [3] YD/T2441-2013 互联网数据中心技术及分级分类标准 [4] GB/T 33136-2016 信息技术服务数据中心服务能力成熟度模型 3 术语 下列术语和定义适用于本文件。 3.1 AB 测试 ab test 为Web或App界面或流程制作两个(A/B)或多个(A/B/n)版本,在同一时间维度,分别让组成成分 相同(相似)的访客群组随机的访问这些版本,收集各群组的用户体验数据和业务数据,最后分析评估 出最好版本正式采用。 3.2 制品 artifact 即构建过程的输出物,包括软件包,测试报告,应用配置文件等。 3.3 代码复杂度 code complexity 主要度量指标为圈复杂度,即代码中线性独立路径的数量。 3.4 部署流水线 deployment pipeline 指软件从版本控制库到用户手中这一过程的自动化表现形式。 1
5. 4 缩略语 下列缩略语适用于本文件。 CI Continuous Integration 持续集成 CD Continuous Delivery 持续交付 MVP Most Variable Product 最小可行产品 DEEP Principle Detailed Appropriately,Estimated,Emergent,Prioritized principle 适 当细化的,有估算的,随时产生的,有优先级的原则 UI User Interface 用户界面 UAT User Acceptance Testing 用户验收测试 OS Operation System 操作系统 5 综述 持续交付是指以可持续的方式将各类变更(包括新功能、缺陷修复、配置变化、实验等)安全、快 速、高质量地落实到生产环境或用户手中的能力。  持续交付的分级技术要求包括:配置管理、构建与持续集成、测试管理、部署与发布管理、环境管 理、数据管理、度量与反馈等,如图1所示。    /   ;0+' /= $4+' :1 +' &+' +' < > % % 97 6 /= $4,*( )5<+' $42 :1 ! /:1#"- &. &@3 $4+'  +' < 
6. 级别 版本控制系统 分支管理 构建产物管理 单一可信数据源 未使用统一的版本 未使用统一的制品库,构 缺乏明确的分支管理 控制系统,源代码 建产物通过直接拷贝或 1 策略,分支生命周期 无 分散在研发本地设 本地共享等方式进行分 混乱 备管理 发 使用统一的制品库管理 使用集中式的版本 采取长周期和大批量 构建产物,有清晰的分级 控 制 系 统 并 将 所 有 的方式进行代码提交, 2 和目录结构及权限管控 无 源代码纳入系统管 代码合并过程存在大 并通过单一制品库地址 理 量冲突和错误 进行分发 使用分布式的版本 控制系统,并将所有 采取短分支频繁提交 使 用 统 一 的 制 品 库 管 理 版本控制系统和制品库 源代码、配置文件、 的方式,研发人员至少 构建产物,并将二进制库 3 作为单一可信数据源,覆 构建和部署等自动 每天完成一次代码提 文件和三方依赖软件工 盖生产部署环节 化 脚 本 纳 入 系 统 管 交,代码合并过程顺畅 具等纳入制品库管理 理 将数据库变更脚本 对制品库完成分级管理, 和环境配置等纳入 分支策略满足持续交 有成熟的备份恢复清理 单一可信数据源进一步 4 版本控制系统管理 付需求,可灵活适应产 策略,如采用使用分布式 覆盖研发本地环境 版 本 控 制 系 统 支 持 品交付 制品库 自动化的变更操作 将软件生命周期的 单一可信数据源贯穿整 所有配置项纳入版 持续优化的分支管理 研发价值流交付过程 5 本控制系统管理,可 策略,可支持团队高效 同上 在组织内部开放共享,建 完 整 回 溯 软 件 交 付 协作 立知识积累和经验复用 过程满足审计要求 体系 6.2 版本可追溯性 版本可追溯性是指软件系统中的每一次变更都可以追溯变更的详细信息,并向上追溯变更的原始需 求、流转过程等所有关联信息。 可追溯性也是版本回滚的历史依据和实施基础,建立良好的版本可追溯性可实现对任一版本完整环 境流程的自动化,精确回滚,快速重现问题和恢复正常环境。 级别 变更过程 变更追溯 变更回滚 变更过程不受控且变更信 1 息分散在每个系统内部,缺 变更缺乏基本的可追溯性 乏信息的有效共享机制 变更问题定位困难且回滚操作具 有高风险 有清晰定义的软件版本号规则,实 代码变更过程应附带变更 可支持版本间差异对比和代码级 2 现版本和代码的关联,可追溯版本 管理信息 别问题定位和回滚 构建对应的完整源代码信息 3
7. 所有配置项变更由变更管 实现版本控制系统和变更管理系统 实现变更管理系统和版本控制 3 理系统触发,并作为版本控 的自动化关联,信息双向同步和实 系统的同步回滚,保证状态的一 制系统的强制要求 时可追溯 致性 可根据变更管理系统按需快速导 使用同一套变更管理系统 变更依赖被识别和标记,实现数据 出复用软件代码变更集,如建立 4 覆盖从需求到部署发布全 库和环境变更信息的可追溯 从变更管理系统到软件代码变更 流程 集的关系数据库 可视化变更生命周期,支 实现从需求到部署发布各个环节的 支持任何时间点全部状态的自动 5 持全程数据分析管理和满 相关全部信息的全程可追溯 化回滚需求 足审计要求 7 构建与持续集成 构建是将软件源代码通过构建工具转换为可执行程序的过程,一般包含编译和链接两个步骤,将高 级语言代码转换为可执行的机器代码并进行相应的优化,提升运行效率。 持续集成是软件构建过程中的一个最佳实践,在版本控制的基础上,通过频繁的代码提交,自动化 构建和自动化测试,加快软件集成周期和问题反馈速度,从而及时验证系统可用性。 7.1 构建实践 构建实践关注软件代码到可运行程序之间的过程,通过规则、资源和工具的有效结合,提升构建质 量和构建速度,使构建成为一个轻量级,可靠可重复的过程。同时构建产物被明确标识管理,采用清晰 的规则定义版本号和目录结构有助于团队成员可以随时获取到可用版本,以及版本相关的信息,快速验 证回溯版本变更。 级别 构建方式 构建环境 构建计划 构建职责 采用手工方式进行 构建工具和环境受限 使用本地设备,构建环境 没有明确的版本号规则 1 构建,构建过程不可 于团队人员能力,频繁 不可靠 和构建任务计划 重复 手动干预维护 明确定义版本号规则, 实现脚本自动化,通 构建工具和环境由专 有独立的构建服务器,多 并根据发布策略细分构 2 过手工配置完成构 人负责维护,并使用权 种任务共享构建环境 建类型,实现每日自动 建 限隔离 构建 明确定义构建计划和规 定义结构化构建脚 构建环境配置实现标准 构建工具和环境由专 则,实现代码提交触发 3 本,实现模块级共享 化,有独立的构建集群, 门团队维护,并细分团 构建和定期自动执行构 复用和统一维护 单次构建控制在小时级 队人员职责 建 优化构建速度,实现增量 实现构建服务化,可 构建系统服务化提供 化构建和模块化构建,单 分级构建计划,实现按 按需提供接口和用 更多用户使用,构建不 4 次构建控制在分钟级,如 需构建并达到资源和速 户界面用于可视化 再局限于专业团队进 可采用分布式构建集群、 度的有效平衡 构建编排 行 构建缓存等技术 4
8. 持续改进构建性能,实现 持 续 优 化 的 构 建 服 构建资源共享和动态按需 5 务平台,持续改进服 分配回收,如搭建基于云 同上 务易用性 服务虚拟化和容器化的分 布式构建集群 将构建能力赋予全部 团队成员,并按需触发 构建实现快速反馈 7.2 持续集成 持续集成是软件工程领域中的一种最佳实践,即鼓励研发人员频繁的向主干分支提交代码,频率为 至少每天一次。每次提交都触发完整的编译构建和自动化测试流程,缩短反馈周期,出现问题第一时间 进行修复,从而保证软件代码质量,减少大规模代码合并的冲突和问题,让软件随时处于可发布状态。 级 集成服务 别 集成频率 集成方式 反馈周期 没有搭建持续集成 每次集成伴随大量的问题 长期本地开发代码集成 代码集成作为软件交付 1 服务,团队成员缺乏 和冲突,集成期间主干分 频率几周或者几月一次 流程中的一个独立阶段 对持续集成的理解 支长期不可用 搭建统一的持续集 采用团队定期统一集成 在部分分支上进行每天 集成问题反馈和解决需要 2 成服务并对系统进 的策略,代码集成频率 多次的定时构建 半天或者更长时间 行日常维护和管理 几天或者几周一次 每次代码提交触发自动 组建专门的持续集 研发人员至少每天向代 化构建,构建问题通过自 集成问题反馈和解决可以 3 成团队,负责优化持 码主干集成一次 动分析精准推送相关人 在几个小时内完成 续集成系统和服务 员处理 每次代码提交构建触发 自动化测试和静态代码 持续集成嵌入每个 研发人员每天多次向代 检查,测试问题自动上报 研发团队日常活动, 集成问题反馈和解决控制 4 码主干集成,每次集成 变更管理系统,测试结果 实现持续集成系统 在 30 分钟以内完成 代价较低 作为版本质量标准要求, 服务化和自助化 如:采取质量门禁等方式 强化主干代码质量 持续优化和改进团 实现持续集成分级和自 任何变更(代码,配置, 队持续集成服务,实 动化测试分级,满足不同 集成问题反馈和解决控制 5 环境)都会触发完整的 现组织交付能力提 模块和集成阶段的差异 在 10 分钟以内完成 持续集成流程 升 化需求 8 测试管理 测试管理是指一个过程,通过该过程,所有与测试相关的过程、方法被定义。在产品投入生产性运 行之前,验证产品的需求,尽可能地发现并排除软件中的缺陷,从而提高软件的质量。 测试管理又可以分为测试分层策略、代码质量管理、自动化测试等多个维度表述。 5
9. 8.1 测试分层策略 测试分层策略是建立一种分层的测试体系,把测试作为一个整体来规划和执行,融入到持续交付的 各个阶段中,达到质量防护的目的。 级别 分层方法 分层策略 测试时机 只进行用户/业务级的 UI 测 尚未建立测试分层策略,测试不分 测试在软件交付过程中在开发完 1 试 层 成后才介入 采用接口/服务级测试对模 测试开始分层,但对测试分层策略 块/服务进行覆盖全面的接 测试在持续交付过程中的介入时 缺乏系统的规划,对用户/业务级测 口测试;采用代码级测试对 间提前到开发的集成阶段,接口/ 2 试、接口/服务级、代码级测试分布 核心模块的函数或类方法 服务级测试在模块的接口开发完 比例由高到低,各层测试缺乏有效 进行单元测试;对系统进行 成后进行 的设计 基本的性能测试 采用代码级测试对模块的 对测试分层策略进行系统的规划, 函数或类方法进行覆盖全 用户/业务级、接口/服务级、代码级 测试在持续交付过程中的介入时 面的单元测试;系统全面的 测试分布比例由低到高,充分设计; 间提前到开发的编码阶段,代码 3 进行性能、容量、稳定性、 对非功能性测试进行全面系统的设 级测试在模块的函数或类方法开 可靠性、易用性、兼容性、 计 发完成后进行 安全性等非功能性测试 代码级测试在模块的函数或类 采用测试驱动开发的方式 测试分层策略的各层测试具有交叉 方法开发过程中同步进行和完 进行代码级、接口级测试; 4 互补性 成;接口/服务级测试在模块的 采用探索性测试方法对需 接口开发过程中同步进行和完 求进行深入挖掘测试 成 在需求阶段进行用户/业务级测 采用验收测试驱动开发的 定期验证测试分层策略,是否完整、 试设计,在需求特性开发、交付 5 方式进行用户/业务级的 UI 有效,持续优化策略 整个过程中同步进行并完成测 测试 试 8.2 代码质量管理 代码质量管理是在软件研发过程中保证代码质量的一种机制,当代码变更后,可以对代码质量进行 检查、分析,给出结论和改进建议,对代码质量数据进行管理,并可以对代码质量进行追溯。 级 质量规约 别 检查策略 检查方式 反馈处理 代码质量检查无任 代码质量检查无针对检 代码质量检查采用人工 对代码质量检查结果处理 1 何规约 查范围、质量门限等相 方式进行评审 不及时,遗留大量技术债 关的策略 2 代码质量检查具备 代码质量检查有针对检 代码质量检查采用自动 对代码质量检查结果给出 6
10. 基本规约,但还缺乏 完整性和有效性 查范围、质量门限的策 略,对代码规范、错误 和圈复杂度、重复度等 质量指标进行检查分析 化结合手工方式进行 反馈,根据反馈进行处理, 对遗留的部分技术债缺乏 跟踪和管理,导致遗漏 根据代码质量检查结果反 代码质量检查具备 代码质量检查将安全漏 代码质量检查完全自动 馈及时处理,技术债仍有 3 完整、有效和强制执 洞检查、合规检查纳入 化,不需要手工干预 短期遗留,但进行有效的 行的规约 到检查范围 跟踪、管理和处理 将检查结果强制作为版本 代码质量检查针对检查 代码质量检查规约 对代码质量检查发现的 质量标准要求,根据代码 范围、质量门限的策略 4 根据需要可进行扩 部分问题自动提出修改 质量检查提出的修改建 可根据需要灵活调整 展和定制 建议,支持可视化 议,对问题及时处理,在 研发阶段主动解决技术债 具备企业级的代码质量 对代码质量数据进行统一 定期验证代码质量 定期验证代码质量 管理平台,以服务的形式 管理,可有效追溯并对代 5 规 约 的 完 整 性 和 有 策略的完整性和有效 提供对代码质量的检查、 码质量进行有效度量 效性,持续优化 性,持续优化 分析 8.3 自动化测试 自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程,在预设条件下运行系统或应用 程序,执行测试并评估测试结果,以达到节省人力、时间或硬件资源,提高测试效率和准确性。 级 自动化设计 别 自动化开发 自动化执行 自动化分析 尚未对自动化测试脚本 手工对测试结果进行分 未采用自动化方式 手工测试执行效率低 1 进行开发和管理,手工 析判断,错误高,可信度 测试,纯手工测试 下,以周级为单位 测试 低 尚未对测试用例中 自动化部分进行规 对用户/业务级测试采用 对自动化测试脚本进行 对自动化测试结果具备一 划和设计,覆盖不完 自动化测试,自动化测试 2 开发和本地管理 定的自动判断能力,存在 整 的执行效率不高,以天级 一定的误报,可信度不足 为单位 从代码级、接口级到 UI 根据需求、接口和代 自动化测试脚本开发采 级 测 试 实 现 了 端 到 端 的 码 对 不 同 测 试 分 层 用数据驱动、关键字驱 自动化测试打通;自动化 对自动化测试结果具备较 3 中 自 动 化 测 试 用 例 动等方法;使用版本控 测试执行效率较高,代码 强的自动判断能力,误报 进行规划和设计,自 制系统对自动化测试脚 级测试分钟级,UI 级测 少,可信度高 动化覆盖比较完整 本进行有效管理 试小时级 4 对性能、稳定性、可 自动化测试用例脚本间 有 组 织 级 的 统 一 自 动 化 自动化测试数据模型标准 7
11. 靠性、安全性等非功 具备独立性和大批量执 测 试 平 台 , 和 上 下 游 需 化,和上下游需求、故障 能 性 测 试 中 自 动 化 行的健壮性 求、故障系统打通;可以 等研发数据关联,可以对 用例进行规划和设 根据需求针对性自动关 自动化测试效果进行度量 计,自动化覆盖完整 联选择自动化测试用例 分析。例如:需求测试覆 脚本执行;可以将由于版 盖率、测试通过率和测试 本原因导致的失败用例 效率等。 和故障关联 采用企业级统一的自动 对故障和测试进行 化测试平台,以云化的方 对自动化测试结果可以智 自动化脚本是测试用 复盘,对遗漏的测试 式提供测试服务,进行分 能分析,自动分析失败用 例设计的活文档,自动 5 用例进行补充,不断 布式测试调度执行,提高 例的失败类型及原因,可 化脚本开发和测试用 优化和完善,持续提 测试执行效率和资源利 以自动向故障管理系统提 例设计完全统一 升覆盖率 用率;定期验证自动化执 交故障,可信度高 行策略,持续优化 9 部署与发布管理 部署与发布泛指软件生命周期中,将软件应用系统对用户可见,并提供服务的一系列活动,包括系 统配置,发布,安装等。整个部署发布过程复杂,涉及多个团队之间的协作和交付,需要良好的计划和 演练保证部署发布的正确性。 其中部署偏向技术实践,即将软件代码,应用,配置和数据库变更应用到测试环境、准生产环境和 生产环境的过程。发布偏向于业务实践,指将部署完成的应用软件功能和服务正式对用户可见,提供线 上服务的过程。部署和发布的有机结合,实现了软件价值向最终用户的交付。 9.1 部署与发布模式 部署和发布模式关注交付过程中的具体实践,将部署活动自动化并前移到研发阶段,通过频繁的演 练和实践部署活动,成为研发日常工作的一部分,从而减少最终部署的困难和不确定性,可靠可重复的 完成部署发布任务。部署发布模式通过合理规划,分层实施,一方面减少软件最终上线交付风险,同时 可及时获取用户信息反馈,帮助持续改善整个软件交付过程和软件功能定义。 级 部署方式 别 部署活动 部署策略 部署质量 部署整体失败率较高,并 部署过程复杂不可控, 运维人员手工完成 采用定期大批量部署策 且无法实现回滚,生产问 1 伴随大量问题和较长的 所有环境的部署 略 题只能在线上修复,修复 停机时间 时间不可控 应用作为部署的最小单 运维人员通过自动 部署过程通过流程文档 实现应用部署的回滚操 位,应用和数据库部署实 2 化脚本实现部署过 定义实现标准化整体可 作,部署失败率中等,问 现分离,实现测试环境的 程部分自动化 控 题可及时修复 自动化部署 3 部署和发布实现全 使用相同的过程和工具 可运行的环境作为部署 部署活动集成自动化测试 8
12. 自动化,同时支持数 完成所有环境部署,一 的最小单位,应用和配置 功能,并以测试结果为部 据库自动化部署 次部署过程中使用相同 进行分离 署前置条件 的构建产物 每次部署活动提供变更对 象范围报告和测试报告 部署发布服务化,实 部 署 过 程 可 灵 活 响 应 通 过 多 种 部 署 发 布 策 略 建立监控体系跟踪和分析 4 现 交 付 团 队 自 助 一 业务需求变化,通过合 保证流程风险可控,如: 部署过程,出现问题自动 键式多环境自动化 理组合高效编排 蓝绿部署,金丝雀发布 化降级回滚,失败率较低 持续优化的部署发 持续部署,每次变更都 软件交付团队自主进行 持续优化的部署监控体 5 布 模 式 和 工 具 系 统 触发一次自动化生产环 安 全 可 靠 的 部 署 和 发 布 系和测试体系,部署失败 平台 境部署过程 活动 率维持在极低水平 9.2 持续部署流水线 持续部署流水线是DevOps的核心实践,通过可靠可重复的流水线,打通端到端价值流交付,实现交 付过程中各个环节活动的自动化和可视化。部署流水线通过将复杂的软件交付流程细分为多个阶段,每 个阶段层层递进,提升软件交付质量信心,并且在流水线过程中提供快速反馈,减少后端环节浪费。 可视化流水线可以增强跨组织的协同效率,提供有效的信息共享平台,从而统一组织目标,并且不 断识别流水线中的约束点和瓶颈,以及潜在的自动化及协作场景,通过持续改进而不断提升软件交付效 率。 级别 协作模式 流水线过程 过程可视化 整个软件交付过程严格遵循 预先计划,存在复杂的部门 软件交付过程中的大部分工作通 交付过程中的信息是封闭的,交付 1 间协作和等待,只有在开发 过手工方式完成 状态不可追溯 完成后才进行测试和部署 通过定义完整的软件交付过 软件交付过程中的各个环节建立 交付过程在团队内部可见,信息在 2 程和清晰的交付规范,保证 自动化能力以提升处理效率 团队间共享,交付状态可追溯 团队之间交付的有序 打通软件交付过程中的各个环 团队间交付按照约定由系统 节,建立全流程的自动化能力, 交付过程组织内部可见,团队共享 3 间调用完成,仅在必要环节 并根据自动化测试结果控制软件 度量指标 进行手工确认 交付质量 建立可视化部署流水线,覆盖整 团队间依赖解耦,可实现独 部署流水线全员可见,对过程信息 4 个软件交付过程,每次变更都会 立安全的自主部署交付 进行有效聚合分析展示趋势 触发完整的自动化部署流水线 持续优化的交付业务组织 部署流水线过程信息进行数据价 5 灵活响应业务变化改善发 持续部署流水线驱动持续改进 值挖掘,推动业务改进 布效率 10 环境管理 9
13. 环境作为DevOps持续敏捷交付过程中最终的承载,环境的生命周期管理、一致性管理、环境的版本 管理都变得非常重要。环境管理是用最小的代价来达到确保一致性的终极目标。 级 环境类型 别 环境构建 环境依赖与配置管理 环境类型只有生产环境和 1 环境的构建通过人工创建完成 非生产环境的划分 无依赖管理,环境的管理就是一 个 OS 的交付 以应用为中心有 OS 级别的依赖 IT 交付过程意识到部分测 环境构建通过一键化的脚本或者虚 和配置管理能力,比如说操作系 2 试环境的重要性,开始提供 拟机来完成的,构建过程完全黑盒 统版本、组件版本、程序包版本 功能测试环境。 化完成。 等等 持续交付过程意识到研发 以应用为中心,有服务级依赖的 环境的重要性,开始提供面 环境的构建通过资源交付平台来 配置管理能力,比如说依赖的关 3 向各类开发者独立的研发 完成,并且底层是由云来交付 联服务,Mysql 服务、cache 服 工作区。 务、关联应用服务等等 全面的测试与灰度环境对于 质量交付过程来说非常重 环境的构建可以通过 Docker 容器 环境和依赖配置管理可以资源 要,有各类的环境类型划分, 4 化快速交付,低成本构建一个新 化描述,类似 dockerfile,大大 区分了开发者,技术测试及 的环境 提升其配置管理能力 业务测试环境以及灰度发布 环境等等 环境的构建结合底层 IT 资源状 环境依赖和配置可以做到实例 根据业务与应用的需要,弹 5 况,采用了各类混合 IT 技术,根 级的动态配置管理能力,根据业 性分配各类环境 据业务及应用架构弹性构建 务和应用架构的变化而变化 11 数据管理 系统开发过程中为了满足不同环境的测试需求,以及保证生产数据的安全,需要人为准备数量庞大 的测试数据,需保证数据的有效性以适应不同的应用程序版本。另外应用程序在运行过程中会产生大量 数据,这些数据天生有状态,同应用程序本身的生命周期不同,作为应用最有价值的内容需要妥善保存, 并随应用程序的升级和回滚进行迁移。 11.1 测试数据管理 测试数据需要满足多种测试类型的需求(手工测试,自动化测试),覆盖正常状态,错误状态和边 际状态,测试数据需同时满足测试效率和数据量的要求。测试数据的输入需要受控,并运行在受控环境 中,保证输出的有效性,同时由于持久数据的必要行,要避免数据被未授权的篡改,以影响测试结果的 客观一致性。为了模拟类生产环境系统运行情况,常采用仿生产环境数据,此类测试数据在使用时需要 注意数据安全,避免敏感用户数据泄露,及时进行数据清洗和漂白。 级 数据来源 别 数据覆盖 数据独立性 数据安全 10
14. 每次测试时手工创 测试数据覆盖率低,仅 测试数据来源复杂,混入 测试数据没有版本控制 1 建数据,测试数据都 支持部分测试场景,无 核心生产数据,带来信息 和备份恢复机制 是临时性的 法有效支持测试工作 安全风险 测试数据覆盖主要场 从生产环境导出一 景,包括正常类型,错 个子集并进行清洗 测试数据有明确备份恢 测试数据经过清洗,不包 误类型以及边界类型, 2 后,形成基准的测试 复机制,实现测试数据 含敏感信息,有效避免信 并进行初步的分类分 数据集,满足部分测 复用和保证测试一致性 息安全风险 级,满足不同测试类型 试用例执行要求 需要 每个测试用例拥有专 建立体系化测试数据, 属的测试数据,有明确 3 同上 进行数据依赖管理,覆 的测试初始状态 同上 盖更加复杂的业务场 测试用例的执行不依 景 赖其他测试用例执行 所产生的数据 每个测试用例专属 通过测试数据分级,实 的测试数据都可以 测试数据覆盖安全漏洞 现专属测试数据和通 4 通 过 模 拟 或 调 用 应 和开源合规等需求场景 用 测 试 数 据 的 有 效 管 同上 用程序 API 的方式 并建立定期更新机制 理和灵活组合,保证测 自动生成 试数据的独立性 所有的功能、非功能 测试的测试数据,都 可以通过模拟、数据 持续优化的持续数据管 5 同上 库 转 储 或 调 用 应 用 理方式和策略 同上 程序 API 的方式自 动生成 11.2 数据变更管理 数据变更管理主要关注应用程序升级和回滚过程中的数据库结构和数据的变更,良好的变更管理策 略可以保证应用版本和数据库版本兼容匹配,以应对应用的快速扩容缩容等线上场景。通过应用变更和 数据变更的解耦,减少系统变更的相互依赖,实施灵活的升级部署。 级 变更过程 别 兼容回滚 版本控制 数据监控 数据变更由专业人 员在后台手工完成 没有识别数据库和应 数据变更没有纳入版本 没有建立变更监控体系, 1 数 据 变 更 作 为 软 件 用版本,存在不兼容风 控制,变更过程不可重复 变更结果不可见 发布的一个独立环 险 节,单独实施和交付 数据变更通过文档 建立数据库和应用的版 数据变更脚本纳入版本 对变更日志进行收集分 2 实现标准化,使用自 本对应关系,并跟踪变 控制,并与数据库版本进 析,帮助问题快速定位 动化脚本完成变更 更有效性 行关联 11
15. 数据变更作为持续 每次数据变更同时提供 部署流水线的一个 明确的恢复回滚机制, 3 环节,随应用的部署 并进行变更测试,如: 同上 自动化完成,无需专 提供升级和回滚两个自 业人员单独执行 动化脚本 应用程序部署和数 数据变更具备向下兼容 4 据库迁移解耦,可单 性,支持保留数据的回 同上 独执行 滚操作和零停机部署 持续优化的数据管 5 理方法,持续改进数 同上 同上 据管理效率 对数据变更进行流程分级 定义,应对不同环境下的 高危操作 对数据变更进行监控,自 动发现异常变更状态 监控数据库性能并持续优 化 12 度量与反馈 DevOps基于精益思想发展而来,其中持续改进是精益思想的核心理念之一。DevOps主张在持续交付 的每一个环节建立有效的度量和反馈机制,其中通过设立清晰可量化的度量指标,有助于衡量改进效果 和实际产出,并不断迭代后续改进方向。另外设立及时有效的反馈机制,可以加快信息传递速率,有助 于在初期发现问题,解决问题,并及时修正目标,减少后续返工带来的成本浪费。度量和反馈可以保证 整个团队内部信息获取的及时性和一致性,避免信息不同步导致的问题,明确业务价值交付目标和状态, 推进端到端价值的快速有效流动。 12.1 度量指标 度量指标的拣选和设定是度量和反馈的前提和基础,科学合理的设定度量指标有助于改进目标的达 成。在拣选度量指标时需要关注两个方面,即度量指标的合理性和度量指标的有效性,合理性方面依托 于对当前业务价值流的分析,从过程指标和结果指标两个维度来识别DevOps实施结果,以及整个软件交 付过程的改进方向;有效性方面一般遵循SMART原则,即指标必须是具体的、可衡量的、可达到的、同 其他目标相关的和有明确的截止时间,通过这五大原则可以保证目标的科学有效。 级 度量指标定义 别 度量指标类型 度量数据管理 度量指标更新 度量指标没有明确 1 定义,对度量价值的 无 理解是模糊的 度量数据是临时性的,没 无 有收集管理 在持续交付各个阶 度量指标以结果指标为 度量数据的收集是离散 度量指标的设立和更新是 段定义度量指标,度 主,如变更频率,需求 2 的不连续的,历史度量数 固化的,度量指标没有明 量指标局限于职能 交付前置时间,变更失 据没有进行有效管理 确的优先级 部门内部 败率和平均修复时间, 度量指标的设立和更新是 建立跨组织度量指 度量指标覆盖过程指 度量数据的收集是连续 动态的,可以按照组织需 3 标,进行跨领域综合 标,客观反映组织研发 的,历史度量数据有明确 求定期变更,度量指标的 维度的度量 现状 的管理规则 优先级在团队内部可以达 12
16. 成一致 整个研发团队共享 建立完整的度量体系和成 业务价值导向的度 度量指标覆盖探索性指 度量数据的收集是连续 熟的度量框架,度量指标 4 量指标,实现指标的 标,关注展示趋势和识 且优化的,对历史数据数 的设立和更新可按需实现 抽象分级,关注核心 别潜在改进 据进行有效的挖掘分析 快 速 定 义 并 纳 入 度 量 体 业务指标 系,推动流程的持续改进 支持改进目标和试验结 持续优化的度量指 果的有效反馈,用于经 5 标,团队自我驱动持 同上 验积累和指导下一阶段 续改进 的改进工作 度量指标可基于大数据分 析和人工智能自动识别推 荐,并且动态调整指标优 先级 表1:部分参考过程度量指标 阶段 需求 版本控制 构建 代码 环境 部署 12.2 度量驱动改进 度量指标 需求总数 各个状态需求数量 需求完成数量 需求平均时长 代码仓库数量 代码提交数 代码提交频率 代码提交时间分布 构建次数 构建频率 构建时长 构建失败率 构建修复时间 构建类型 代码行数 代码复杂度 代码重复率 单元测试覆盖率 单元测试用例数 单元测试成功率 环境变更时长 变更频率 容器镜像更新 活跃容器数量 资源使用统计 部署版本数量 部署时间 部署成功率 部署回滚率 13
17. 度量驱动改进关注软件交付过程中各种度量数据数据的收集,统计,分析和反馈,通过可视化的度 量数据客观反映整个研发过程的状态,以全局视角分析系统约束点,并在团队内部共享,帮助设立客观 有效的改进目标,并调动团队资源进行优化.同时对行之有效的改进项目进行总结分享,帮助更大范围 组织受益于改进项目的效果,打造学习型组织和信息共享,不断驱动持续改进和价值交付。 级 报告生成方式 别 报告有效性 报告覆盖范围 反馈改进 度量报告通过手工 报告发现的问题没有进行 方式生成,没有标准 受众局限于报告生成人 1 数据时效性无法保证 有效跟踪落实,问题长期 化的格式定义,内容 员及相关的小范围内部 无法改进 缺乏细节 度量报告以自动化 由预先定义的事件触发 测试报告中反馈的问题录 方式生成,通过预定 数据体现报告生成时间 2 自动化报告发送,受众覆 入问题追踪系统,进行持 义 格 式 和 内 容 标 准 点的最新状态 盖团队内部成员 续跟踪 化度量报告 度量报告进行分类 实现报告精准范围推送, 度量反馈问题纳入研发迭 分级,建立多种度量 通过可视化看板实时展 3 支持主动订阅,受众覆盖 代的待办事项,作为持续 反馈渠道,内容按需 示数据 跨部门团队 改进的一部分 生成 度量反馈的持续改进纳入 研发日常工作,预留时间 建立跨组织级统一 通过可视化看板聚合报 多维度产品状态实时信 处理非功能性需求和技术 4 的数据度量平台,数 告内容,自动生成趋势 息展示 债务,并且识别有效改进 据看板内容可定制 图,进行趋势分析 并扩展到整个组织,作为 企业级知识体系积累保留 通过数据挖掘实现跨组织 持续优化的度量方 5 同上 法,平台和展现形式 同上 跨流程数据度量分析,分 析结果作为业务决策的重 要依据,帮助组织持续改 进价值交付流程 14