持续交付与DevOps

,DevOpsEssentials,CI/CD/Agile/LEAN,梁博,敏捷教练OpenStackExpertise,10+yearsProgrammingExp.MicrosoftMSFRedHatOpenShiftExpertiseRedHatVirtualizationExpertiseOpenStackCertifiedAdministratorOpenStackContributor,软件交付流程一,需求,部署,开发,软件交付流程二,产品,收集需求,文档,价值评审,优先级,原型,立项,开发,计划,设计评审测试评审,测试,Fix,回归测试,UAT,辩论,运维,上线签字,准备环境,配置,部署,交付,沟通,发布,反馈,开发,需求评审,观后感-什么是DevOps,开发和It运维之间的高度协同高频部署的同时，提供生产环境的可靠性、稳定性、弹性和安全性价值流业务(需求定义)客户(价值交付)起源于2009年前后一天10次部署(JohnAllspaw,PaulHammond)基础设施即代码(MarkBurgess,LukeKanies)敏捷基础设施(AndrewShafer)敏捷系统管理(PatrickDebois)精益创业(EricRies)持续集成和发布(JezHumble)平台即服务(AWS),GotoMarket,featurecycletime,time,Customer,Users,GotoMarket,featurecycletime,time,Customer,Users,minimize,GotoMarket,featurecycletime,time,Customer,Users,minimize,这才是你创造的价值,GotoMarket,featurecycletime,time,Customer,Users,minimize,这才是你创造的价值,You,GotoMarket,featurecycletime,time,Customer,Users,minimize,You,一切都是围绕着尽快将新的功能交付到用户手上,冲突,关于DevOps你必须知道的几件事,ResolvingissueswithoutDevOps,Operationsgetsnotifiedofapplicationproblem.,Customerfindsproblemwithyourapplication.,我们的Dev&Ops,DEV,OPS,BUSINESS,别人家的DevOps,协作为何如此重要,Production,Development,Operate+learn,Plan,Develop+test,Release,Requirements,别人家的DevOps,Source,Build,Test/issues,Deployment,Application,Operations,Processtools,Cloud,On-premises,别人家的工具,Source,Build,Test/issues,Deploy,App,Ops,Processtools,Gradle,Grunt,别人家的发布流程,Dev,test,Pre-pROD,pRODUCTION,Stages,Environments,Actions,Approvers,ReleasePaths,IT的革新进程,IT的革新进程,IT的革新进程,DevOps典型模型,Scrum,DevOps典型模型,DevOps持续集成,为什么要持续集成,快速反馈减少项目风险每个人都是项目的Owner持续开发将一些重复的事情交给机器去做,持续集成最佳实践,单一代码仓库经常提交(CommitOften)让你的Build可以自动化测试自动构建快速构建,CI/CD角色分工,CI/CD角色定义,工作描述,减少风险减少重复过程任何事件、任何地点生成可部署的软件增强项目的可见性建立团队对开发产品的信心,CI搭建骨架,CI搭建填充,持续测试(测试策略),Selenium：用于自动化测试DashboardUITempest：用于自动化测试OpenStackAPIRally：用于自动化测试OpenStack性能UnitTests：用于每个项目的单元测试,持续审查,持续审查,持续审查,持续审查,持续审查,持续部署,Why?CreateapplicationruntimeenvironmentsondemandFast,reliable,repeatableandpredictableoutcomesConsistentenvironmentsinstagingandproductionMakesreleasedaysriskless,almostboringWhat?OperatingSystems,DriversMiddleware,Databases,etc.Applications,Dependencies,DataHow?InfrastructureasCode!KeepeverythinginVersionControlCodeConfigurationDataAlignDevelopmentandOperations,+Configuration,Everythingthataffectsapplicationstate,持续部署,持续部署,持续部署,持续部署,持续部署,持续反馈,一对一反馈集体反馈书面反馈反馈训练反馈工具自动反馈,构建流水线,构建流水线,构建流水线,源代码管理,本地版本控制集中版本控制分布式版本控制,环境定义,自动化配置管理,自动化监控,自动化监控-HA,敏捷看板管理,看板方法,看板方法可以动态显示瓶颈,敏捷VS看板,敏捷VS看板,生命周期模型是如何的，工序如何划分如何通过历史生产率确定资源的配置项目的完成进度是否是以各个故事卡的最终完成比例确定的是否对故事卡进行了群和组的划分，以实现迭代交付项目的实际进度和每个成员的在做工作在看板上都能够体现一个是团队总的等待时间，一个是返工时间，如何消除浪费,可视化沟通,借助看板和故事卡基于数据沟通基于历史事件沟通基于任务沟通,可视化沟通,用户故事划分,主要是要从客户角度对用户故事进行划分，具体可以：按照不同操作添加、删除、修改、浏览等按照数据可以浏览产品名和介绍、可以浏览产品价格按照特性易用性、性能、兼容性、并发性等等按照角色从不同用户角度按照投入的人力比如要完成信用卡支付(Visa,Master,AmericanExperess)，可以分成三个故事来实现。,将大的故事分成小块,减少等待下游的成员不必要等待过长的时间，小用户故事在系统内的流转会更快，从宏观来说变成了一个并行模式而不是串行模式。加快反馈每一个小功能的完成都是一个反馈点，可以及时沟通信息。大块需求导致很多需求的缺陷往往到最终测试的时候才能发现，如果不能及早完成，尽快测试，缺陷会越来越难以解决。软件很少一次就做好。多次反馈（至少三次）及不断演进才是一个真正把功能做好的策略。减少缺陷沟通更加及时，有问题可以及时发现，立刻解决，而不需要过长时间的等待。更好的衡量进度可以工作的软件能够更好、更真实地反映项目进度状况。人天生只能关注很小部分精力和智力所限。较少的投入获得较早的回报这样可以尽早的达到成本与收入的平衡点。风险小小的功能投入的资源较少。更容易分优先级大块用户故事中难免还有优先级较低的小用户故事，通过细分，可以真正关注高优先级的用户故事。更容易让每个人接触不同的用户故事用户故事变小，也会更简单，因此很容易让不同人同时去完成。,用户的故事越小越好,完成的定义DefinitionofDone,开发阶段用户故事得到PO的验证代码得到静态分析新增代码人工评审用户故事有相应的测试用例发布阶段完成发布规则要求的重点内容通过发布的全量测试回归测试为全部修复所有等级为1、2、3的缺陷4级及4级以下的缺陷不超过200个1、2级缺陷必须修复，3级缺陷经过带缺陷审批后可以发布,每日DoD,日构建环境下班前必须CheckIn当天的代码或第二天邀请同伴评审的代码持续集成环境，上午、下午至少签入一次TDD，代码必须有对应的单元测试,UserStoryDoD,用户故事最终的描述符合需求用户故事的测试用例的对应覆盖用户故事得到对应的自动化测试用例用户故事得到用户代表认可,每周DoD,上上周发现的缺陷是否解决上周新增功能的自动化测试是否加入到测试集,故事在何时完成,已完成所有的任务(开发、测试和记录)正在运行和通过所有验收测试无开放的缺陷Po全部验收交付用户,敏捷估算,相对估算，使用故事点数为单位规模估算，规模的计量单位是故事点，和人天，时间无关估算关注团队速度，而不是个人速度通过总规模和团队速度，推算周期,敏捷估算,敏捷估算,对估算技术的认知使用小任务单元团队合作询问正确的问题记录您的实际工作,迭代计划,定义迭代迭代演示迭代计划会议每日站会,迭代计划,需求人员与测试人员精化用户故事每天召开站会（可选）PO逐条讲解用户故事(故事的Owner可参与)石头故事、钻石故事说服开发人员归类钻石故事估算工作量,知道迭代工作量饱和PO参与讨论，但不干涉结果方案设计明确责任人,迭代计划思考常见问题,为什么分给组，而不是个人?为什么不让领取任务的人估算?为什么不让师傅估算，大家直接采纳?为什么PO还要参加？,自动化测试简介,大量机械的、重复性的回归测试结果正确性不依赖主管判断的测试需要模拟大量数据、大量并发的测试需要不间断执行的测试需要短时间内完成的大量测试用例,测试成熟度,对自己开发的项目有足够的了解根据输入输出的特点选择合适的测试工具由谁来测试测试义务测试责任,结对开发,优点:,互相帮助，互相学习让编程环境有效贯彻设计增强代码和产品质量，减少BUG降低学习成本互相讨论,结对开发,缺点,不同习惯可能导致矛盾程序员各执己见注意力分散应付工时，敷衍了事有人更喜欢单兵作战,重构,封装EncapsulateField提取方法ExtractMethod一般化类型GeneralizeType函数归父PullUp函数归子PushDown方法更名RenameMethod,重构,IntelliJIDEAEclipseNetBeansCodeGearVisualStudio,重构,重构不是必须要做的，但是是学习型组织不可缺少的重构帮助团队了解项目的细节不要为了重构而重构在相应的设计下进行重构重构不等于重新做一遍,缺陷管理,观点：不要把缺陷称之为Bug缺陷是产品的错误表现，不符合客户预期立刻处理缺陷,缺陷管理工具,JIRABugZeroRedmineTrac,敏捷回顾,尽早确认，时常处理保持初心希望改变或者提出改进记录回顾，收集反馈限制范围蔓延小型成功提升积极性,吞吐率,吞吐率用于估算,若每个人只能处理一个单独的故事，那么我们至少需要5个人才能按时完成任务。出于安全考虑（这里没有精确的公式），我们最好组建一个6人团队来开展工作。:-),交付率（吞吐率）是为了满足客户可接受的最后交付期限所需要达到的目标速率。基于此，我们计算出期间需要处理的工作项数量。例如，若一个故事的前置时间是0.25周、目标交付率是20个故事/周。则，WIP=20*0.25=5个故事。,内部质量管理,测试团队在敏捷开发模式下价值有限？开发人员只顾自己写代码，缺乏文档进度导致测试时间有限，上线后出现很多问题测试人员得不到认可，离职率很高QA部门无法收集数据，无法度量,内部质量管理,QA从警察角色转换为教练团队整体参与测试自动化测试，自动化测试，自动化测试提供并获取反馈敏捷实践持续集成灰度发布沟通,外部质量管理,内部质量决定外部质量需求收缩小而精期望值,能力培养和学习型组织,建立共同愿景团队学习改变心智模式超越自我系统思考,DevOps关键能力坐标,自服务能力,持续交付能力,弱,强,强,一区（典型代表：传统企业）,三区（典型代表：传统互联网企业）,四区（典型代表：DevOps团队）,二区（典型代表：云上传统企业）,DevOps成熟度模型,DevOps成熟度模型评估,原始阶段,第一阶段,流程不可控一切手工为主不能及时响应变化质量低劣的应用高成本、高返工,基础阶段,第二阶段,流程文档化部分工作自动化完成不能及时响应变化应用质量提升高成本,可持续阶段,第三阶段,流程标准化、流转自动化大部分工作自动化持续测试和集成，加速变化响应应用质量明显提升成本明显降低,成熟阶段,第四阶段,过程度量和控制持续交付自动化实现端到端的交付质量可度量、可跟踪各方面成本都有所下降,优化阶段,第五阶段,聚焦于流程改进高度自动化，并不断优化不断提升变化的响应效率质量完全可以掌控，并不断改进成本不断下降,DevOps文化,分享,想法,问题,流程,工具,目标,信任,开放,DevOps重要因素,人,激励,目标,其次,流程,技术,DevOps的本质,价值观和目标,工具,流程,自动化,分阶段实施DevOps,第一阶段：核心实践和试点第二阶段：持续集成和测试第三阶段：持续部署和交付第四阶段：持续运维第五阶段：持续评估改进,实施DevOps过程中的阻碍因素,缺乏自上而下的推动力,