2持续交付2.pptx

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 的代码产生恐惧心理，这就是心理学上的的

5、Broken 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) 用来确保让代码能够快速、安全的部署到产品环境中，它通过将每一次改动都提交到一个模拟产品环境中，使用严格 的自动化测试，确保业务应用和服务能符合预期。因为使用完全的自动化过程来把每个变更自动的提交到测试环境中，所以当业务开发完成时，你有信心只需要按一次按钮就能将应用安全的部署到产品环境中。 持续部署(C

10、ontinuous 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 种实践之

13、一。,PART ONE,CI 需要具备的特性,全面的自动化测试。这是实践持续集成&持续部署的基础，同时，选择合适的自动化测试工具也极其重要； 灵活的基础设施。容器，虚拟机的存在让开发人员和 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）、持续交付（Co

17、ntinuous Delivery）和持续部署（Continuous Deployment）提供了一个优秀的 DevOps 环境，对于整个团队来说，好处与挑战并行。 频繁部署、快速交付以及开发测试流程自动化将成为软件工程的重要组成部分,PART ONE,从持续部署到DevOps,把开发交付划分为，计划、编码、构建、测试、部署、运维几部分，我们可以从图看出DevOps和持续交付，持续集成，持续测试，持续部署以及敏捷开发的关系。能具备持续集成，持续测试，持续部署的能力，并逐步完善从而实现具备持续交付的能力。,PART ONE,DevOps的重点,警惕总体安全风险 虚拟化、云、BYOD以及软件定义网

18、络（SDN）等新兴技术不断得到采用意味着网络变得越来越复杂，愈发的异构化，安全风险也是如此。这是一个文化问题，需要安全、开发者以及运营团队培育出此前未有过的一定水平的信任和协作。 安全风险变化 把DevOps看作一种可将开发者和IT运营引向更快更高效的部署、运营及升级应用的协作理念和流程很重要。 可伸缩性 企业和技术的人必须在功能、推向市场的时间、成本以及风险承受能力等方面做出权衡。你需要有合适的衡量目标，包括特定模式下的那些端点上有多少用户，有多少并发请求。 实现易用 DevOps就是自动化和可重复性。 管理网关 尽管新的目标是在开发和运营团队之间建设最好的文化，但为了确保产品环境保持稳定，

19、在这两个职能之间保留一些网关仍然是好的。,PART ONE,DevOps的一个使用场景,使用RTC ( Rational Team Concert ) 进行协同开发，项目管理，以及管理代码。通过提交代码自动触发持续集成任务，Jenkins作为持续集成工具解决各种模块之间的依赖，并且能触发接下来的构建过程，在成功完成的构建之后，还可触发预置的简单的脚本调用测试环境的准备,PART ONE,持续集成的步骤,最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统，关键在于团队运行的基础设施，团队对持续集成系统的资源投入力度。 对比一下私有部署和托管型持续集成系统，或许能帮助你

20、更好地做出选择。,PART ONE,CI工具的选择,Self Hosted CI 指的是将软件部署在公司的机房或内网中，需要提供多台服务器来完成 CI 系统的运转，同时需要对不同机器之间进行环境配置。比如Maven 或 Gradle 或 Jenkins ，他们的特点是自由开源，且文档支持广泛。 Hosted CI 指的是由 SaaS 型的 CI 服务，全程在线进行构建配置，不需要考虑装机器，装软件，环境搭建等成本。常见的有 CircleCI，Codeship 和 TravisCI 等，还有国内的持续集成服务flow.ci 。,PART ONE,CI工具的特点,Self Hosted CI 对构

21、建环境有完全的控制权，能够实现完全定制。但需要搭建环境和配置、维护成本高，需要买专门的机器，花费人力物力且更新迁移风险高； Hosted CI 无需额外机器，几分钟就可以用起来。可以根据你的需要动态调度资源。省时，省心，省力。,Jenkins 过去一直是大部分公司的选择，但这个现象正在发生改变，随着公有云服务、Docker，SaaS 的普及，越来越多的企业开始选择 Hosted CI，也就是托管型持续集成系统。,PART ONE,持续集成的前提,将所有的源代码保存在单一的地点，让所有人都能从这里获取最新的源代码（以及以前的版本）。 使创建过程完全自动化，让任何人都可以只输入一条命令就完成系统的

22、创建。 使测试完全自动化，让任何人都可以只输入一条命令就运行一套完整的系统测试。 确保所有人都可以得到最新、最好的可执行文件。,PART ONE,持续集成的步骤,STEP1 . 提交 流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交（commit）。,PART ONE,持续集成的步骤,STEP2. 测试（第一轮） 代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。 测试有好几种。 单元测试：针对函数或模块的测试 集成测试：针对整体产品的某个功能的测试，又称功能测试 端对端测试：从用户界面直达数据库的全链路测试 第一轮

23、至少要跑单元测试。,PART ONE,持续集成的步骤,STEP3. 构建 通过第一轮测试，代码就可以合并进主干，就算可以交付了。 交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。 常用的构建工具有： Jenkins Travis Codeship Strider Jenkins和Strider是开源软件，Travis和Codeship对于开源项目可以免费使用。它们都会将构建和测试，在一次运行中执行完成。,PART ONE,持续集成的步骤,STEP4. 测试（第二轮） 构建完成，就要进

24、行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。 第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。 注意：新版本的每一个更新点都必须测试到。如果测试的覆盖率不高，进入后面的部署阶段后，很可能会出现严重的问题。,PART ONE,持续集成的步骤,STEP5. 部署 通过了第二轮测试，当前代码就是一个可以直接部署的版本（artifact）。将这个版本的所有文件打包（ tar filename.tar * ）存档，发到生产服务器。 生产服务器将打包文件，解包

25、成本地的一个目录，再将运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。 这方面的部署工具有Ansible Chef Puppet等。,PART ONE,持续集成的步骤,STEP6. 回滚 一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。,PART ONE,持续部署一览图,PART ONE,持续部署的步骤,PART ONE,持续部署的管道,交付管道的建立和自动化是持续交付的基础。,PART ONE,持续部署的要求,如果持续集成实现了自动化而部署过程需要大量手工操作，那部署就无法跟上持 续集成的节奏。部署也需要自动化

26、，部署自动化工具可以帮助一个构建自动地在部署管道中推进，使部署本身不成为瓶颈。 自动化可以确保整个部署过程可以固化下来，在每次部署中可重复进行。这样就可以既测试待部署工件的质量，也同时验证部署流程的质量，把这种流程也作为资产管理起来。,PART ONE,DevOps目标,PART ONE,DevOps工具,PART ONE,DevOps的推进,1.弄清楚“为什么？” 首先非常清楚跨团队的成员为什么会聚到一起，知道团队试图实现什么，清楚大家的目的是什么是非常重要的。 组织的主要目标是我们实现DevOps文化的唯一原因，除此之外没有其他原因。 DevOps仅仅是达到目标的一种手段，但是它自己本身并

27、没有结束：“DevOps并不是你的为什么，不是你合作伙伴的为什么，当然也不是你业务的为什么”。,PART ONE,DevOps的推进,2. 实现组织合作 接下来是使整个跨团队组织合作，让所有人基于一组共享的条件和规则向一个共同的目标努力。 当能够把同一个目标指定给多个人的时候，一个组织就实现了正确的合作，大家会选择同样的方式去实现各自的目标，对于同一个问题有同样的答案。这可能是“组织合作的终极梦想”。 为了完成这种合作，组织内部必须要有人描绘一个DevOps愿景。这并不能通过教学过程实现，因为人们只会尝试着机械性地遵循这些步骤。,PART ONE,DevOps的推进,3.持续改进循环 这些循环

28、的目的是通过制定计划、实现计划、测量输出和决定如何持续地改进流程。,PART ONE,CI 需要具备的特性,单一代码源 自动化创建脚本 自动化测试 主创建 代码归还,PART ONE,CI的数理基础,集成的工作量是与两次集成间隔时间的平方成正比 每周集成一次所需的工作量绝对不是每天集成的5倍，而是大约25倍。,PART ONE,成功创建的标准,所有最新的源代码都被配置管理系统验证合格 所有文件都通过重新编译 得到的目标文件（例如Java的class文件）都通过连接（Link），或者得到可执行文件 系统开始运行，针对系统的测试套件开始运行 所有的步骤都没有错误、没有人为干涉，所有的测试也都通过了

29、,PART ONE,成功创建的标准,绝大多数的集成都可以而且应该自动完成。 读取源代码、编译、连接、测试，这些都可以自动完成。 在整个创建过程中，完全不需要你动脑子。,PART ONE,对CI的领悟,如果集成让你感到痛苦，也许就说明你应该更频繁地进行集成。 如果方法正确，更频繁的集成应该能减少你的痛苦，让你节约大量时间。 持续集成应该天天做，实时做,PART ONE,持续部署成功的关键,充分而广泛的自动化测试覆盖； 尽可能短的测试反馈时间； 部署过程自动化； 部署过程要保证数据安全； 在稳定的前提下，尽早部署； 完善的风险缓解措施； 将同样的产物部署到不同的环境中,PART ONE,持续部署的

30、最佳实践,实践1：建立单一的部署来源 开发团队可能分布在各处，或者即便是一起开发也会根据业务逻辑进行团队划分。每个团队都可能有自己的一套应用部署工具和流程。小规模团队这种情况还好，而不同的流程和不同的工具对于大型团队来讲，在编排发布计划时会带来巨大的挑战和风险。 因 此，在制定发布计划时，需要建立一个单一的、可信任的、实时更新的部署来源。比如说，待组装的应用组件应该放在相同的容器里进行管理，发布的流程设计应该 统一风格和模式，不同环境要求的配置项或者属性信息应该统一设置和管理，等等。这样可以让接入持续交付管道的各个角色协同起来，同时提供了整个交付管道的 可视性和可跟踪性，清楚的知道谁、何时、做

31、了哪些动作。,PART ONE,持续部署的最佳实践,实践2：让令人痛苦的手工步骤自动化起来 在 部署过程中的手工步骤带来了许多风险。比如说，如果这个步骤没有写的特别详细，对于新手来说就存在执行的不确定性；或者这个步骤在部署到其他环境中时遗漏 了，就会导致部署失败。 另外，手工步骤是难于跟踪和管理的。为了解决这个问题，尽最大可能自动化现有的部署步骤。 自动化能力为完成部署步骤提供了一种安全 的、被验证过的、成功率更高的手段，理想情况下，所有步骤都应该被自动化。,PART ONE,持续部署的最佳实践,实践3：管理应用内部的相互依赖关系 避 免仅仅依赖开发人员口头去描述和理解应用的内部依赖关系。复杂

32、的部署通常包含应用组件的互相依赖。 如果组件 A 依赖于组件 B 的某一个具体版本，那么没有部署或者没有正确部署组件 B 将导致整个发布失败。需要将这种依赖关系通过工具管理起来，而且需要保证同时部署的组件必须一起测试过，要测试这些组件的功能和他们的兼容性。 当应用在不 同的测试环境移动时，必须确保这种依赖关系的顺利移动，也就是说，必须清楚的知道具有依赖关系的某个组件的某个具体版本是否被正确部署。,PART ONE,持续部署的最佳实践,实践4：让部署过程的“什么。在哪里。”可视化 不 知道在某一个机器上或者某一个环境中部署了什么存在很大的风险。尤其当应用向更严格的环境中移动时风险就更大，如当应用

33、从 UAT 环境向生产环境迁移，一个存在于 UAT 环境中的组件版本和生产环境的另一个组件不兼容，文档中并没有记录这一点，那么，这种部署就带来了极大地风险，甚至成为生产事故。另外，停止应用去跟踪和 分析其部署也是非常耗时和浪费的事情。如果能对部署环节的“什么。在哪里。”管理起来并清晰可见，就可以确保各个环境确实成功部署了组件和组件版本。 另外，跟踪应用的部署也变得非常轻松。生成工件部署清单并实时追踪分析就可以为整个应用部署带来更好的洞察力。,PART ONE,持续部署的最佳实践,实践5：让部署环节的准入条件和批准情况清晰可见 认证和审批可以确保质量。在持续交付管道中定义清晰明确的质量属性是非常

34、重要的。只有当在某一个环境中部署的应用，符合了下一个环境的质量属性并得到审核批准后，才能将应用部署到该环境中。 比如一个构建经过了SIT 阶段，需要向 UAT 阶段移动时，理论上应该已经通过了单元测试、功能测试、性能测试、接口测试等一系列验证，并且集成测试部门经理也批准该构建可以部署在 UAT 环境中，那么，该构建的上述验证值应该为真（表示已通过验证），其部门经理批准值也为真（表示已经批准），在 UAT 测试环境的准入条件中，只有这些属性值都为真的时候，才允许部署这个构建。让这些准入条件和审核批准状态清晰可见，所有人才能知道一个应用需要什么条件才 能在持续交付管道中前进。通常我们把这种质量属性

35、称之为质量门（quality gate），它正是作为应用向下一个环境迁移的准入条件。,PART ONE,持续部署的最佳实践,实践6：在不同的环境中保持部署的一致性 不同的阶段和环境使用不同的部署流程增加了出错的概率。 比如，由于生产环境使用的部署流程并没有在更早期的环境中验证过，仅在该环境下的特殊步骤就有可能出现错误。应该使用测试环境去验证会在生产环境上运行的每一个步骤。当编排和设计应用的发布流程时，应该设计成一个单一流程，它被用到整个持续交付管道中的 每一个阶段中。,PART ONE,持续部署的最佳实践,实践7：发布计划简单明了 发布计划应该做到编写容易，在计划会议上讨论时就能随手制定，而且

36、应该易于理解，让每一个持续交付管道中的角色都能知道计划是怎样的，如果发布变化产生的影响是什么。 发布变更应该有便利的协作手段去审核和批准。如果发布计划难于理解，通常都会被束之高阁，这会带来一系列问题，如变更混乱，风险增加。,PART ONE,高效DevOps的最佳实践,实践1：利益相关者的积极参与 DevOps的根本原则是开发人员,运营人员以及技术支持人员必须定期紧密的工作在一起。言外之意是他们必须互相视对方为重要的利益相关人，并积极争取一起工作。 敏捷社区中一个普遍的实践是“现场客户”。这个实践出自于极限编程，它鼓励开发人员应该与业务人员紧密合作。规范的敏捷团队将该实践更进一步， 即利益相关

37、的积极参与，这意味着开发人员应该与所有利益相关者一起紧密工作，包括运营人员及支持人员，而不仅仅是业务人员。这是双向的：运营人员和技术支持人 员也必须愿意和开发人员紧密工作。,PART ONE,高效DevOps的最佳实践,实践2：自动化测试 敏捷软件开发人员被称为质量感染者，这是因为他们关注于编写高质量的代码，渴望测试越早开始越好。结果，自动化的回归测试是敏捷团队普遍采用的实践。该实践有时又被扩展为测试先行的方式，比如测试驱动开发（TDD），以及行为驱动开发（BDD）。 由于敏捷团队经常一天多次运行他们的自动化测试集， 并且能够马上修复发现的问题，所以他们比普通团队能达到更高的质量。对于运营人员

38、而言，在同意一个解决方案发布到产品环境前，坚持足够的质量审查，这是件 好事情。,PART ONE,高效DevOps的最佳实践,实践3：集成配置管理 要实现以集成的方式来进行配置管理（CM），开发团队不仅要习惯于在解决方案层级应用CM，还需要考虑自身的解决方案与组织的其余基础设施之间的 产品环境配置问题。对于一些开发人员而言这是个不小的转变，因为他们往往习惯于只考虑当前他们工作的解决方案的CM。 在DevOps环境中，开发人员需要 拥有企业级视角，在更高的层次看待问题。他们的解决方案如何能在产品环境结合其它资源带来优势？其它资源是否能支持被开发的解决方案？言外之意是开发团队 需要了解及管理他们产

39、品的所有范围的依赖。集成配置管理也使得运营人员了解新的发布潜在的影响，从而更容易决定进行发布的时间。,PART ONE,高效DevOps的最佳实践,实践4：综合变更管理 从IT的角度来看，变更管理（高级配置管理）是一门确保IT基础设施的演化能对整体组织的支持成功及有意义的艺术。但是对于项目-团队层级则颇具挑战。这是因为非常多的技术，甚至相似技术的多个版本会被使用在单个解决方案的开发过程中。 由于DevOps引入了与运营有关的企业级问题，综合变更管理策略会变得越来越复杂，因为需要考虑大量的解决方案能够在产品环境中同时运行和交互。为了实现综合变更管理，开发团队必须与运营团队紧密合作，来从组织层面了

40、解任何技术的改变带来的影响。该方式依赖于前面的实践-利益相关者的积极参与，集成配置管理及自动化测试。,PART ONE,高效DevOps的最佳实践,实践5：持续集成 持续集成（CI）是构建及验证项目的规范，当有代码更新被迁入到版本控制系统时，会进行自动化的回归测试及代码分析。 CI是与DevOps相关的敏捷开发实践之一（至少从开发人员角度来说是如此）。 CI确保开发人员以较小的，可以对代码缺陷立即反馈的常规步骤来开发一个高质量的可以工作的解决 方案。,PART ONE,高效DevOps的最佳实践,实践6：集成部署计划 从开发团队角度而言，部署计划总是需要与该组织的运营人员交互。有些情况下，与运营人员接口的专家被特称为发布工程师。经验丰富的团