搜索
持续交付教育研发中心2015-05-12目录持续交付简介工作计划讨论什么是持续交付？•什么是持续交付？•持续交付是在用户与项目团队（包括客户或者ProductOwner）之间建立紧密的反馈环，即：通过持续交付新的软件版本，验证新的想法和软件的改动，并能衡量这些改动对收入的影响。•持续交付(ContinuousDelivery)是一系列的开发实践方法，用来确保让代码能够快速、安全的部署到产品环境中。它通过将每一次改动都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和服务能符合预期。因为使用完全的自动化过程来把每个变更自动的提交到测试环境中，所以当业务开发完成时，你有信心只需要按一次按钮就能将应用安全的部署到产品环境中。•持续交付的好处：•业务收益：1、它让你能更快地验证新业务方案的结果，并根据真实的用户反馈进行调整。2、大幅降低交付风险、交付成本。•IT管理的好处：1、项目经理们能看到项目的真实进度，通过规律性增量发布，大大减少了每次发布的风险。Monthstoweekstodays什么是持续交付？•你是不是真的在持续交付？(以终为始)•你的软件是不是一直处于产品可发布状态。你只要按个回车键就可以把它发布给用户。•如果你的发布过程很痛苦，而且不太频繁，并且在发布之前还有一个充满风险的集成阶段，那么你就没有在做持续交付。•持续交付中最重要的度量是周期时间（cycletime）•从决定实现某个想法开始，到将其发布给用户为止这段时间长度。Monthstoweekstodays持续交付的发展产品交付生命周期模型传统交付过程的反馈环持续交付模型的反馈环持续交付模型持续交付成熟度模型图（V1.2）业界持续交付现状和目标持续集成ContinuousIntegration环境与部署EnvironmentsandDeployments测试Testing数据管理DataManagement配置管理ConfigurationManagement业界现状Level2可重复级Repeatable根据直观感觉遵从一定的流程。无事先定义好的标准或公共工具集。高度依赖于个人能力。1.在开发人员的代码上进行定期的自动化构建和单元测试。2.利用自动化过程，能够从源控制中重新生成任意一个构建版本。3.开发人员的提交频率是不定的。Level2可重复级Repeatable1.环境已被定义，并可自动化地准备和控制。2.部署操作是手工和自动化相结合才能完成。Level2可重复级Repeatable1.自动化测试和手工测试相结合，并做为Story开发过程中的工作来完成。2.在组件测试和验收测试级别上，仍旧严重依赖于手工测试。3.对“完成的定义”不包含自动化测试的完成。Level2可重复级Repeatable1.对数据库的变更是利用与应用程序版本相匹配的脚本来完成的。Level2可重复级Repeatable1.完整环境的所有元素（Allelements）被清楚定义。2.对源代码、测试、构建和部署脚本、数据迁移和所需的支持性文档等等进行版本控制，但没有标准的工具集。持续集成目标Level4定量级Quantiatively对过程进行端到端的度量与控制。已具备全面自动化部署的能力。1、构建数据度量项被收集，高度可视化，并执行相应的改进活动。2、构建失败不会没人管。所有团队成员至少每天提交一次。3、尽可能在最后时刻（即将发布时）才拉发布分支。Level3已定义级在整个产品生命周期中，已为增量自动化制定了标准和实践。1.开发和测试环境是全面自动化且自服务的。2.已具备“点击按钮即可向任意环境进行部署”的能力。3.为了完成自己的工作，每个人都有相应权限访问并操作相应的环境。Level3已定义级1.一旦需要，就将新的测试添加到测试套件里。2.非功能测试被加到自动化测试套件中。3.手工测试主要关注于探索性测试。Level3已定义级1.数据库变更作为部署流程的一部分自动执行Level4定量级Quantiatively1.每次部署时，数据库升级或回滚都使用生产数据进行自动化的测试。2.使用一个标准的版本控制工具，所有配置项和工作都能被标识和管理。3.对产品环境的任意变更都是成功通过部署流水线完成的。持续交付-7个最佳实践(IBM)•实践1：建立单一的部署来源•实践2：让令人痛苦的手工步骤自动化起来•实践3：管理应用内部的相互依赖关系•实践4：让部署过程的“什么。。在哪里。。”清晰可见•实践5：让部署环节的准入条件和批准情况清晰可见•实践6：在不同的环境中保持部署的一致性•实践7：发布计划简单明了持续交付-演示DEMO目录持续交付简介工作计划讨论每月都有那么几次！！版本上线已经成为项目组的心魔•上哪个版本，版本没错吧？•XX请假了，怎么上线？手抖了……•怕出线上问题啊…•哪些库文件要改…为什么要搞持续交付定制组现状及目标分析持续集成ContinuousIntegration环境与部署EnvironmentsandDeployments测试Testing数据管理DataManagement配置管理ConfigurationManagement组织协调性OrganisationalAlignment定制组现状Level2可重复级Repeatable根据直观感觉遵从一定的流程。无事先定义好的标准或公共工具集。高度依赖于个人能力。1.在开发人员的代码上进行定期的自动化构建和单元测试。2.利用自动化过程，能够从源控制中重新生成任意一个构建版本。3.开发人员的提交频率是不定的。Level1退化级Regressive过程不可重复，发布不频繁且不可靠。改进行为依赖于团队成员临时性的努力1.手工准备环境，对冲突无控制。2.手工部署软件。Level2可重复级Repeatable1.自动化测试和手工测试相结合，并做为Story开发过程中的工作来完成。2.在组件测试和验收测试级别上，仍旧严重依赖于手工测试。Level2可重复级Repeatable1.对数据库的变更是利用与应用程序版本相匹配的脚本来完成的。Level2可重复级Repeatable1.完整环境的所有元素（Allelements）被清楚定义。2.对源代码、测试、构建和部署脚本、数据迁移和所需的支持性文档等等进行版本控制，但没有标准的工具集。Level2可重复级Repeatable1.为了减少瓶颈，在开发周期中更早地得到反馈，职能型团队之间存在一些协作。2.Productowner被识别，且有决定权。持续集成目标Level4定量级Quantiatively对过程进行端到端的度量与控制。已具备全面自动化部署的能力。1、构建数据度量项被收集，高度可视化，并执行相应的改进活动。2、构建失败不会没人管。所有团队成员至少每天提交一次。3、尽可能在最后时刻（即将发布时）才拉发布分支。Level3已定义级在整个产品生命周期中，已为增量自动化制定了标准和实践。1.开发和测试环境是全面自动化且自服务的。2.已具备“点击按钮即可向任意环境进行部署”的能力。3.为了完成自己的工作，每个人都有相应权限访问并操作相应的环境。Level3已定义级1.一旦需要，就将新的测试添加到测试套件里。2.非功能测试被加到自动化测试套件中。3.手工测试主要关注于探索性测试。Level3已定义级1.数据库变更作为部署流程的一部分自动执行Level4定量级Quantiatively1.每次部署时，数据库升级或回滚都使用生产数据进行自动化的测试。2.使用一个标准的版本控制工具，所有配置项和工作都能被标识和管理。3.对产品环境的任意变更都是成功通过部署流水线完成的。Level4定量级Quantiatively1.运维团队尽可能多地使用部署流水线完成他们要做的修改。2.在整个生命周期早期，团队成员就能够识别和解决问题。3.使用与业务成功相关的度量项来衡量团队的成功持续交付三条主线（步骤）•从Code到Artifact仓库：没有统一的Artifacts仓库•从Artifacts到Runningservice：不同环境的部署方法不一样•从开发测试环境到准生产、生产环境：开发、QA和运维采用传统协作方式持续交付-基础架构•从Code到Artifact仓库：•1.1版本控制服务SVN/GIT•1.2持续集成服务JenKins/Go•1.3AritFacts仓库Artifactory/Nexus(Java)+Yum(c++)/Docker•从Artifacts到Runningservice•2.1环境创建Kickstart/Cobbler/VirtualMachine/IAAS???•2.2服务自动化+2.3代码部署Ansible/Puppet/Saltstack/Chef•2.4服务监控/ELK/Flume/Zabbix/Nagios/Cacti•2.5自动化测试工具Selenium/CuCumber??持续交付-组织架构•从开发测试环境到准生产、生产环境环境目标用户构建类型部署者Dev（开发环境）开发人员不稳定版本（实施自动构建）CI自动触发（自动部署）Test（测试环境）测试人员不稳定版本（每日自动构建）CI自动触发（自动部署）Acceptance（准上线环境）内部用户发布版本（人工触发）部署控制台（人工触发）Production（生产环境）最终用户发布版本（人工触发）部署控制台（人工触发）三观念转变一构建自动化的文化，并建立清晰、一致的DTAP流程二不同角色人员之间相互融合（DevOps）传统观念新观念开发人员：增加新功能运维人员：保持服务稳定、快速开发人、运营、测试、项目管理人员的共同工作是：enablethebusiness近期工作目标-待讨论•持续集成（三级已定义级）•1.每次提交都会触发构建和各类测试。•2.公共工具集中的脚本或工件得到重用。•环境与部署（三级已定义级）•1.开发和测试环境是全面自动化且自服务的。•2.已具备“点击按钮即可向任意环境进行部署”的能力。•3.为了完成自己的工作，每个人都有相应权限访问并操作相应的环境。•测试（三级已定义级）•1.一旦需要，就将新的测试添加到测试套件里。•2.非功能测试被加到自动化测试套件中。•3.手工测试主要关注于探索性测试。•数据管理（三级已定义级）•1.数据库变更作为部署流程的一部分自动执行。•一个月试点定制项目•三个月云平台定制项目•六个月云平台产品项目目标内容目标范围持续交付团队的位置及成员角色-待讨论•持续交付团队的定位•持续交付方法的提供者和传播者。•持续交付服务提供者。•持续交付团队的成员•持续交付工程师-自动化部署方向1名2年以上相关工作经验负责自动化部署、监控和自动化配置管理的设计与建设，完成自动化脚本的设计与编写。•持续交付工程师-自动化测试方向1名2年以上相关工作经验负责自动化测试系统的设计与建设，完成自动化测试用例与脚本的设计与编写，有丰富的自动测试经验•持续交付工程师-自动化构建方向1名2年以上相关工作经验负责自动化构建、自动化发布的设计与建设，完成自动化脚本的设计与编写。工作计划讨论