共计 5665 个字符，预计需要花费 15 分钟才能阅读完成。
提到 DevOps，很多人就想到了 CI/CD Pipeline，甚至很多集体或者企业认为实现了 CI/CD Pipeline 就等于实现了 DevOps，尽管这种观点有失偏颇，然而从侧面反映了 CI/CD Pipeline 在 DevOps 中扮演着无足轻重的位置。CI/CD 是 DevOps 的两大要害外围能力。CI/CD Pipeline 的真正实现会减速企业向 DevOps 转型的过程。本文将揭开 CI/CD Pipeline 的神秘面纱，来一探到底。
一、什么是 CI/CD Pipeline
Pipeline 指管道或者流水线，相似于工厂里的生产线，原料从一端输出，两头通过多个工作核心，一个工作核心的输入作为下一个工作核心的输出，最终在另一端输入高质量的产品。CI/CD Pipeline 指 CI/CD 的流水线，在输出端输出源码，通过既定工作流，最初在输入端输入对用户有价值的产品。从字面就能看出侧重点继续、流水线。
CI/CD Pipeline 的简略示意图如下。
开发人员提交完代码，通过一系列的流程，最初生产出有价值的应用程序。
二、为什么须要 CI/CD Pipeline
DevOps 的呈现就是为了解决理论问题：突破横亘于开发人员与运维人员之间的壁垒。CI/CD Pipeline 能够帮忙实现这个目标：开发人员在代码提交之后，就有 CI/CD 流程来对所开发代码的功能性，健壮性，安全性等进行验证，如果验证失败，就返回至开发人员处，持续批改；如果通过既定流程，就能够进行生产部署。
当然，整个流程必须是齐备的，测试环节必须是谨严的，开发环境，测试环境，生产环境应尽量保持一致，以此来防止环境不统一导致的上线失败。且整个过程中所有的变更，包含代码变更，部署脚本变更，环境配置变更都是可追踪的，便于呈现问题之后进行回溯与复盘。这样，开发人员就不会放心代码不可能及时部署到生产线，而运维也不用放心新上线的代码会导致系统解体。
此外，CI/CD pipeline 有助于缩短应用程序的公布周期，进步应用程序的公布频率，疾速取得市场反馈，及时作出响应。这种良性循环有助于应用程序抢占市场，给企业带来效益。
《凤凰我的项目: 一个 IT 运维的传奇故事》中比尔团队的故事就是对上述过程的一个很好佐证：当比尔团队将凤凰我的项目的部署流程梳理分明之后，进行了 ” 流水线 ”(书中虽不叫 CI/CD Pipeline，然而内容却是一样，能够认为是 CI/CD Pipeline 的雏形)革新，在大大提高凤凰我的项目公布频率的同时，业务部门与 IT 部门之间的矛盾也变得越来越少，公司盈利了，也就防止公司被拆分，IT 部门被外包的危险。
基于此，CI/CD Pipeline 个别具备以下几个特点：
- 标准化的步骤：应用程序交付流水线中的构建，测试等步骤，一个都不能少，而且环环相扣。
- 可主动部署：从代码提交那一刻起，所有流程都应该是主动的，自动化的益处毋庸置疑：节省时间，缩小人为干涉，防止人为误操作；” 一键式 ” 部署让部署变得简略。
- 实用多种语言：CI/CD Pipeline 应该实用于大多数甚至全副语言类型的应用程序，java，php，python。可能只需针对不同语言做大量调整。而不须要每种语言对应本人的 CI/CD Pipeline。
- 具备可移植能性：应用程序在不同部署环境下 (比方从私有云到公有云，从 AWS 的 Kubernetes 平台到 IBM 的 Kubernetes 平台) 迁徙的时候，Pipeline 能够在不改变或者大量改变的前提下，实现迁徙，这样进步了灵活性，缩小了工作量。
三、CI/CD Pipeline 蕴含的阶段
一般来讲应用程序交付流水线有如下图所示的几个阶段：
3.1 打算阶段
此阶段次要是项目经理或产品经理从用户处获取应用程序的相干信息，从而制订开发计划，来对前期开发进行领导。在麻利流行的明天，很多公司在此阶段都用麻利来进行开发治理，以迭代的形式来实现用户故事的开发。
3.2 编码阶段
这个阶段次要是开发人员通过 IDE 来进行代码开发，开发人员借助于装置在 IDE 内的一些插件，来编写合乎公司编码标准和平安需要的代码。
3.3 构建阶段
构建阶段是能够算是 CI/CD Pipeline 的真正开始阶段，开发人员在本地实现代码开发，并将代码提交到源码管制工具(比方 git)，此时会触发 CI 流程，进行代码扫描，编译，单元测试及覆盖率测试等工作。如果流程是胜利的，那么代码就会被合入主干分支(合并能够是手动，也能够是主动，这取决于我的项目的开发模式与规定)。而一旦某个环节呈现失败，都会使得整个流程中断，并将相应信息反馈至开发人员处。
3.4 测试阶段
代码被部署到测试环境并开展一系列的测试工作，包含手动的，主动的；性能的，性能的，平安的。须要留神的是，此阶段测试所需环境最好与生产环境保持一致，防止因环境不统一导致的上线失败。
3.5 版本筹备阶段
测试阶段验证胜利当前，能够认为代码已具备上生产的能力，测试通过的版本被标记为能够上生产，只须要手动或者主动操作 (取决于我的项目规定) 就能够将版本推送至生产线上。
3.6 部署阶段
将应用程序部署到生产线上。能够采纳手动或者主动的形式来实现部署，同时能够采纳蓝绿部署，金丝雀部署等形式来实现 ” 零宕机 ”、平安部署。
3.7 维护阶段
应用程序上线后，运维团队须要确保利用程序运行环境的稳固，在访问量高的时刻可能主动扩容来应答峰值，访问量低的时候缩容以缩小资源耗费。
3.8 监控阶段
监控应该蕴含两方面的：应用程序的监控和 Pipeline 的监控，借助于监控工具来获取一些无效数据，而后反馈给开发团队，或者运维团队，以此来进一步提高应用程序及 Pipeline 的稳定性，安全性。
CI/CD Pipeline 简直等同于应用程序交付流水线，它与之绝对应阶段的关系如下图所示。应用程序交付流程从打算阶段开始，而 CI/CD Pipeline 开始于利用程序开发阶段。
四、CI/CD Pipeline 的实现
CI/CD Pipeline 也能够用三步工作法来实现：
- 第一步：实现从输出端源码到输入端产品的正向流程，将源码构建，测试，版本筹备，部署，运维几个步骤串起来；
- 第二步：实现从各个阶段至开发阶段的继续反馈；
- 第三步：在运行过程中与开发，平安等团队单干进行继续改良。比方，让部署流程、检测报告、监控信息可视化。
CI/CD Pipeline 的实现要依赖于一些工具，这也就是为什么很多人说 DevOps 是工具的合集的一个重要起因。尽管观点不全面，然而工具的确是实现 DevOps 不可短少的一环。
工具的抉择能够遵循以下几个准则：
- 拥抱开源
拥抱开源俨然已成为 IT 行业的一种新趋势，开源意味着收费，这能够进一步升高企业老本，另外凋谢的源代码对软件问题的追根溯源有很大帮忙，最重要的一点是，能够借助于开源来疾速推出有价值的商用产品，比方借助于开源的 Linux，Redhat 公司推出企业级的 Linux 产品；借助于开源的 Docker 和 Kubernetes，亚马逊，微软，谷歌，IBM 等公司都减速实现了本人企业级云产品的商用。
- 社区弱小，用户数多
开源工具的抉择必须要思考社区的大小和用户的多少，社区大，用户多，开源工具的迭代就快，性能就弱小，出问题也能找到相应的解决办法。比方 Jenkins，弱小的中英文社区，超过千万的用户，让其变成了最初欢送的一款继续集成工具。
- 丰盛的 API
CI/CD Pipeline 是工具的汇合，工作核心与工作核心的就是工具与工具之间的交互，也就是 API 的互相调用，如果一款工具具备丰盛的 API，那么就比拟容易将其整合进 CI/CD Pipeline。比方 Github，就有对于 release，commit，pull request 等各种 API。
- 易学易用
一款工具可能疾速上手，容易应用，就可能减速 CI/CD Pipeline 的开发，升高 CI/CD Pipeline 的保护难度，大大减少了工作量。
五、CI/CD Pipeline 发展趋势
CI/CD Pipeline 始终在倒退演进，其次要的倒退变动有以下几点：
5.1 云原生
CI/CD Pipeline 的倒退方向跟应用程序是一样的：云原生。有一些云原生的 CI/CD Pipeline 工具，比方 Jenkins，Tekton 等曾经呈现，它们可能进一步提高 CI/CD Pipeline 的效率，减速云原生应用程序的构建。
5.2 GitOps 和 ChatOps
GitOps 和 ChatOps 将占据重要的戏份。GitOps 和 ChatOps 能够将团队，工具，流程，自动化等组成一个高效的、通明的工作流，工作进度高深莫测，所有变更可控、可回溯跟踪，产品的研发效率会随着团队之间沟通协调效率的减少而进步。
Github Action 就是 GitOps 的一个典型例子。Slack 的 bot 就是 ChatOps 的一个典型例子。
5.3 平台化
平台化的益处毋庸置疑：通过将工具，流程的无效整合，使得软件开发生命周期的整个流程透明化，数据可视化，部署流程自动化，为继续反馈，继续改良提供重要依据。
六、CI/CD Pipeline 的一些反模式
6.1 与开发没有关系
开发人员对于 Pipeline 的意识有余，开发模式不做任何扭转。代码提交频率没有晋升，可能是三天一次，甚至是一个新性能提交一次。这样就不能充分发挥 Pipeline 所带来的劣势，产品公布频率就不高。此外，开发认定的工作范畴只是到提交完代码的那一刻，不去关怀整体流程的胜利与否，不去取得继续反馈信息。一旦出问题了，就间接找运维。一次次的 “ 穿新鞋，走老路 ” 也就导致 DevOps 转型的失败。
6.2 构建工夫太长
为了保障代码品质，实现一键式部署，Pipeline 会集成所有的步骤，Pipeline 就显得分外臃肿，一次构建须要几十分钟，甚至几个小时(比方采纳 appscan 实现代码的动动态扫描)。开发人员不违心提交一次代码，期待如此长时间的构建。就会升高代码提交频率，一次提交多个变更。由此，Pipeline 成了进步产品公布频率的瓶颈，继续集成和继续部署就更无从谈起了。Pipeline 应反对产品随时随地部署，能够一天实现屡次部署要求。就好比一条路，不限度下面跑的是人还是车，跑多快，有多少。
6.3 反馈信息简略
当某个步骤的失败导致整个流程终止时，仅仅用一句构建失败来告诉相干人员。这种不明确的告诉就须要相干人员齐上阵一起查处问题的本源，这是一种节约。构建过程中产生的信息应尽量具体，比方代码编译失败，单元测试失败，镜像检测有破绽等。如果是微服务，还应该明确是哪个服务。这样在第一工夫就有相应的责任人去疾速修复。
6.4 破绽是平安团队的事件
当扫描出安全漏洞时，都认为是平安团队的工作领域。报告在，没人管。其实，平安的范畴很大，谬误的配置信息，代码中的敏感信息，都算是破绽。不同层面的破绽应该有不同的团队来负责，比方与利用程序代码相干的应该是开发团队负责，与基础设施相干的应该是运维团队负责，而且两个团队应该与平安团队协调单干，独特修复破绽。
6.5 不合理的人工干预
当修复紧急故障的代码覆盖率不达标，但又不得不上线时，通过升高，甚至勾销代码覆盖率检测来使 Pipeline 胜利；当 Pipeline 在最初一步失败时，为了节省时间，防止从新构建时，通过手动批改流程或者配置来实现 Pipeline。这种为了节省时间而引入的不合理的人工干预，毁坏了 Pipeline 的完整性，人工干预是不可追踪的，引起的故障很难回溯。Pipeline 是一个流程，既然是流程，就应该依据流程走。
6.6 胆怯失败
胆怯构建失败，失败就意味着代码有问题，大家个体炸锅。为了每次构建都失去绿色的后果，调低检测阈值，剪掉常常出错的步骤，最初是开发 happy，运维 happy，测试 happy，大家个体 happy。其实，失败是继续改良的推动力。继续改良的 Pipeline 才是实用的 Pipeline。
七、结束语
能够看到，” 流程 + 工具 + 自动化 ≈ CI/CD Pipeline”。也就不难理解，为什么会有 DevOps 就是流程，就是工具的汇合，就是自动化等这些误区的存在。DevOps 是一场文化静止，CI/CD Pipeline 是这场静止在企业落地实际的强有力伎俩。
附录
下图是基于 Kubernetes 平台的一个 CI/CD Pipeline 示例，仅供参考。
图中呈现的工具均为开源工具，但不是说图中呈现的工具就是最好的，必选的，工具的抉择需依据前述准则来进行。
最上面的属于监控零碎，告诉零碎，每套环境都用到了，而且贯通整个流程。所以只画一次。
CI 流程如果胜利，既能够手动也能够主动部署测试环境；同样的，如果测试环境测试胜利，既能够手动也能够主动部署生产环境。以此实现 CD 流程。
作者：马景贺
马景贺，人称小马哥，花名逍遥子。曾做过 LTE 4G 网络协议开发，后转向 DevOps，对于 Cloud Native DevSecOps 进行布道，喜爱钻研 docker，kubernetes，istio 等 Cloud Native 相干技术，乐于分享，经营着 DevOps SIG 公众号。曾在大连 DevOps 社区活动上，举办 DevOps Workshop 流动。
参考资料
- 《凤凰我的项目 一个 IT 运维的传奇故事》作者 (Gene Kim, Kevin Behr，George Spafford), 人民邮电出版社
- 《DevOps 施行手册 在多级 IT 企业中应用 DevOps》作者 (Sanjeev Sharma), 清华大学出版社
- https://opensource.com/articl…
- https://www.red-gate.com/simp…
- https://devops.com/continuous…
- https://www.plutora.com/devop…
- https://medium.com/taptuit/th…
起源：CIO Talk
5 月每周四晚 8 点，【冬哥有话说】品质与测试专场。公众号留言“品质”可获取地址
- 0506 朱少民《如何最大化软件测试效力》
- 0513 神秘嘉宾 神秘话题
- 0520 陈霁《没错，去 QA 是提高质量最无效的办法！》
- 0527 施慧斌《DevOps 实际之继续测试》
