持续交付与DevOps

DevOpsEssentialsCI/CD/Agile/LEAN梁博,敏捷教练OpenStackExpertise•10+yearsProgrammingExp.•MicrosoftMSF•RedHatOpenShiftExpertise•RedHatVirtualizationExpertise•OpenStackCertifiedAdministrator•OpenStackContributorDevOps流程介绍Part01DevOps企业文化Part02CONTENT目录HPE之DevOps篇Part03软件交付流程一需求部署开发软件交付流程二产品收集需求文档价值评审优先级原型立项开发计划设计评审测试评审测试Fix回归测试UAT辩论运维上线签字准备环境配置部署交付沟通发布反馈开发需求评审观后感-什么是DevOps开发和It运维之间的高度协同高频部署的同时，提供生产环境的可靠性、稳定性、弹性和安全性价值流业务(需求定义)客户(价值交付)起源于2009年前后一天10次部署(JohnAllspaw,PaulHammond)基础设施即代码(MarkBurgess,LukeKanies)敏捷基础设施(AndrewShafer)敏捷系统管理(PatrickDebois)精益创业(EricRies)持续集成和发布(JezHumble)平台即服务(AWS)GotoMarketfeaturecycletimetimeCustomerUsersGotoMarketfeaturecycletimetimeCustomerUsersminimizeGotoMarketfeaturecycletimetimeCustomerUsersminimize这才是你创造的价值GotoMarketfeaturecycletimetimeCustomerUsersminimize这才是你创造的价值YouGotoMarketfeaturecycletimetimeCustomerUsersminimizeYou一切都是围绕着尽快将新的功能交付到用户手上冲突关于DevOps你必须知道的几件事ResolvingissueswithoutDevOps我们的Dev&OpsDEVOPSBUSINESS别人家的DevOps协作为何如此重要ProductionDevelopmentOperate+learnPlanDevelop+testReleaseRequirementsCollaboration别人家的DevOpsSourceBuildTest/issuesDeploymentApplicationOperationsProcesstoolsCloudOn-premises别人家的工具SourceBuildTest/issuesDeployAppOpsProcesstoolsGitHubCodeplexGradleGruntHudsonJenkinsConfigurationGradleChefGruntHudsonJenkinsPuppetLabsVagrantAlertingMonitorZabbixRedmineJIRAPublicCloudOn-premisesMicrosoftAzureLinuxPuppetLabsEclipseVisualStudioGradleGrunt别人家的发布流程DEVDevServersTESTPRE-PRODiPRODUCTIONCreateSQLdatabaseConfigureservicesRun.msifileStagesEnvironmentsActionsApproversTestServersCreateSQLdatabaseConfigureservicesUpdate.inifilePre-ProdServersRestoreSQLdatabaseRunSQLscriptConfigureservicesProdServersRunSQLscriptRun.msifileRun.msifileRun.msifileReleasePathsIT的革新进程IT的革新进程IT的革新进程DevOps典型模型•ScrumDevOps典型模型DevOps持续集成为什么要持续集成•快速反馈•减少项目风险•每个人都是项目的Owner•持续开发•将一些重复的事情交给机器去做持续集成最佳实践•单一代码仓库•经常提交(CommitOften)•让你的Build可以自动化测试•自动构建•快速构建CI/CD角色分工SourceCodeRevisioncontrolsystemContinuousIntegrationProgrammableInfrastructureAutomatedDeploymentMonitoring,NotificationsandReportingAutomatedBuildAutomatedTestingAutomatedQAAutomatedDocumentationCollaborationCI/CD角色定义DevOpsProgrammableInfrastructureLicenseManagementSelfServiceImage/configurationmanagementRevisionControlSystemContinousIntegration&Dev.AutomationBuildAutomationTestAutomationQAAutomationCodeCoverageToolsStandardsCheckToolDocumentationAutomationAutomatedDeploymentMonitoring,NotificationandReportingCollaborationtoolsAgileDevelopment工作描述•减少风险•减少重复过程•任何事件、任何地点生成可部署的软件•增强项目的可见性•建立团队对开发产品的信心CI搭建–骨架CI搭建–填充持续测试(测试策略)•Selenium：用于自动化测试DashboardUI•Tempest：用于自动化测试OpenStackAPI•Rally：用于自动化测试OpenStack性能•UnitTests：用于每个项目的单元测试持续审查持续审查持续审查持续审查持续审查持续部署Why?»Createapplicationruntimeenvironmentsondemand»Fast,reliable,repeatableandpredictableoutcomes»Consistentenvironmentsinstagingandproduction»Makesreleasedaysriskless,almostboringWhat?»OperatingSystems,Drivers»Middleware,Databases,etc.»Applications,Dependencies,DataHow?»InfrastructureasCode!»KeepeverythinginVersionControl»Code»Configuration»Data»AlignDevelopmentandOperations}+ConfigurationEverythingthataffectsapplicationstate持续部署✔持续部署✔✔持续部署✔✔✔持续部署✔✔✔✔持续部署✔✔✔✔✔持续反馈•一对一反馈•集体反馈•书面反馈•反馈训练•反馈工具•自动反馈构建流水线构建流水线构建流水线源代码管理•本地版本控制•集中版本控制•分布式版本控制环境定义自动化配置管理自动化监控自动化监控-HADevOps流程介绍Part01DevOps企业文化Part02CONTENT目录HPE之DevOps篇Part03敏捷看板管理看板方法看板方法可以动态显示瓶颈敏捷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还要参加？自动化测试简介•大量机械的、重复性的回归测试•结果正确性不依赖主管判断的测试•需要模拟大量数据、大量并发的测试•需要不间断执行的测试•需要短