1、 CHINAUNICOM敏捷与DevOps项目全过程研发管控2018年5月23敏捷与DevOps支撑下的快速研发、高效交付天梯-敏捷研发体系平台1挑战与变革下的敏捷研发DevOps理念与体系#业务人员开发测试人员运维人员最终用户想法市场计划和需求开发和测试发布和部署反馈和优化1stGap2ndGap敏捷DevOps敏捷(Agile)的出现缩小了商业需求与开发直接的隔阂，有效的加快了产品开发的周期和频率。开发和运维之间的隔阂需要解决，DevOps的理念应运而生。#瀑布开发敏捷开发预见性开发模式每一个步骤有严格产出成果人和交互 重于过程和工具可以工作的软件 重于求全而完备的文档客户协作 重于合同谈2、判随时应对变化 重于循规蹈矩设计越完美，成本损失越小不适应快速变化#100%ValuesValues敏捷宣言价值观敏捷宣言价值观1个体和交互胜于流程和工具2可工作软件 胜于 冗长 的文档3与客户协作 胜于合同的谈判4对变化响应 胜于 遵循原计划#敏捷开发是“一种以人为核心、迭代、循序渐进的开发方法”在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。#敏捷研发的目标：任何开发方法和实践必须服务于业务成功，业务需求的快速响应与高质量交付是敏捷研发体系的最终目标；敏捷研发体系的原则：敏捷研发体系是以快速响应变化为基础的背景下产生的一种3、软件交付理念与方法论；敏捷研发没有具象化的实施准则，不同的团队的最佳敏捷实践会不同；需求如何能够快速迭代与响应；需求如何实现高保真、高质量交付；如何提升版本交付效率；如何降低版本交付的成本；平台+应用的高度灵活、扩展性的系统架构；中心化、服务化的应用设计；以前端客户为区分的灰度发布体系；团队成员的水平与能力；敏捷聚焦的问题敏捷实现的前提#敏捷研发的实现主要取决于流程、管理、团队与工具四大关键要素。通过四大要素的优化与协同，提升软件交付的效率与质量是敏捷研发体系的核心所在过程 简单 明确 高效管理 透明化 可视化 可管可控团队 敏捷化 独立化 一体化工具 自动化 便捷化#需求和开发团队对产品业务4、目标达成共识需求分析人员建立和维护产品需求列表（需求会不断新增和改变），并进行优先级排序需求人员每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明需求人员对每轮迭代交付的可工作软件进行验收和反馈回到第3步，开始下一轮迭代23如何支撑快速研发、高效交付1挑战与变革下的敏捷研发DevOps理念与体系敏捷与DevOps支撑下的快速研发、高效交付DevOps是软件开发、运维和质量保证三个团队之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及5、时生产软件产品或服务，以满足某个业务目标，对开发和运维之间相互依存关系的一种新的理解。打破了目前的RD-QA-OP流水线的流程例如：RD每次提交代码触发一系列的自动化步骤，包括编译、单元测试、代码覆盖率、功能测试、部署测试、性能/容量测试，RD，QA,OP都在过程中做质量保障。#Culture(文化)拥抱变革，促进协作和沟通Automation(自动化)将人为干预的环节尽量从价值链中消除Lean(精益)使用敏捷和精益原则促使高频率循环周期题Metrics(度量)与他人分享成功与失败的经验，并在错误中不断学习改进Sharing(分享)度量每一个环节并通过度量数据来持续改进#效能提升效能提升上：上6、：能够有效缩短提交代码到正式部署上线的时间，降低风险；能够自动的、快速的提供反馈，以便及时发现和修复缺陷；能够让软件在整个生命周期中处于可部署状态,能按下按钮，就能将任意版本、按需部署在任意环境中；能够让整个交付过程变成一种可靠、可预期、可视化的过程；文化建设文化建设上：上：团队重组;交叉组合;加强协作;最小边界(岗位轮换，知识共享)；方法与技术方法与技术上：上：软件产品交付过程中IT工具链的打通(开发类工具，部署工具，测试工具，度量工具等)；工作流程和标准的定义(开发提交标准，测试标准，部署标准，质量标准);采用敏捷实践提高开发效率&质量；技术架构上向微服务架构演进降低系统耦合；分工协作上分7、工协作上：与人合作(like one team/face to face);穿他们的鞋走路(put ones shoes);为其他人而工作(for the people)；什么是什么是DevOpsDevOps（DevelopmentDevelopment和和OperationsOperations的组合的组合）:是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例,（此为目标）透过自动化“软件交付”和“架构变更”的流程,（此为方法）来使得软件构建、测试、发布能够更加地高效、快速和可靠（此为结果）。持续改进持续改进上：上：通过对改进过程数据收集、度量8、分析，确定如何对低效过程实施改进；通过工具自动化、工具链信息打通实现协作改进；通过ETC组统一识别、推动改进的持续进行；开发、质量、运维之间紧密协作DevOps是一种体系框架，包含文化建设、组织转型、流程转变，以及一系列的实践方法与支撑工具组合23天梯-敏捷研发体系平台1挑战与变革下的敏捷研发DevOps理念与体系敏捷与DevOps支撑下的快速研发、高效交付#体系建立敏捷提效任务自助内建质量度量改进 建立适用于自身特点的建立适用于自身特点的DevOpsDevOps实践体系实践体系 尽可能清晰定义活动边界和检验标准；敏捷开发模式敏捷开发模式推荐作为DevOps的必选项 选择Scrum+KANB9、AN+XPScrum+KANBAN+XP实践方法 CICD可由非专职人员一键执行，重复执行；能自动化能自动化的流程尽量自动化 CICD流程对接自动化测试自动化测试；代码编写规范及SonarSonar扫描扫描；代码变更代码变更影响分析自动评估；持续集成各环节时长及次数度量；持续交付各环节成功率度量；代码质量各维度度量；根据度量结果进一步优化优化工作流程123455种核心策略#业务人员开发测试人员运维人员最终用户想法市场计划和需求开发和测试发布和部署反馈和优化持续业务计划和需求分析协作式开发持续测试持续监控持续发布和部署DevOps精益和敏捷原理持续改进、持续反馈、持续优化需求快速沉淀到敏捷小组中10、开始迭代各小组认领各自的需求分支和容器化环境，独立开发需求开发部署测试一体化，快速组成发布版本，随时交付需求快速响应多小组众筹研发版本灵活交付同时研发异地多版本多分支多团队 极端情况可持撑全部需求的独立自动化部署、测试、快速交付 支持不停服、用户无感知版本交付 提供正式版本、灰度版本等多版本支持需求研发测试发布Docker版本管理优化提出版本与功能研发分离概念使用Git分布式版本控制，在研发过程中引入多分支，根据需求的优先级不同可随时制定版本计划，动态发布。应用部署测试优化基于容器化平台给不同的小组分配不同的开发测试环境在小组内通过路由算法，可以针对不同的需求内容进行定向部署，测试。自动化程度11、优化 提取各工具之间的配合逻辑，在工具之外做流程的自动化流转。改变目前各工具各自为战的状态，使所有的工具形成一个整体，统一为体系服务。010203基于互联网的敏捷研发体系#全功能运营管理提升全功能团队搭建每个敏捷小组可独立完成需求的分析、研发、测试、发布流程。敏捷配置按照功能划分敏捷小组，以职能为单位，独立管理。人员与团队解耦，灵活调配。团队配置团队之间边界清晰，责任明确。每个团队独立对相关需求的全生命周期负责。能力提升团队内部成员互相学习，成长，通过人员互换，加深业务了解，培养全面型人才传统的敏捷开发模式，注重小而灵的团队开发思路，通过团队内部的快速响应来完成交付目标。但在运营商庞大而复杂的12、需求接收、严格把控的版本交付环境下，项目的管理人员如何能够准确的掌握每一个项目、每一个需求的具体进度成为了困扰我们的难题。针对以上问题，我们设计了不同参与人员各自关注的需求视角加任务视角的敏捷研发过程。需求节点丰富清晰 需求涵盖任务生命周期 需求状态流转自动化 需求验证自动化 需求交付自动化 任务类型明确 任务驱动需求 任务串并行可配置 任务串联自动化#需求的整个生命周期过程由业务需求、需求单元、任务三种工作项来呈现。项目人员只需关注分派给自己的任务，通过任务的完成情况来驱动需求单元及需求的状态变更需求单元做为最小独立可上线业务单元，状态节点需尽量细化：需求分析中 需求分析完 需求评审中 需求13、评审完 设计中 设计完 开发中 开发完 分支合并中 分支合并完 测试环境发布中 测试环境发布完 集成测试中 集成测试完 联调环境发布中 联调环境发布完 联调测试中 联调测试完 生产环境发布中 生产环境发布完 验证中 验证完 BUG修复中 BUG修复完任务根据工作的不同分类型，任务状态只有待分配、活动中、完成三种：需求设计开发合并发布测试#需求研发测试发布运维全过程生命周期管理，覆盖DevOps体系全系流程多维度、多种视角项目监控，透明化项目管理立会制度，全面信息掌握，准确把握项目进展与问题灵活的人员配置，充分调用各级、各小组人员能力，全面服务项目建设项目管理人员管理#需求与研发持续集成、持续测14、试持续交付需求管理流程管理敏捷管理版本管理单元测试自动构建自动测试性能测试仓库管理持续部署XunitTestNGRobotframeworkNexus灰度发布天宫持续集成工具（封装Jenkins）需求管理模块数字化质量分析代码安全扫描Review Board/Gerrit/ATDD（Cucumber）系统漏洞扫描开源软件集中管理单元测试覆盖率SVN/GIT接口测试UI测试自动性能测试仓储管理Maven/Gradle代码影响分析需求管理JmeterKANBAN第三方商业产品工具图例开源软件自建平台工具封装第三方软件#任务卡片、关注工作流标准看板状态：未领取，未开始，进行中，阻塞，完成免费KANB15、AN-Leangoo-Redmine国内：-yugusoft鱼骨#看板中支持Sonar违规修改任务、自动化测试任务、缺陷任务从StoryTask均可以派生缺陷（bug）、测试用例（case）#提交阶段编译单元测试分析构建安装包自动化测试自动化验收测试自动化容量测试手工测试手工测试演示探索性测试发布阶段发布构建好的软件包只要点击一下鼠标，就可以将软件部署到任何目标环境。#持续集成持续集成(CI)(CI)-Continuous Integration大师Martin Fowler对持续集成是这样定义的：持续集成是一种软件开发实践软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集16、成一次至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建自动化的构建（包括编译，部署，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。持续交付持续交付(CD)(CD)-Continuous Delivery持续交付并不是并不是指软件每一个改动都要尽快的部署到产品环境中。它指的是任何的修改都已证明可以在任何时候实施部署已证明可以在任何时候实施部署。Carl Caum(ccaum)August,2013持续交付(Continuous Delivery)是一系列的开发实践方法开发实践方法，用来确保让代码能17、够快速、安全的部署到产品环境中，它通过将每一次改动都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和服务能符合预期。因为使用完全的自动化过程来把每个变更自动的提交到测试环境中，所以当业务开发完成时，你有信心有信心只需要按一次按钮就能将应用安全的部署到产品环境中。Carl Caum(ccaum)August,2013通常将侧重研发侧的过程称为称为CICI（持续持续集成集成），侧重正式环境部署的过程称为侧重正式环境部署的过程称为CDCD（持续交付持续交付）。一般不单独提持续部一般不单独提持续部署署（ContinuousContinuous Deployment)Deployment)18、#统一的版本管控 发布版本管理详细关联具体的任务单信息发布版本管理详细关联具体的任务单信息，防止遗漏和多出任务防止遗漏和多出任务部署版本构建版本部署版本构建版本构建版本构建版本Svn-测试分支Svn-生产分支测试环境生产环境准生产环境交付版本变更范围-需求处理范围-代码&SQL来源-代码分支构建版本部署环境部署版本上线交付范围交付版本#CI/CD整体流程开发活动开发活动、测试活动测试活动、生产交付活动通过生产交付活动通过CICICDCD系统串联自动化并全领域覆盖系统串联自动化并全领域覆盖Agile-敏捷活动CI-持续集成CD-持续交付设计开发需求软件构建(代码&SQL)Sonar扫描单元测试J19、unit应用部署(测试环境)自动化测试(接口&UI)集成测试版本交付应用部署(准生产环境)验收测试应用部署(生产环境)系统运营流程节点可定制#持续集成主要组件：Gitlab+Jenkins+SonarQube+阿里EDAS平台+RF自动化测试套件Jenkins通过Pipeline脚本拉取Gitlab里面的项目并组合编排编译顺序及后续调用编译过程中同步使用Jenkins agent对源码进行sonar检查编译成功后将生成的服务包发送到阿里EDAS平台，使用EDAS来管理服务服务启动成功后自动运行RF自动化测试脚本，生成测试报告TFS收集分析任务测试发布开发人员1开发人员2开发人员3GitlabM20、erge到分布库测试分支应用代码测试脚本生产环境测试环境中央第三方快照通知测试流程开始集成、部署、单元测试、自动化测试pomdeploy拉取测试分支代码拉取开发环境代码拉取代码提交代码#持续的软件版本发布/测试项目监控外部调用执行的工作Jenkins，之前叫做Hudson，是基于Java开发的一种持续集成工具，用于监控持续重复的工作。作为全球领先的开源自动化服务器，Jenkins 提供了数以百计的插件来支持构建、部署和自动化任何项目。发布监控#LBABAAAA路由策略现网环境BBBB灰度发布（蓝绿切换）流程：部分更新服务，并选择更新的实例数（绿色版本）如果更新成功，更新会暂停将部分流量引导至新21、实例，进行测试如果测试通过，可继续更新剩余实例（增加绿版，减少蓝版）如果测试失败，可将服务回滚至旧版本在任何阶段如果更新发生错误，可将服务回滚到旧版本灰度发布：指逐步扩大某一产品特性（版本）的使用范围的过程，在灰度期间，有俩个版本在同时使用；大多数场合下灰度发布也常叫做蓝绿切换、灰白切换或AB切换。#DevOps灰度发布支持策略：1.对于使用第三方云平台的应用，通过DCOS调用云平台的灰度发布能力2.对于使用kubernetes+docker的应用，调用k8s能力进行灰度发布3.对于使用mesos+marathon+docker的应用，调用marathon能力进行灰度发布4.对于自带部署工具的22、应用，如新版订单中心，调用自身的部署工具如ACC的能力进行灰度发布5.对于使用Spring cloud架构(非docker化）的应用，调用Eureka的配置能力进行灰度发布6.对于传统非云化架构的应用，使用滚动发布（分区域逐台替换）的方式进行灰度发布灰度发布相关因素：灰度发布相关因素：用户无感知停机用户无感知停机：在应用切换时在线用户无感知，也叫“应用无状态化”容器化（容器化（dockerdocker）：容器化不是灰度发布必要条件，但是大部分的灰度发布都默认首先要容器化，因为容器便于创建和销毁，具备更高的发布效率和资源使用效率。而传统模式要经历“停止老应用更新版本启动新应用”过程 分布式部署集23、群部署分布式部署集群部署：分布式部署不是灰度发布的必要条件，但是区分正式集群和灰度集群更方便限制灰度应用范围 容量弹性伸缩容量弹性伸缩：可以根据版本发布的需要自动扩展或收缩应用实例的个数，减少资源浪费 灰度配置灰度配置：灰度版本可以拥有自己的配置文件，可以与正式版本区分。通常需要分布式数据库或分库支持。灰度发布版本控制平台灰度发布版本控制平台：控制灰度版本的发布或回退平台，必要条件 灰度路由策略灰度路由策略：灰度发布必要条件#核心价值对软件产品的二进制文件（.class)进行分析，得到版本变更影响的业务范围，从而精确进行产品测试，减小回归测试范围，降低测试时间，同时避免测试遗漏，保证产品质量软24、件产品代码影响分析工具测试指导分析代码级测试覆盖率通过java agent方式监控JVM采集方法动态执行数据，与代码静态分析变更数据比对，从而得到测试覆盖率功能延伸最佳实践：纳入持续集成（CI）流程，自动调用，分析结果可视化展现 分析结果输出到测试环节，以选择小范围回归测试用例 通过代码级测试覆盖率分析，确定热点代码和非核心不常用业务代码，促进代码优化#Sonar效果：1)阻断级违规：405-02)严重级违规：2332-03)代码变更行数：190#接口自动化测试是接口及服务测试工具。主要特点包括：1.支持Http/https,WEB Service,Restful等接口协议2.支持HSF、CS25、F等微服接口协议3.支持接口定义批量导入4.支持从接口报文自动解析接口定义5.支持自动解析WSDL6.支持个性化的报文加解密实施要素：1.每次持续集成（CI）部署必须调用接口自动测试2.每个成员都承担接口测试用例的编写与调试工作，不由专人负责#1、单元测试整体覆盖率27.5%（其中行覆盖率29.7%，分支覆盖率20.8），测试用例总数269702、部分用例采用FUZZ随机测试理念由程序自动生成。#整体流程BACKLOG用户需求用户故事用户故事用户需求用户故事用户故事用户需求用户故事用户故事开发任务测试任务设计任务单元测试验证测试开发任务开发任务BACKLOG障碍问题计划会议：PO主持创建Spr26、int backlog评审会议：PO主持验收用户故事回顾会议：只有团队成员参与好的、待改进、如何改进看板+每日例会：可视化流程鼓励团队沟通产品backlog：条目化用户故事优先级排序按用户故事组织开发和交付Sprint Backlog：经任务分解和估算的用户故事经设计的测试用例可以迭代完成的周期持续集成：自动化随需的软件构建、静态代码扫描、单元测试、部署任务领取编码&单元测试测试用例&自动化测试脚本集成测试环境准生产环境生产环境开发分支测试分支交付(生产)分支持续集成版本发布集成自动化测试UAT测试应用上线UAT测试组织者缺陷反馈开发测试环境自动化部署执行测试+自动化测试敏捷团队组成：干系人 PO ScrumMaster 团队（跨职能，开发，测试等）DevOps平台系统(工具集)用户故事未认领未开始执行中阻塞完成1.1.需求敏捷需求敏捷开发模式开发模式2 2.敏捷活动敏捷活动与看板与看板3 3.团队团队4 4.CI.CICDCD CHINAUNICOM谢谢