资源描述
,转型的灯塔！,DevOps,持续交付能力成熟度模型及最新实践,转型的灯塔！DevOps 持续交付能力成熟度模型及最新实践,1,目录,D,e,v,O,ps,的重要性,1,D,e,v,O,ps,实施的五个关键阶段,2,D,e,v,O,ps,实施的四个要素和七个问题,3,持续交付能力成熟度模型介绍,4,二级应该怎么做,5,目录DevOps的重要性1DevOps实施的五个关键阶段2D,2,为什么D,e,v,O,p,s,很重要,提质增效，行业总体趋势,减少停机时间，更快上线,减少人为错误，更安全，少故障 降低人员流失带来的伤害,您的竞争对手已经在这样做,为什么DevOps很重要提质增效，行业总体趋势,3,D,e,v,O,p,s,实施的五个关键阶段,定目标,理解DevOps，培训赋能，上下对齐，设定共同目标,看现状,评估现有研发流程，技术栈，工具链，文化，管理，组织结构,找差距,对标DevOps能力成熟度模型，找到差距，分析原因，设计方案,画蓝图,绘制DevOps实施路线图,搞事情,小规模试验，探索+调整，复制流程，大规模应用,DevOps实施的五个关键阶段定目标 理解DevOps，,4,流程,基于现有产品研发流程进 行梳理,打通流程的各个环节,保证流程的流畅和闭环,不断优化,可复制的流程管理,规范,需求规范,开发规范,测试规范,部署规范,运维规范,技术,/,平台,技术架构,跨平台，多终端,云服务，自服务,业务管理平台,开发,/,测试,/,部署,/,监控平台,D,e,v,O,p,s,实施的四个要素,可视化,（,DevOps,流水线,+,度量体系）,流程 基于现有产品研发流程进 行梳理规范需求规范技术/平台技,5,DevOps,长什么样？,DevOps,真的有用？,DevOps,真的对我有用？,DevOps,常见路线图,我在哪儿，我做的如何？,我要做什么才能变得更好？,我要用什么工具？,D,evOps 标准,看见,全貌,参考 路线,定位 度量,改进 方向,工具 平台,DevOps,转型与落地，我们需要弄清楚七个问题,DevOps 长什么样？DevOps 标准看见全貌参考 路线,6,主管单位：工信,部,中国信息通信研究院（国家级智库，可信云等出品单位）联合发起,：OSCAR,联,盟,、,DevOps,时代社区、高效运维社区,起草单位：中国信息通信研究院、,D,e,v,O,p,s,时代社区、高效运维社区、,B,A,T,J,、中国移动、中国电信、中国银行、中国太 平洋保险集团等,目前进展：工信部和联合国,ITU-T,正式立项,，2018,年,6,月,29,发布全量送审稿,DevOps,标准：研发运营一体化能力成熟度模型,级别,英文,中文,1,级,Initial,Level,初始级,2,级,Foundation,Level,基础级,3,级,Comprehensive Level,全面级,4,级,Excellent,Level,优秀级,5,级,Fabulous,Level,卓越级,主管单位：工信部 中国信息通信研究院（国家级智库，可信云等出,7,8,1.,具备中等企业,IT,交付水平,2.,集中式管理，在局部建立自动化能力（包括构建、测试、部署与环境配置等）,3.,可按月进行发布，交付时长与质量具备一定水平，部署成功率和业务连续性相对稳定,二级,1.,具备成熟企业,IT,交付水平,（IT,能力是业务支撑）,2.,专业化管理，在全流程建立自动化能力，端到端打通各个交付环节,3.,可按天或周进行发布，内建质量管控，部署失败率低，业务可用性高,4.,具备一定的度量可视化能力，客观体现团队现状和问题,三级,1.,具备顶级互联网,/,科技企业,IT,交付水平,（IT,能力是核心竞争力）,2.,团队自治，实现持续交付平台化，CD,as,Service，并对研发团队进行赋能,3.,每天具备多次发布的能力，团队可按需自行交付，实现业务无中断和高质量,4.,具备较强的度量反馈机制，业务实现良性增长和团队持续改进,四,级,国内先进水平,D,e,v,O,p,s,标准的级别说明,1.具备中等企业IT交付水平2.集中式管理，在局部建立自,9,为了实现二级，我们还有很多问题,版本混乱无法回溯，修复了的,Bug,又出现了,每次集成伴随大量的问题和冲突，集成期间主干长期不可用 迭代,6,次才能上线投产一次，版本如何管理,进度不可控，等待上线时间太长,部署步骤太多太复杂，上线经常失败,为了实现二级，我们还有很多,问题,机会,为了实现二级，我们还有很多问题版本混乱无法回溯，修复了的Bu,10,配置管理,过程域二级,过程域评估维度,一级（初始级）,二级（基础级：自动化/脚本化、小范围）,配置管理,版本控制,版本控制系统,源代码分散在研发本地自行管理,分支管理,无分支策略，或没有统一策略,使用统一的版本控制系统,将全部源代码纳入版本控制系统管理,多条分支长期并行存在且分支合并到主干的周期长,制品管理,1),使用统一的制品库管理构建产物,构建产物分散在研发本地自行管理,2),有清晰的存储结构,单一可信数据源,无,有唯一的版本号,通过统一的制品库地址进行构建产物分发,开发测试部署环节所用到的源代码来源于统一版本控制系统,1),无变更过程,缺乏信息的有效共享机制,1),建立代码基线,2）变更信息分散在每个系统内部,，,2),记录代码变更管理信息,3),针对重点变更内容进行评审,无,1),有清晰定义的版本号规则,2),实现制品和代码基线的关联，可追溯指定版本的完整源代码信,变更过程,变更管理,说明：该 变更是指,需求、代,变更追溯,码等内容,变更回滚,无,息,手工实现回滚,配置管理过程域二级 过程域评估维度一级（初始级）二级（基础,11,构建方式,采用手工方式进行构建，或者严重依赖于,IDE,使用研发人员本地设备构建,构建计划,构建任务不定期执行,没有统一的持续集成服务,持续集成,长期本地开发代码，集成频率几周或者几月一次,代码集成作为软件交付流程中的一个独立阶段,每次集成伴随大量的问题和冲突，集成期间主干长期不可用,构建方式采用手工方式进行构建，或者严重依赖于IDE,12,二级（基础级：自动化/脚本化、小范围）,构建与持续集 成,构建实践,说明：关注软件 代码到可运行程 序之间的过程,过程域二级,过程域评估维度一级（初始级）,构建方式采用手工方式进行构建,采用脚本实现构建过程自动化,构建环境使用研发本地设备构建,构建计划构建任务不定期执行,持续集成,构建职责,集成服务,集成频率,无专人专岗负责构建,无持续集成服务,长期本地开发代码，集成频率几周 或者几月一次,有独立的构建服务器，多种任务共用构建环境,1）,实现每日自动构建,2,）根据发布策略细分构建类型，比如发布构建、测试 构建,构建工具、环境与计划由专人负责维护并有权限管理 搭建统一的持续集成服务,采用团队定期统一集成的策略，代码集成频率几天或 者几周一次,集成方式,在部分分支上进行每天多次的定时构建,反馈周期,代码集成作为软件交付流程中的一 个独立阶段,每次集成伴随大量的问题和冲突，集成期间主干长期不可用,集成问题反馈和解决需要半天或者更长时间,构建与持续集成,二级（基础级：自动化/脚本化、小范围）构建与持续集 成构建实,13,测试分层策略,只进行用户,/,业务级的,UI,测试,无测试分层方法或分层策略,测试介入时机,测试在软件交付过程中在开发完成后才介入,手工测试为主，自动化程度低,自动化测试,自动化测试脚本与工具分散管理,测试执行以周为单位,手工对测试结果进行分析判断,测试分层策略只进行用户/业务级的UI测试,14,二级（基础级：自动化,/,脚本化、小范围）,测试管理,略,测试分层,策,求。,过程域二级,过程域评估维度一级（初始级）,分层方法,说明：分层方法是测试体系按照不同,的测试对象，类型进行分类聚合的方,只进行用户,/,业务级的UI测试 法，每一层对应了特有的测试需,采用接口,/,服务级测试对模块,/,服务进行覆盖全面的接口测试；,采用代码级测试对核心模块的函数或类方法进行单元测试；,对系统进行基本的性能测试,分层策略,说明：分层策略是指基于测试分层策,无测试分层策略,1),已建立测试分层策略,2),测试设计以对用户,/,业务级UI测试为主，辅以少量的接口,/,服务级,测试,略对每部分的测试比重和投入，以及 覆盖度等的划分策略。,测试时机,测试在软件交付过程中在开发完,1),测试在持续交付过程中的介入时间提前到开发的集成阶段,成后才介入2),接口,/,服务级测试在模块的接口开发完成后进行,自动化测试,自动化设计,说明：自动化设计是指测试分层中各,无,对用户,/,业务级的U,I,测试进行自动化设计,种测试类型的自动化设计方法，用于 指导自动化测试工作的有效执,行。,自动化开发,自动化测试脚本与工具分散管理,1),设置专人专岗统一管理自动化测试脚本与工具,2),使用版本控制系统对自动化测试脚本进行有效管理,自动化执行,手工测试为主，自动化程度低,1),对用户,/,业务级UI测试采用自动化测试,测试执行以周为单位2),自动化测试的执行效率较低，以天为单位,自动化分析,手工对测试结果进行分析判断,对自动化测试结果具备一定的自动判断能力，存在一定的误报,测试管理,二级（基础级：自动化/脚本化、小范围）测试管理略测试分层策求,15,灰度测试,每周,每日测试,每日,服务测试,定时（1,2小时）,可用性测试,提交即测试（5,10分钟）,稳定性测试,验收测试,/,人工测试,灰度测试,压力测试,/,异常测试,系统测试,验收测试,/,人工测试,功能测试,/,新功能测试,回归测试,集成测试,单元测试,冒烟测试,功能测试,建立测试分级体系，从不同,级别,和,频率,进行全面的质量保障。,UI,测试,服务测试,单元测试,建立测试分级体系,灰度测试每日测试服务测试可用性测试稳定性测试灰度测试建立测试,16,质量规约,&,环境管理,过程域二级过程域,评估维度,一级（初始级）,二级（基础级：自动化,/,脚本化、小范围）,代码质量,代码质量管 管理理,质量规约,具备初始代码质量规约，规约停留在个人级,1),建立团队级代码质量规约,2),规约范围覆盖部分代码质量指标，如：,代码规范、错误和圈复杂度、重复度等质量,指标,检查方式,代码质量检查采用人工方式进行评审,反馈处理,无代码质量检查结果处理机制，存在大量技术债,代码质量检查采用自动化结合手工方式进行,对代码质量检查结果给出反馈，只处理部分,检查结果,环境管理,环境管理,环境类型,环境类型只有生产环境和非生产环境的划分,建立功能测试环境,环境构建,1),环境构建通过自动化来完成,2),环境准备时间以天为单位,环境依赖 与配置管理,人工创建环境,环境准备时间长，需要几周完成,无依赖管理,环境的管理为操作系统的交付方式,通过配置管理工具实现操作系统级别的依赖,管理，比如说操作系统版本、组件版本、程,序包版本等等,质量规约&环境管理过程域二级过程域评估维度一级（初始级）二,17,二级（基础级：自动化,/,脚本化、小范围）,部署与发布 管理,过程域二级,过程域评估维度一级（初始级）,部署方式运维人员手工完成所有环境的部署 部署过程部署过程存在较长的服务中止时间,部署与发,布模式,部署策略,采用定期部署策略，部署频率以月为单位,单次部署包含大量需求,运维人员通过自动化脚本实现部署,部署过程部分自动化,部署过程通过流程文档实现标准化,采用定期部署策略，部署频率以周为单位,应用作为部署的最小单位,应用和数据库部署实现分离,实现测试环境的自动化部署,部署质量,1),部署整体失败率较高,1),部署失败率中等,2),部署无法实现回滚，生产问题只能在线上修复,，,2),实现应用部署的回滚操作，问题可及时修复,线,协作模式,修复时间不可控,整个软件交付过程严格遵循预先计划,存在复杂的部门间协作和等待,3),只有在开发完成后才进行测试和部署,部署流,水,流水线过程,软件交付过程中的大部分工作通过手工方式完成,1),交付过程中
展开阅读全文