《2持续交付2》由会员分享，可在线阅读，更多相关《2持续交付2（79页珍藏版）》请在金锄头文库上搜索。
1、,讲师：陈 浩 2016-9-28,中国广州,软件研发的优化实践,中国移动,目录 CONTENTS,01.,02.,03.,04.,敏捷开发,持续交付,测试驱动开发,全息化生产,01.,02.,03.,集成产品开发体系,产品型研发活动,游戏化研发实践,高效研发实践,高价值化研发,高效研发实践,1,1, 持续交付 ,PART ONE,PART ONE,背景介绍,在互联网的产品开发时代，产品迭代越来越频繁，“从功能开发完成直到成功部署”这一阶段被称为软件开发“最后一公里”。很多开发团队也越来越认识到，敏捷开发和持续交付可帮助开发团队提高迭代效率和质量。,移动互联网又使得DevOps成为一个十分火热
2、的概念。当企业希望将原本笨重的开发与运营之间的工作移交过程变得流畅无碍，便可借助DevOps来完成,PART ONE,背景介绍,持续集成是一种软件开发实践：许多团队频繁地集成他们的工作，每位成员通常进行日常集成，进而每天会有多种集成。每个集成会由自动的构建（包括测试）来尽可能快地检测错误。许多团队发现这种方法可以显著的减少集成问题并且可以使团队开发更加快捷。持续集成，让很多开发团队又 爱 又 恨 。爱，在于整个流程对项目的交付价值大有裨益，尽最大可能地减少不必要的加班；恨，在于成本过大，部署的困难、工程文化的隔阂。,PART ONE,持续集成的益处,在开发中，问题暴露的越早，修复代码的成本越低
3、，成功部署的胜算就越大。持续集成高频率地编译、测试、审查、部署项目代码，这其中代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律的集成，以此来确保当前代码库的质量，把握开发的进程和节奏。 很明显的一点，使用持续集成后，程序员们提交代码也会变得更加小心谨慎。,尽早暴露问题，把握开发节奏,PART ONE,持续集成的益处,在通常的开发环境中，工具及环境的滞后，加上工作的重复枯燥，让开发者对写程序失去新鲜感。在持续集成过程，一步一步的编译、测试、审查、部署，牵扯大量重复的工作。在搭建持续（自动化）集成环境之后，可以让开发人员不再需要手动地 checkout 代码，节省大量的时间和
4、避免不必要的压力，把精力放在更多有价值的事情上，这样也可以形成良性的循环。,避免重复操作，让流程自动化,PART ONE,持续集成的益处,每日高频率的集成保证了项目随时处于可部署运行的状态，如果没有持续集成，项目发布之前将不得不手动地集成，然后花费大量精力修复集成问题，弄的团队成员疲惫不堪。使用持续集成，帮助我们跨越频繁部署的障碍。大家都知道，只有保持频繁部署，让用户看到产品的新特性， 才能不断地磨合优化构建和发布流程，让反馈周期更短更有效。,保持随时部署，简化发布流程,PART ONE,持续集成的益处,无论什么样的工程师，都会对存在大量 bug 的代码产生恐惧心理，这就是心理学上的的 Bro
5、ken Windows 综合症（Broken Windows syndrome）。CI 可以有效防止破窗综合征，让开发团队一点点积累起对产品的信心，对使用技术的保持成就感。 与此同时，持续集成让每个人都能看到良好的界面和视图来了解项目的成熟度，让所有人都知道正在发生什么。也许更容易增强开发信心，培养团队良好的工程文化，齐心协力向目标前进。,增强团队信心，建立工程师文化,PART ONE,持续集成的不足,场景1：环境升级项目A和项目B都依赖于Web容器，公司决定升级Web容器版本，而公司要升级的机器有上百台，依赖人肉升级已不现实，维护团队因此针对各种软件开 发了相应的自动化脚本，但当新的软件出现
6、时，必须要开发新的脚本。而且当同时升级若干环境软件时，则难度随之增大，手工调度的方式极易出错，当升级失败时 仍需要大量人工处理。由于存在大量升级脚本，有一定的维护成本。,PART ONE,持续集成的不足,场景2：依赖于环境的软件升级与回滚针对环境升级，公司为项目A和项目B开发了新的版本。但环境的升级和软件的升级不是同步进行，出错的可能性非常大（想一想间接依赖和多重依赖的情 况）。当新版本部署到生产系统时，发现问题，需要回滚到之前的版本所有运行时版本都需要回滚，而且环境也需要同步回滚。几百台机器,PART ONE,持续集成的不足,场景3：运行时依赖在第一节的方案中，我们将所有的运行时依赖都打包到
7、一起。当项目依赖关系复杂时，这样产生的包将非常臃肿，潜在地延长了部署的时间（想一想全世有几 百台服务器，一个部署计划需要部署几百兆文件的情况），而且产生冲突的可能性非常大，而且对于不同类型的项目（Java和Ruby项目）缺乏通用性。06 年左右，Nortel可是拿Excel统计过运行时依赖的，牵涉若干项目组，反复多次，没有个把月真搞不定。,PART ONE,持续集成的不足,场景4：泛滥的部署每个项目相关的持续集成环境都需要开发自己的部署脚本，重复投入大，而且各个项目的部署过程不一致，并且对于同一个项目无法同时满足不同目的部署要求，例如，环境或系统配置参数改变后，无需安装包，只需做清理和激活的工
8、作。最后，持续集成只是支持了和代码修改有关的部署。,PART ONE,持续集成的不足,场景5：不一致的环境简单项目中，开发环境和运行环境都由开发人员搭建，当公司变大时，系统的运行环境将由运维人员搭建，而开发环境如果由运维人员搭建则工作量太大，由开发人员自己搭建则操作复杂又容易产生不一致的情况。,PART ONE,持续集成的不足,场景6：热切换对于某些部署，需要尽量减少服务的停止时间，需要在服务的同时进行部署。,PART ONE,持续集成的不足,大型企业，人多，项目多，机器多，项目环境复杂，部署维护工作繁多。以持续集成为基础的部署可以解决各个项目的集成问题，却无法帮助企业应对复杂的项目环境和各种
9、不同的部署要求。要实现真正意义上的持续交付与部署，我们就必须把环境和项目同等对待，通通纳入管理之中。同时，部署本身要得到统一。 一个好的部署机制，应该是易于建立，易于使用，易于维护。,PART ONE,解决持续集成后续的问题,持续交付(Continuous Delivery) 用来确保让代码能够快速、安全的部署到产品环境中，它通过将每一次改动都提交到一个模拟产品环境中，使用严格 的自动化测试，确保业务应用和服务能符合预期。因为使用完全的自动化过程来把每个变更自动的提交到测试环境中，所以当业务开发完成时，你有信心只需要按一次按钮就能将应用安全的部署到产品环境中。 持续部署(Continuous
10、deployment) 持续交付的更高阶段：所有通过了自动化测试的改动都自动的部署到产品环境里。大多数的公司如果没有制度的约束或其它条件的影响，都应该以持续部署为目标。,PART ONE,解决持续集成后续的问题,持续交付/持续部署已经超越了传统软件研发的工作界面，构建了一种新型的研发、运维场景。要像真正达到持续交付的目标，就必须实施 DevOps （Development Operations）， 将研发与运维两个部门、两个思维观念的差异点整合起来,PART ONE,DEVOPS的使命,敏捷的出现打破了用户、开发和测试之间的隔阂，实现了团队的协作。 新近出现的DevOps则借鉴了敏捷思想，将敏
11、捷原则应用于运维领域，使交付团队与运维团队建立起更紧密的合作关系。DevOps让企业能够获得更快交付高质量、高价值软件的能力，从而增强企业竞争力。,PART ONE,DEVOPS的益处,DevOps 就是想方设法的避免各种“终极失败”，同时让大家用更聪明更有效的方式去工作。它是一种框架，包含了很多优秀想法和原则，它鼓励开发部门和运维部门通力合 作。在DevOps环境中，开发人员和系统管理员会构建一些关系、流程和工具，从而更好的与客户互动，最终提供更好的服务。,PART ONE,DEVOPS的益处,DevOps 也不仅仅是一种软件的部署方法。它通过一种全新的方式，来思考如何让软件的作者（开发部门
12、）和运营者（运营部门）进行合作与协同。使用了DevOps模型 之后，会使两个部门更好的交互，使两者的关系得到改善，从而让很多领域从中受益，例如：自动化、监视、能力规划和性能、备份与恢复、安全、网络以及服务提供（provisioning）等等。,PART ONE,特征解析,持续集成持续交付持续部署三者究竟是什么，有何联系和区别呢？,PART ONE,从持续集成到持续部署,PART ONE,从持续集成到持续部署,持续集成是指软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程（XP），是 XP 最初的 12 种实践之一。,PART ONE,CI 需
13、要具备的特性,全面的自动化测试。这是实践持续集成&持续部署的基础，同时，选择合适的自动化测试工具也极其重要；灵活的基础设施。容器，虚拟机的存在让开发人员和 QA 人员不必再大费周折；版本控制工具。如 CVS，SVN ，Git等；自动化的构建和软件发布流程的工具，如 Marven，Jenkins；反馈机制。如构建/测试的失败，可以快速地反馈到相关负责人，以尽快解决达到一个更稳定的版本。,PART ONE,CI 的优势,“快速失败”，在对产品没有风险的情况下进行测试，并快速响应；最大限度地减少风险，降低修复错误代码的成本；将重复性的手工流程自动化，让工程师更加专注于代码；保持频繁部署，快速生成可部
14、署的软件；提高项目的能见度，方便团队成员了解项目的进度和成熟度；增强开发人员对软件产品的信心，帮助建立更好的工程师文化。,PART ONE,从持续集成到持续部署,持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的类生产环境（production-like environments）中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。,PART ONE,持续交付的焦点,开发不能等到所有东西都完成了才向下个环节交付，这样所有的问题只会在最后才爆发出来，解决成本将巨大到无法解决。代码没有问题之后，是继续手动部署到生产环境中的。持续交付并不是指软件每一个改动
15、都要尽快部署到产品环境中，它指的 是任何的代码修改都可以在任何时候实施部署。,PART ONE,持续交付的优势,快速发布。能够应对业务需求，并更快地实现软件价值。编码-测试-上线-交付的频繁迭代周期缩短，同时获得迅速反馈；高质量的软件发布标准。整个交付过程标准化、可重复、可靠，整个交付过程进度可视化，方便团队人员了解项目成熟度；更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。,PART ONE,从持续集成到持续部署,持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味
16、着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。,PART ONE,持续部署的优势,持续部署主要好处是，可以相对独立地部署新的功能，并能快速地收集真实用户的反馈。“You build it, you run it”，这是 Amazon 一年可以完成 5000 万次部署，平均每个工程师每天部署超过 50 次的核心秘籍。,PART ONE,持续部署的要素,PART ONE,从持续集成到持续部署,持续集成（Continuous Integration）、持续交付（Continuous Delivery）和持续部署（Continuous Deployment）提供了一个优秀的 DevOps 环境，对于整个团队来说，好处与挑战并行。频繁部署、快速交付以及开发测试流程自动化将成为软件工程的重要组成部分,PART ONE,从持续部署到DevOps,把开发交付划分为，计划、编码、构建、测试、部署、运维几部分，我们可以从图看出DevOps和持续交付，持续集成，持续测试，持续部署以及敏捷开发的关系。能具备持续集成，持续测试，持续部署的能力，并逐步完善从而实现具备持续交付的能力。,
