作者：董文娟,尚小冬,张军
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
OpenStack CI／CD：原理与实践试读：
前言
本书由来过去十年，中国电信业快速发展，语音和数据业务需求极大提升，尤其当以安卓、iPhone为代表的智能手机推出后，数据业务的增长速度远超预期。近三年，移动数据业务每年以大约90%的复合增长率增长，这对设备商交付新版本的速度提出了更高的要求。中兴通讯在2013年就启动了无线接入网项目移植虚拟化技术预研，希望实现软硬件解耦以缩短版本交付周期，满足运营商业务飞速发展的需求。目前，这些虚拟化研究成果已经成为5G的基础技术标准。
虚拟化预研项目不仅涉及电信网元本身的适配，还涉及开发云操作系统和制定操作管理规范、接口标准。而云操作系统是虚拟化的关键技术之一，综合考虑云操作系统开源社区影响力、项目热度、扩展性、可维护性、业界认可度等因素，项目团队选择OpenStack作为云操作系统的开源解决方案。但电信领域常见的需求，如网口绑定、高速转发、巨页（Huge Page）、CPU绑核等功能在OpenStack社区尚不支持，如何把虚拟化的电信网元（Virtual Network Function）运行在OpenStack上，并提供高性能服务，是项目面临的巨大挑战。在此背景下，笔者所在的团队开始深入参与到OpenStack开源社区的开发工作中，推动社区一起解决这些关键技术问题。
计算、存储和网络是OpenStack虚拟层三大基础设施服务，其中存储（Cinder）项目涉及厂商的硬件集成。Cinder项目制定了一套API接口规范，厂商的存储设备若需要集成，需向社区提交遵守该接口规范的驱动程序，并搭建一套CI系统来验证，该CI系统需要遵守社区第三方CI规范。
图0-1是一个简化的第三方CI系统架构图，厂商需要准备的有：
·第三方CI系统，即本书所要讲述的OpenStack CI系统；该系统连接厂商的存储硬件，并与社区的Gerrit系统连接，监控stream-events事件流；当社区Gerrit有新的变更和补丁提交时，将变更代码与厂商提供的硬件环境进行集成测试并向社区Gerrit反馈测试结果；
·本地OpenStack资源池，为第三方CI系统运行提供虚拟机资源；
·存储设备，用于对变更代码进行验证。图0-1 第三方CI架构图
通过这种机制，Cinder项目可以及时发现变更代码的兼容性问题，厂商也能及时发现变更代码对设备驱动的影响。所有第三方CI系统的执行结果都会显示在社区Gerrit系统每个代码变更的评审记录中。
OpenStack CI系统提供了一套动态调度测试任务的方法，极大提升了开发效率，具体优点如下：
·提高CI系统的并发性，开发人员的多个变更测试任务不需要在环境排队等待执行，只要本地OpenStack资源池资源足够多，就可以并行执行所有测试任务，这可以显著减少开发人员的等待时间；
·提高测试任务的可管理性，使用YAML文件描述测试任务，易阅读、评审，可进行版本管理，容易在不同团队之间复制和重用；
·可定制虚拟机基础镜像，如支持不同的操作系统、不同的软件栈配置，增加了在项目实际使用中的适用性和灵活性；
·提高测试任务的准确性，每次测试任务都在相同的环境和配置下执行，不存在静态环境中测试任务执行后对软件、配置文件等清理不完整而导致测试任务执行不一致的问题；
·可复用云环境，统一运维资源，减少维护开销并提高资源利用率。
这套CI系统不仅适用于OpenStack社区组件研发，也适用于电信网元的开发。基于此，笔者所在的团队潜心研究OpenStack CI这套系统，结合自身需求，增强了CD的方案和实践，最终形成一套完整的CI/CD解决方案。这套解决方案在团队得到广泛应用，无论是内部的维护工作，还是对外的技术合作，都由该CI/CD系统提供技术支撑。公司数字化转型战略和敏捷实践触发了内部项目对CI/CD技术的重视，越来越多的团队渴望获得和提升这方面的技能。所以，笔者所在的团队作为开源技术的先锋，在给内部进行培训和技术转移的过程中，诞生了把对该系统的经验、实践汇总整理并出版成书的想法。
了解OpenStack的人很多，但对OpenStack CI系统有实际应用经验的人很少，主要是因为OpenStack CI系统目前只用于OpenStack社区基础设施的管理。国内DevOps思想和技术在最近两年才得到大规模接受和实践，大家对了解CI/CD相关技术的需求非常高。笔者很荣幸把这套适用性广、定制性强和并发性高的CI系统介绍给大家，同时回馈社区，推广和普及这些基础设施技术。目前，国内外几乎没有该套系统的完整描述，因其组件众多，且搭建该系统需要投入大量的人力物力（笔者团队搭建该系统花费了近两个月的时间，这还是在使用社区已有安装脚本进行最简安装的情况下）。从目前已经接入的第三方CI环境来看，国内搭建OpenStack CI系统的公司凤毛麟角，说明在OpenStack技术如此普及的情况下，国内公司对这套OpenStack CI系统仍然知之甚少。希望本书能让读者少走弯路，事半功倍。本书结构
本书从逻辑上可分为四部分：
·第一部分（第1章和第2章）对DevOps的发展、文化和转型进行了简单说明，并引入本书的重点内容OpenStack CI/CD说明其对DevOps转型的重要性。
·第二部分（第3～9章）以系统管理员视角对OpenStack CI/CD中的每一项关键技术进行详细的分析和阐述，这些关键技术包括：
·版本控制（Git）与代码评审（Gerrit）系统，开源社区最常用的代码管理和代码评审工具，Gerrit系统与本书介绍的持续集成系统和门控系统进行密切配合，共同完成整个开发流程。
·持续集成系统（Jenkins），最为流行的一款开源持续集成工具，用于代替人工进行重复的持续集成工作，同时也为促进持续交付提供技术支撑；该章还介绍了JJB（Jenkins Job Builder）工具，通过YAML文件来定义Jenkins任务，提升Jenkins任务的开发和运维效率。
·门控系统（Zuul），确保主线稳定，仅当与变更相关的所有测试都通过后，才会将变更合入相应的目标分支中。它保障了测试任务获得最大程度的并行，且在发生错误的情况下，自动回滚；它支持指定项目间变更依赖关系，解决跨项目集成问题，致力于守护项目及关联项目。
·资源管理系统（Nodepool），通过在OpenStack资源池中动态创建虚拟机并作为Jenkins Slave节点添加到Jenkins的资源池中，确保不同的测试之间互不影响；在测试结束后，删除使用过的虚拟机，保证对每个测试任务都能提供一致的测试环境；此外，Nodepool还集成了镜像制作功能，支持测试环境的定制开发。
·日志服务器，对所有测试任务提供统一的日志存储服务，以便回溯测试故障。
·日志分析系统，将测试过程中的测试日志导入Elasticsearch中，便于出现问题时，快速检查和分析故障。
·公共组件，重点介绍了支持OpenStack CI系统组件之间进行协作和通信的系统，包括任务分发（Gearman）、消息队列（ZeroMQ）和分布式协调服务（ZooKeeper）等组件。
·第三部分（第10章）描述团队在社区工具和经验的基础上的经典实践，以及如何进行裁剪、扩展和定制化修改以满足团队需求。
·第四部分（第11章）探讨当前解决方案中存在的不足和可行的优化方案，并描述了社区当前正在经历的变化和未来的演进路线。
尽管本书各章节功能相对独立，笔者建议顺序阅读第3～5章，因为这些章节大量使用了前序章节的基本概念和术语；其他章节可以根据需要进行翻阅。本书读者
本书面向基础设施管理团队、DevOps团队或致力于了解CI/CD的技术人员，可作为学习OpenStack社区CI/CD基础设施解决方案的教材，协助你高效搭建社区第三方CI系统。勘误与交流
笔者团队在编写本书的过程中虽已经进行了大量的内部评审和检验工作，但因时间紧、精力有限，难免会出现一些错漏，敬请广大专家和读者批评、指正。你可以把与本书相关的意见或建议发送到电子邮箱openzero@aliyun.com中。
本书中团队实践和示例代码都可以在GitHub上进行下载，读者可以尝试使用并与我们进行探讨。致谢
本书的创作团队是一支拥有丰富专业技术经验的团队，团队成员有十年以上电信领域的工作经验、四年以上开源社区技术研究和贡献经验。本书是团队智慧和多年经验的结晶。使用本书介绍的技术和经验，希望可以帮助你的团队高效管理公司内部的基础设施，节省大量人力资源，并提供快速而稳定的服务。
本书由创作团队在业余时间编写，占用了团队成员很多家庭生活的时间，每位成员都付出了极大的努力并克服了诸多困难，对此表示感谢。感谢所有团队成员不厌其烦，一次又一次地评审修订，以认真严谨的态度验证了本书所有的代码实践。感谢董文娟在本书编写过程中有力地组织、协调和推进，没有你辛勤的付出，本书不可能顺利完成。
在此，还要感谢我的领导潘峰、王前和施嵘，没有你们的信任和支持，不可能有本书的诞生。感谢中兴学院的闫林院长对本书的指导和建议。感谢OpenStack基础设施团队设计出如此优秀的工具和系统，感谢你们在日常工作中及时答疑解惑。感谢机械工业出版社的杨福川和李艺编辑的信任和支持，及时更正了本书中较多的排版问题。张军第1章 DevOps
什么是DevOps？为什么DevOps会受到越来越多的关注？“DevOps”是英文单词“Development”和“Operation”的组合，即开发和运维的结合。目前DevOps并没有权威的定义，但得到大部分人认可的是，DevOps已经成为一种文化价值观和实践方法。DevOps价值观的呈现和实践并不依赖于特定的软件，但通过合适的软件工具链的支撑可以更容易实现这一价值观。
DevOps使得业务可以更快地运营，更快地应对变化。2017年DevOps现状调查报告显示，工作于DevOps团队的人员比例达到27%，相比于2014年，增加了一倍。DevOps能够缩短上市时间，提升产品质量并增加营收，从而受到越来越多的公司关注并进行实践。1.1 DevOps简介
谈到DevOps，就不得不回顾一下软件开发模型（Software Development Model）的历史。软件开发模型是指软件开发全部的过程、活动和任务的结构框架。它包括需求、设计、编码和测试等阶段，有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程，明确要完成的主要活动和任务。本章不会系统介绍曾经出现的所有软件开发模型，只选取其中较典型的瀑布模型、迭代模型、敏捷模型进行说明，以及如何演进到DevOps。1.1.1 软件开发模型
瀑布模型严格遵循预先计划的需求分析、设计（可细分为系统设计、概要设计、详细设计）、编码、集成、测试的步骤顺序进行。上一阶段的成果输出成为下一阶段的工作输入，阶段之间通过交付大量的文档进行传递。严格分级、分阶段导致团队的灵活性降低，使项目难以响应需求的变化，难于调整或调整的代价极高。
迭代式开发模型每次只设计和实现这个产品的一部分，在迭代式开发方法中，整个开发工作被组织为一系列短小的、固定长度（如4周）的小周期，被称为一系列的迭代。每一次迭代中都会包含完整的需求分析、设计、编码与测试，再通过反馈来细化需求，并开始新一轮的迭代。这种方式弥补了瀑布模型中的一些弱点，加快了对变更的响应速度，可以提前识别问题，从而降低了项目风险，提升了项目成功率和生产率。
敏捷软件开发模型，是一种从20世纪90年代开始逐渐引起广泛关注的新型软件开发方法，能应对需求的快速变化。敏捷强调开发人员与业务专家之间的紧密协作，强调面对面的沟通，强调频繁交付新的软件版本，强调能够很好地适应需求变化的代码编写和团队组织方法，也更加注重软件开发中人的作用。
瀑布式开发，从需求到测试，要求每一个开发阶段都要做到最好，特别是前期阶段，设计得越完美，提交后的成本损失就越少；迭代式开发，不要求每一个阶段尽善尽美，而是先实现主要功能，再通过持续反馈逐步完善；敏捷开发，相比迭代式开发，两者都强调在较短的开发周期交付软件，但敏捷开发的周期可能更短，更强调团队的高度协作，强调适应性而非预见性。1.1.2 DevOps发展历史
自从人类创造了计算机，就诞生了程序员（Programmer）这个职业，从为计算机编写程序以利用其计算能力，逐渐演变为专职的实现特定功能的开发人员（Developer）。后来由于存在大量的软硬件资源需要维护，又逐渐出现专职的运维人员（Operator）这一职业。
开发人员关注更快实现功能并交付开发产品，运维人员关注如何使产品运行得更加稳定。Dev和Ops的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。而DevOps打破了开发和运维两个部门、团队之间的障碍墙。
2009年6月，在Velocity大会上，一个名为《10+Deploys Per Day：Dev and Ops Cooperation at Flickr》的演讲成为本次大会最大的亮点，几乎所有和DevOps相关的资料都引用该演讲作为DevOps出现的标志事件。这个演讲提出：“以业务敏捷为中心，构造适应快速发布软件的工具和文化。”
第一届DevOpsDays于2009年10月在比利时根特举行，这次聚会开创了DevOps活动的先河。本次活动尽管只通过推特（Twitter）发起和召集，却出乎意料的成功。世界各地的开发工程师、运维工程师，还有各种IT管理人员、工具爱好者齐聚一堂分享相关技术和实践。从此之后，DevOps在全球开始流行起来。近几年随着微服务和Docker的流行，DevOps得到大规模的应用和实践。
敏捷和DevOps并不是孤立或对立的关系，其实敏捷是DevOps中的关键组成部分。一般而言，敏捷关注于开发过程中的实践，而DevOps包含从开发、持续测试、持续部署到运维的整个过程。图1-1可以更好地帮助我们理解它们在软件开发过程中所处的环节。图1-1 DevOps生命周期
·敏捷实践包含了从规划（涉及需求分析和设计）到代码开发和构建的过程。
·持续集成CI（Continuous Integration）在敏捷实践的基础上包含了持续构建和测试的过程；持续集成加强了对开发人员的反馈过程，快速验证并解决问题，提升开发效率。
·持续交付CD（Continuous Delivery）在持续集成的基础上，增加了持续进行版本交付的过程；持续交付加强了对测试人员的交互过程，每天都有可用的版本，避免测试阻塞，提升测试效率。
·DevOps在持续交付的基础上，包含了持续部署和运维反馈的过程；DevOps加强了用户体验，用户所使用的环境每天迭代更新，用户反馈的问题短时间得到更新，用户体验得到持续提升。图1-2 DevOps循环1.1.3 DevOps循环
经典的DevOps循环如图1-2所示。
这个循环包含了开发和运维两部分工作，通过自动化的测试和部署把这两方面的工作进行集成。一份关于敏捷和自动化测试的报告显示70%的团队采用了敏捷实践，但只有30%的团队采用了CI实践，至于CD就更少了。1.1.4 DevOps价值
DevOps可以缩短软件发布周期，提升软件质量、安全以及反馈速度。从2016至2017年的DevOps现状调查变化中可以看到，2017年DevOps进一步提升的目标不再是生产效率，而是质量和稳定性。
DevOps有如下一些价值：
·文化：DevOps首先是一种团队文化的转变，团队拥有共同的目标和信仰。
·沟通协作：沟通在团队工作中非常重要，团队可以通过一些实时工具进行协作，通过持续沟通，团队的任务对所有成员可见，团队成员掌握了最新进展，可以有效进行技能传递，消除由于沟通、依赖导致的无效等待，改进团队全方面的能力，包括设计、开发和监控。
·信任：是团队的最大特质，没有对团队成员的信任，团队不可能获得成功；成员之间在沟通、协作的过程中增强了相互之间的信任，同时也增强了团队凝聚力，提升了工作质量。
·减少对专家的依赖：此前大部分组织都是领域专家领导的面向功能的开发团队，比如开发部、质量部、网络管理部、数据库管理部等。DevOps通过取消这些特性团队来减少对专家的依赖；团队的每个成员都是通才，可以解决团队面临的各方面的问题。
·系统性思考：以业务逻辑的视角来全面理解系统所实现的功能，而不只是局限于深入理解某个领域。
·精益生产：为组织的纪律、效率和有效性设置标杆；在此过程中努力做到消除浪费、加强质量、延迟承诺、快速发布、尊重个人和全局优化。
·自动化：所有需要重复执行的工作都努力做到自动化、代码化，经验可复制、可推广。
·持续改进：创建一个持续改进的文化氛围，无论是困难还是收获都进行分享，努力打造学习型团队，最终得以持续改善日常工作。1.2 DevOps与团队文化
DevOps团队在内部共享态度、价值、目标和实践，而这些团队通常具有如下特质：
·团队每个成员都有极大的自主权，可以选择愿意承担的工作、任务和挑战；充分授权让团队成员拥有极大的自信，同时也能够得到快速锻炼。
·团队成员共担责任，对于错误或失败每个人都有责任，是团队整体的错误，而不归责于某个成员。
·团队成员在接受不同任务的过程中，可以更全面地了解团队承担的职责，对于团队成员实现的功能也增加了认识和理解，在此过程中，进一步锻炼了自己的能力，可以参与各种角色和功能开发。
·团队成员分享快乐和痛苦，一同解决技术问题、跨越障碍，收获成功和喜悦，并共同分担在此过程中的痛苦和磨炼。
·团队成员在解决困难、分担和分享的过程中学会担当，因而，每个成员都会积极处理团队需要承担的事务和需要解决的问题，进一步提升团队的主动性和自治性。
如果认为使用自动化的工具把开发和运维工作结合在一起就达到了DevOps，或者某个特定的团队来实施DevOps，其他团队保持传统的开发模式，其实就是打着DevOps旗号的伪实践，DevOps的价值和文化很难在这种模式下表现出来并发挥作用。DevOps是一种文化的转变，团队成员同时负责了开发、部署和运维的工作。在开发过程中不考虑如何部署，不考虑如何运维，仍然是割裂的团队和工作模式。
在向DevOps团队转型的过程中，可以通过表1-1中的指标把团队分为三个等级：表1-1 DevOps团队转型过程中的分级指标注解
变更前置时间指的是从代码提交到代码在生产环境中成功运行之间的时间；低效能团队的代码部署频率在2016年至2017年间得到了大幅提升，从1次/月～1次/半年提升到1次/周～1次/月。
让我们看一下高效能团队和低效能团队在表现上的差异：
·高效能团队的部署频率是低效能团队的46倍。
·高效能团队部署变更到生产环境的效率比低效能团队快440倍。
·高效能团队部署故障恢复时间比低效能团队快96倍。
·低效能团队部署变更失败率比高效能团队高5倍。
·高效能团队人工参与的时间相当于低效能团队的60%～70%。
·高效能团队倾向于使用主干分支，每天向主干分支合入，分支只存在若干小时，而低效能团队则采用长时间的特性分支。
·高效能团队更倾向于使用松耦合架构，无论是团队独立开发的应用和服务，还是必须与其他团队合作开发需要交互的服务。
中国第一份DevOps年度调查报告中指出，国内50%的团队的DevOps实践经验都少于1年，同时随着团队在DevOps上的经验积累，自动化方面的投入增加，变更失败率可以得到逐渐降低。从2017年的DevOps现状调查报告中可以看到，在亚洲，工作于DevOps团队的比例大约是10%，而在美洲则高达54%，这也就不难解释国内经验不足的现状了。1.3 DevOps工具链
以下是业界在DevOps工具链方面的经典实践，在使用时可以参考。
本节只简单列举一些主流的DevOps工具（如图1-3所示），在本书的后续章节，会对部分工具进行详细阐述。图1-3 DevOps工具链（1）Git
Git是一个自由且开源的分布式版本控制管理系统，功能丰富、性能出众，但又十分轻量，可扩展性非常好。轻量“廉价”的分支管理使其非常适合于敏捷开发，能及时响应需求和变化，开发人员可以在多任务之间轻松切换。（2）JIRA
JIRA是项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA提供了一系列敏捷工具，如Scrum和Kanban。（3）Maven
Maven是一个项目管理和自动构建工具。它强调构建过程中的两个重要方面：如何构建和描述依赖关系。在实际使用中还可以通过一系列的插件来扩展各个阶段的流程。由于Maven包含许多重用性很强的默认规则，往往几行代码就可以完成一个项目的构建。Maven通常用来管理Java项目，但也可以用于管理C#、Ruby、Scala等其他项目。（4）JUnit
JUnit是一个Java语言的单元测试框架。多数Java开发环境都已经集成了JUnit作为单元测试的工具。JUnit是一套框架，使用比较简单，只要继承TestCase类，就可以用JUnit进行自动测试了。（5）Jenkins
Jenkins是基于Java开发的一款开源的持续集成工具，用于代替人工进行重复的持续集成工作，同时也为促进持续交付提供技术支撑。它支持各种版本控制工具，如CVS、Git、ClearCase等，并且可以与多种构建工具进行集成，如Ant、Maven，甚至有自定义的Shell脚本。Jenkins是开发和部署连接的纽带，社区活跃，有大量的插件来扩展其功能，是实现自动化的关键。（6）Puppet
Puppet是一款集中配置管理工具，使用自定义的DSL描述语言，可管理配置文件、cron任务、软件包、系统服务等。Puppet采用C/S结构，每个客户端周期性（默认半个小时）地向服务器发送请求，获得其最新的配置信息，保证系统和该配置信息同步。（7）Ansible
Ansible是一款新出现的自动化运维工具，基于Python开发，有批量配置、部署、运行命令、编排复杂任务等功能。与其他自动化运维工具的显著不同在于它只需使用SSH服务（SSH可以说是各种Linux服务器的基本服务），它不需要在被管理节点上安装组件或代理。Ansible本身提供了上千种Module可供使用。（8）Nagios
Nagios是一款开源的网络监视工具，能有效监控Windows、Linux和UNIX等各种主机、交换机、路由器等网络设备。在系统或服务状态异常时可以发出邮件或短信报警，第一时间通知运维人员。1.4 DevOps转型
DevOps涉及文化、技术、工具等一系列支撑，业界在这方面有太多的选择，但却没有明显的解决路径，而国内这方面的人才又比较匮乏，在任何一方面的技能缺乏或没有得到合适指导的情况下，目前正在DevOps转型过程中的团队很容易失败。
有些服务提供商，已经开始咨询如何进行DevOps转型，但痛苦的是，能胜任这项工作、有经验的顾问太少。许多公司希望寻求一个适合所有人的模式或方法，这往往会造成更多的问题。举个例子，某些公司在既不考虑这个转变是否创造了足够的业务价值，也忽略了必要的、充分的文化转变的情况下，就去构建一个DevOps平台。
通信、有线、娱乐和媒体公司为了跟得上市场需求，就需要有能力持续发布新产品和服务。与此同时，随着互联网普及、开源模式得到更广泛的接受，新技术的推广速度越来越快。但在短时间内实现新业务、上线新活动仍然不是一件轻松的事情，这需要强大的IT基础设施的支持。在IT所面临的挑战中，可以看到，识别出哪些IT领域需要进行DevOps转型是非常困难的。如图1-4所示，IT领域所面临的挑战大约有十项，例如：掌握开源模型和生态系统、合作伙伴管理、不充分的集成策略、缺乏清晰的技术架构路线图等，其中有16%受访者第一选择都是识别出哪些IT领域需要进行DevOps转型。图1-4 IT所面临的挑战
本书将协助你了解支撑DevOps的技术全貌，了解当前你的团队所处的状态，并一步一步掌握转型至DevOps团队所需要的关键技术和技能。通过本书的学习和本书作者所在团队亲历的最佳实践的总结，希望能够协助你，选择出适合的技术路线，构建一种可扩展的、高可靠、高并发的CI/CD支撑平台，降低技术债包袱，逐步完成DevOps转型。1.5 本章小结
本章简要介绍了软件开发模型以及DevOps实践的价值和转型工作，本书的后续章节将详细说明如何构建一个支撑DevOps转型的CI/CD平台。第2章 CI/CD
DevOps贯穿软件生命周期的全过程，而CI/CD则是它的基础和技术核心，在没有自动化测试、持续集成和持续部署的支撑下，DevOps就是空中楼阁。2.1 CI/CD介绍
CI是指持续集成（Continuous Integration，CI），狭义的CD指持续交付（Continuous Delivery，CD），广义的CD指持续部署（Continuous Deployment）。所谓的持续，就是说每完成一个完整的部分，就向下个环节交付，发现问题可以马上调整，使问题不会放大到其他部分和后面的环节。集成是指个人研发的软件部分向整体部分交付，以便尽早发现个人开发部分的问题；交付是指研发尽快向质量团队或者用户交付，以便尽早发现生产环境中存在的问题；部署是代码通过测试后自动部署到生产环境。2.1.1 持续集成
随着软件项目复杂度的增加，对软件组件之间的集成和协同工作提出了更多的要求。如果开发人员在后期才进行集成，发现和解决问题的代价会很大，很有可能导致项目延期甚至失败。因此要“尽早集成、经常集成”，在项目早期发现的风险和质量问题更容易得到解决，并保证了开发进度，持续集成就诞生在这样的背景下。
持续集成指的是频繁地将代码合入到主干分支，只有通过自动化测试和验证的代码才能被集成，目的是让产品在可以快速迭代的同时还能保证质量。简单来说就是，针对软件系统的每次变更，能持续且自动地进行验证：构建、测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起，并确保核心功能正常执行，不受影响。Martin Fowler说过：“持续集成并不能消除Bug，而是让它们非常容易被发现和改正。”
持续集成的流程如图2-1所示。图2-1 持续集成的流程
开发人员首先获取当前工作代码库的副本。随着其他开发人员将更改后的代码提交到源代码库，此副本逐渐与远端代码库不同步。代码库可能不仅仅被更改，还可能添加新库，或者增加其他引起依赖或者冲突的模块。
代码分支检出的时间越长，当开发者分支重新集成到主线时，集成冲突和失败的风险就越大。当开发人员将代码提交到代码库时，必须先更新代码，使本地副本和代码库中的主线分支同步。代码库包含的更改越多，开发人员在提交自己的变更前必须执行的工作越多。
开发人员的代码提交到源代码库，即触发CI服务器开始构建和测试，并把测试结果反馈给开发人员。测试通过，代码即合并到代码库中继续下一轮的测试；测试失败，开发人员根据反馈结果修改后重新提交。
以上过程循环重复即持续集成。
持续集成一般由代码变更触发，遵循先进先出的原则，否则容易引起混乱，很难定位是谁的代码破坏了集成；而且构建时间不能太长，否则构建次数太少，大部分变更一直处于等待状态。
需要补充一点，在代码提交之前，开发人员必须在本地完成单元测试，集成测试通常在检测到新提交时在CI服务器上自动运行。
持续集成的好处就在于：
·快速发现错误，变更容易追踪，节省了项目生命周期间的时间和金钱。
·避免版本发布最后时期才集成的混乱。
·测试失败或出现bug时更容易恢复。
·保证主干分支的可用。
·频繁地集成推动开发人员设计模块化、不太复杂的代码。
可以说，持续集成是DevOps的重要基础环节。2.1.2 持续交付
持续交付指在持续集成的基础上，频繁地将集成后的代码交付给质量团队（QA）或者用户，部署到更贴近真实运行环境的类生产环境中以供测试评审，通过就进入发布，生产阶段。它旨在更快更频繁地构建、测试和发布软件，有助于降低交付的成本、时间和风险。直接和可重复的部署过程对于持续交付非常重要。持续交付并不意味着每个变更都会尽快部署到生产环境中，它意味着每次更改都被证明可以随时部署。持续交付的目标不是要消灭缺陷，而是要规范开发和测试的流程，从根源上提高产品的质量。开发人员需要了解任何代码提交都可能会随时发布给客户，这一点很重要。
持续交付的流程如图2-2所示。图2-2 持续交付的流程
由图2-2可以看到，持续交付在持续集成的基础上多了手工部署和系统测试等流程。
持续交付的产品一般有：
·源代码交付：比如Python/Shell脚本，但这些文件不是标准的软件包，不利于集中管理和运行。
·软件包交付：比如通过RPMBuilder工具制作Linux标准包。
·镜像交付：可以是虚拟机镜像也可以是Docker镜像。
持续交付的优点：
·提高了产品质量，加快了产品上市时间。
·产品更符合用户需求，提高了客户满意度：频繁地发布使开发团队可以更快地获得用户反馈，专注于开发对客户有用的功能，有助于构建正确的产品。
·提高了生产力和效率。
在实施持续交付的过程中，必须考虑将基础设施的维护纳入进来，作为支持产品运行的一部分。传统的基础设施运维管理存在以下几个问题：
·自动化缺乏串联：虽然有一定的自动化，但不能做到无人值守，需要执行一些临时命令。由于环境释放和重建的成本高，因而倾向于不释放，导致资源利用率低。
·与产品团队脱节：很难根据需求随时动态增加环境。需要额外的文档来描述环境，可能更新不及时。
通过基础设施代码化（Infrastructure as Code，IaC）可以解决上述问题，大大有助于实现持续交付，促使持续交付和DevOps的成熟，是DevOps的一项关键实践。
IaC有四项关键原则：
·再生性：环境中的任何元素可以轻松复制。
·一致性：无论何时，创建的环境中各个元素的配置是完全相同的。
·快速反馈：能够频繁、容易地进行变更，并快速验证变更是否正确。
·可见性：所有对环境的变更应该容易理解、可审计、可回退、受版本控制。2.1.3 持续部署
持续部署是持续交付的下一阶段，指的是软件通过测试后自动部署到生产环境。持续部署的前提是能自动化完成测试、构建、交付等步骤；目标是代码在任何时刻都是可部署的，可以进入生产阶段。
持续部署的流程如图2-3所示。
持续部署意味着每次更改都会自动部署到生产环境中，强调的是自动化。为了进行持续部署，必须持续交付。虽然持续部署可能不适合每个团队或项目，但持续交付是DevOps实践的绝对要求。2.1.4 CI/CD工作流
以上简单介绍了CI/CD的概念及每个阶段的工作流程，整合起来即一套完成的CI/CD流水线。在实际应用中，一般通过代码评审系统实现代码审查和集成反馈。整个CI/CD系统配置了代码仓库系统、代码评审系统和构建工具系统。图2-3 持续部署的流程（1）代码提交
开发者向代码评审系统（比如Gerrit）提交代码。（2）测试
系统监听到代码评审系统的事件后即触发相关的测试。这里的测试有如下几种：
·单元测试：针对函数或者模块的测试。
·代码风格检查：针对代码编写的风格进行检查，比如Python的pep8等。
·集成测试：功能测试。（3）构建
测试通过后代码就可以合入主干分支，同步到代码仓库，进行下一阶段的构建了。所谓构建，就是将源代码转换为可以运行的软件包或者镜像等。（4）测试
构建完成后进行下一轮测试，此阶段的测试比第一轮测试全面，包括功能测试、系统测试、性能测试等。（5）交付
第二轮测试通过，代码就进入发布、生产阶段。（6）部署
经过多轮测试后的版本就是一个可直接部署到生产环境的稳定版本，此版本发布到制品库上，用户就可以在获取版本后通过自动化工具部署到生产环境。
工作流有了，接下来就是选择每个阶段的工具搭建整个自动化的生态系统，在没有制定出CI/CD的工作流时考虑工具的选择只是纸上谈兵，只有在设计好工作流程和业务流程之后再选择相匹配的工具集才有意义。2.2 OpenStack CI/CD
OpenStack作为现在世界上第二大开源社区，有着一个完整的、标准化的、自动化的持续集成测试平台。它由社区的OpenStack-Infra团队开发维护，具有高可靠性、灵活性和可扩展性，对于搭建企业内部CI/CD系统有非常好的借鉴意义。注解
社区的持续交付，主要应用于版本发布，后文如不做特殊说明，CD指的都是持续交付。框架上是支持持续部署的。2.2.1 当前CI/CD系统的形态
以Jenkins作为持续集成工具为例，CI/CD系统的复杂程度分4个等级：
第1级：如图2-4所示，仅使用Jenkins，且都在一套服务器上，适用于产品项目较小、资源较少的场景，使用维护较为简单。
第2级：如图2-5所示，在第1级的基础上引入了Gerrit评审系统，但是具体构建还是在本地，测试环境受限。图2-4 CI/CD 1级图2-5 CI/CD 2级
第3级：如图2-6所示，也是目前稍具规模的公司或社区都会使用的系统，使用Jenkins+Jenkins-Job-Builder（JJB）工具。在执行构建时，使用了一些静态资源（如虚机、容器或物理机），可以满足多场景构建和测试需求，但是资源利用率较低，多次测试的环境上下文存在耦合，目前OPNFV社区使用这种框架。
第4级：如图2-7所示，在第3级的基础上引入了任务门控系统（Zuul）和动态资源管理系统（Nodepool）的使用模式，也是目前OpenStack开源社区的应用。
首先我们来学习一下OpenStack社区的CI/CD框架。图2-6 CI/CD 3级图2-7 CI/CD 4级
试读结束[说明：试读内容隐藏了图片]