共计 21796 个字符，预计需要花费 55 分钟才能阅读完成。
很快乐加入 IDCF 组织的第 6 期 DevOps 案例深度钻研，咱们小组的分享主题为《降龙十八掌—CI/CD 继续集成继续部署》，以“企业 CI/CD 转型之路”为核心内容，较为残缺全面地梳理了 CI/CD 从征询到落地实际以及企业内一直优化的全生命周期的过程，和大家一起领略企业在复杂多变的环境之下如何胜利实现 CI/CD 转型。
一、飞龙在天
1.1 CI/CD 概览
首先，咱们来回顾一下 CI/CD 的概念。
在工业实际中，工厂里的装配线以疾速、自动化、可反复的形式，从原材料生产出消费品。——自动化是现代化车间的一个重要规范，能够设想在将来会有更多先进的机器和工具去代替人工，人次要是负责保护和治理这些机器。
同样，在软件行业中，交付管道以疾速、自动化和可反复的形式从源代码生成公布版本。如何实现这项工作的总体设计称为“继续交付”（CD）。启动装配线的过程称为“继续集成”（CI）。确保品质的过程称为“继续测试”，将最终产品提供给用户的过程称为“继续部署”。——运维开发及 DevOps 践行者让这所有简略、顺畅、高效地运行。
1.1.1 继续集成（CI）
继续集成（CI）须要对开发人员每次的代码提交进行构建测试验证，确定每次提交的代码都是能够失常编译测试通过的。
继续集成为咱们的工作带来了很多便当，它的长处包含：
- 尽早发现问题。
- 由多个代码组合，因而，常常操作能够立刻晓得谬误何时何地呈现。
- 轻松编写代码，以便与别人一起评论。
- 代码评论可立刻取得反馈。
其毛病是：
- 当我的项目变大时，很难集成。
- 团队短少互动从而会产生一系列的代码问题。
- CI 不可避免地须要工具，这须要老本。
传统 Source Integration vs Continuous Integration（继续集成）
传统集成：项目经理调配模块给开发人员，每个模块的开发人员并行开发，并行单元测试，一周到几个月，编写大量版本，如果两头有其余更新代码，则更新的代码也须要进行相应的批改。
这样一来，就可能呈现一些问题：
- 模块之间依赖关系简单，集成时发现大量的 bug。
- 测试人员期待测试工夫过长，造成资源节约。
- 软件交付无奈保障。
继续集成能够解决以上问题，每个成员每天至多集成一次，每次都通过自动化的构建（编译、公布、自动化测试）来疾速验证，尽快发现错误。
1.1.2 继续交付（CD）
继续交付（CD）是基于继续集成的根底上，将集成后的代码自动化地公布到各个环境中测试，确定能够公布的生产版本。能够借用制品库实现制品的治理，依据环境类型创立对应的制品库。一次构建，多处运行。
很多人会把继续交付误认为成继续部署，然而两者是两个不同档次的能力。
1.1.3 继续部署（CD）
继续部署（CD）是继续交付的下一步，在继续交付的根底上，由开发人员或运维人员自助式地定期向生产环境部署稳固的构建版本。继续部署的指标是代码在任何时刻都是可部署的，并可主动进入到生产环境。
继续交付和继续部署的比照：
- 继续交付（Continuous Delivery）是指团队确保每个变更能够部署至生产环境，但兴许并不需要理论部署，这通常可能是出于业务方面的起因；
- 继续部署（Continuous Deployment）是指每个变更能够主动部署到生产环境。只有胜利实现继续交付的前提下，能力进行继续部署。它基于一致性，齐全打消了人的干涉，所有已通过品质和测试的 Release 都立刻推送到操作环境。
继续部署带来的益处是：
- 公布频率更快，因为不须要停下来期待公布。每一处提交都会主动触发公布流。
- 在小批量公布的时候，危险升高了，发现问题能够很轻松地修复。
- 客户每天都能够看到继续改良和晋升，而不是每个月或者每季度、每年。
- 主动实时地部署上线，是最优的解决办法，但继续部署要求团队十分成熟，并且上线前需 - 要通过 QA 测试，所以实际上比拟难实现，挑战和危险都很大，个别的团队也很难承受。
1.2 CI/CD 的倒退历史
当初，基本上每个 IT 公司都有本人的 CI/CD 零碎，有的公司甚至不止一套。从 CI/CD 倒退历史来说，大体经验了如下 4 个阶段：
- 人工公布阶段：CI/CD 的操作都是由开发和运维人工染指的，通常是开发做 CI 生成可部署单元，运维将其部署到服务器上。人工形式是最间接、最无效、最易出错的形式。
- 脚本公布阶段：咱们称之为“半自动化”阶段，人工公布过程的很多事件是重复性的，开发、运维人员深感其扰，于是开始寻求脚本帮忙，如 shell、python 脚本。脚本的退出极大缓解了开发运维的重复劳动，但脚本形式还须要很多人工操作，而且脚本的很多步骤会被人为跳过或篡改，造成公布的不标准、不胜利等问题。
- 零碎公布阶段（自动化）：当初大多数公司都在研发本人的 CI/CD 零碎，其目标就是标准公布流程，缩小人为失误，进步公布效率。系统对脚本最大的益处是暗藏细节，不可篡改。
- 零碎公布阶段（智能化）：大数据时代，一些优良的公司曾经开启智能化 CI/CD 零碎，通过引入数据分析、智能预测伎俩，进一步优化公布流程、进步公布效率。
（内容原创：李帅 DevOps DevOps 技术说）
1.3 推动 CI/CD 的内外因素
1.3.1 企业推动 CI/CD 的起因
- 当今商业世界，须要比以往更快的翻新，软件交付也须要更快更好。借助自动化，须要实现的手动工作较少，能够更频繁地公布较小的变更到生产环境，更快地交付产品，疾速取得最终用户反馈，帮忙企业更好、更高效地参加市场竞争。
- 应用 CI/CD，测试和部署过程是通明的。任何问题简直都能够立刻看到，并且能够疾速找到起因，从而缩小了之前在查明问题起因时无可奈何的猜想。
- 谬误缩小。古代软件性能、我的项目和应用程序很简单，谬误也越来越简单。开发人员的手动工作更少，这意味着更少的人为谬误机会。运维部门会收到高质量的代码，QA 须要解决的问题较少，客户服务也不会收到那么多宜人的客户投诉邮件或投诉电话。每个人的工作都失去改善。
- 资源开释。如果将可反复和可预测的工作移交给自动化，则能够为开发人员腾出工夫来做他们喜爱的事件，在放弃原始业务束缚的同时，还能够实现更多工作。
- 客户更称心。更快、更频繁的公布和更少的谬误使得开发人员与其余业务部门之间更加信赖，按时实现工作，取得牢靠的后果以及使最终用户更加称心。
由此可见，CI/CD 是双赢的。有了 CI/CD 和自动化，频繁的集成，可见性，手动操作造成的谬误等问题就打消了。因而，当初越来越多的企业正在向麻利方法论和自动化流程迈进。
1.3.2 案例 – Nationwide
Nationwide（互惠保险，500 强里排名第 69 的一家公司）的转型是从麻利开始的，从瀑布模型逐步转型到 CI/CD，随后在多个团队实现全栈式麻利开发。
第一阶段：从 3 个麻利团队倒退到 200 个麻利团队
一年后麻利团队成熟了，开始规模化麻利。从 3 个团队开始，始终倒退到整个公司绝大多数开发团队都能做到成熟的麻利施行。这一过程花了五六年的工夫，因为公司规模大，问题也是很不错的，从品质、开发速率、零碎稳定性等多方面获得了很好的问题，这是第一阶段的胜利。
第二阶段：新的痛点
进入第二阶段，互惠保险遇到新的问题。
（图片起源：DevOpsDsys 2017 – 北京站）
公司发现整个交付曲线如上图，通过该曲线能够看到两头的设计、开发、测试都做得不错了，速度也很快。但从商业想法开始到包含需要剖析、年度我的项目估算等对 IT 的整体公布速率来讲是一个微小的瓶颈，这个瓶颈占到整个开发流程总工夫的 60%。
另一个比较严重的瓶颈是开发之后始终到产品上线又花了大量的工夫。
公司发现只做麻利是不够的，于是开始依照解决这两个瓶颈的思路去解决问题。
解决新痛点的办法
用一个典型的价值流图去展现整个流程，并剖析这个价值流图。
（图片起源：DevOpsDsys 2017 – 北京站）
首先解决的是产品代码开发当前到上线的环节，就是继续交付阶段。重点要解决的问题是代码写好后怎么上线，整个环节都在优化这个局部。同时还引入了很多新的工具，并进行了架构方面的优化。
1.3.3 CI/CD 的利用
通过以上案例，能够看到 CI/CD 的利用是层层递进的，通过团队的迭代和能力一直向前演进。CI/CD 的能力也不是欲速不达的，须要团队破费大量的工夫和人力去实现，依据团队在麻利 DevOps 的成熟度一直的进步，打牢上一阶段根底前方可开始下一阶段的摸索。
如上图，在麻利开发团队迭代成熟后，能够开始为 DevOps 做筹备，打牢 CI 的根基，而后才能够 Continuous Delivery, 最初到 Continuous Deployment。
1.3.4 CI/CD 中的生产率、投资回报率和转型
通过剖析 DevOps 钻研报告能够看出 DevOps 对生产率、投资回报率和企业转型产生的重大影响。
- 改善用户体验。生产率在 5 年内进步约 20%。
- 老本管制通过高 RoI（投资回报）进行简化。
- 构建团队规模可缩小 30-50%。
- 提供按需部署和审核。
- 随着技术不断创新，DevOps 持续以最高的品质和速度参加。
- 当您能够应用 DevOps 构建负责任的业务环境时，无需申请工作。
- DevOps 工具生成的报告提供业务见解并加强 SDLC 中的可见性。
- 通过端到端治理价值，系统地进步交付速度。
- 生命周期的所有阶段都放弃齐全的可追溯性
- 设计应用程序 UI 和治理 UX 代码是富有成效的。
- 我的项目数据被平安地开发和存储。
- 开发人员能够通过平安的容器注册表和存储库轻松构建代码包。
- 通过自动化软件开发管道来减速自在、不间断的流。
- 放弃了高标准的产品质量。编写代码、验证它、进行更改、构建新代码，甚至将它们集成到源代码中都很容易。
- 测试速度可进步 40-60%。除了自动测试之外，还有代码品质剖析、动态分析平安测试和动态剖析平安测试等流程。
- 对要害根底构造配置信息的拜访通过伪装成秘密变量的工具进行爱护。
- 经营缩小中的中断可缩小 40-60%。
(参考文献：Amol Muratkar.What is DevOps Lifecycle and How to Manage Yours [OL].(2020-03-26))
依据以上 17 点，能够总结演绎出 CI/CD 在软件开发全生命周期过程中为企业带来的 4 点重大收益：
- 升高研发老本
通常咱们会消耗大量工夫去做本地环境配置、测试数据筹备及环境复原，有了 CI/CD 后，从代码生成、推送到代码库后到部署至测试环境中，绝大多数的步骤能够实现自动化，不须要人工干预，只需制订肯定的反馈机制即可，由机器来反馈每个步骤的执行状况，并将这些状况反馈给开发者。
以前咱们可能须要制订专门的软件包治理制品，有了 CI/CD 后，只须要依照肯定的版本号进行约定，通过专门的制品管理软件进行治理，解放人力，让业务人员专一于业务开发，升高研发老本，进步整个研发的效率。
- 软件生命治理规范化
CI/CD 促成软件生命周期治理更加规范化、系统化，让所有的流程有据可依，对自动化也有极大的促进作用。
它体现在：对立源代码治理，更不便资源共享，开发者无需在各种代码库上切换，开明各种各样的代码库权限；对立编译构建环境，一次配置，永恒应用，无需为各种各样的环境放心和过多的投入，软件版本公布更可控，对盘根错节的编译构建提供了可能；对立的代码提交流程，避免各为其政，更少的代码提交抵触，更有利于团队、团队之间高效的合作；对立的制品治理更不便测试、部署工作的开展。
- 升高产品交付危险
通过机器 + 代码的模式代替更多人工劳动，实现高度自动化，让开发和运维人员的从纠缠不清的泥淖中解放出来，不再为互相推卸责任而节约更多的工夫。
通过编辑检测保障代码不呈现低级的编译构建谬误；通过品质监控保障代码无验证的 bug、破绽；通过部署制品包测试验证制品能失常部署、失常运行；通过触发自动化脚本测试保障软件的逻辑正确性，从而极洼地保障了骨干分支的代码品质，极大地缩小了因人为因素导致的公布事变。即使软件交付失败，也能够通过版本回退，因为公布的新个性波及的范畴较小，也能够疾速修复已升高交付危险。
- 推动并促成 DevOps 落地
DevOps 是 CI/CD 思维的延长，CI/CD 则是 DevOps 的技术外围，如果没有 CI/CD，DevOps 是没有任何意义的。所以说 DevOps 是以 CI/CD 为根底来优化程序的开发、测试、运维等各个不同环节。
尽管 DevOps 更多是在企业数字化转型过程中产生的架构变更时被提起，但 CI/CD pipeline 依然是 DevOps 胜利的要害，并帮忙应用程序更好更快地交付。这是企业从手动、单机交付到自动化、现代化利用交付的外围业务流程。
CI/CD pipeline 是 DevOps 的要害，因为它打消了 DevOps 过程中各种摩擦，从而使得迭代更为迅速，更快地进入生产阶段。DevOps 背地的推动力是 CI/CD 管道（pipeline），凭借 CI/CD pipeline 的凝聚力量，率领软件开发和交付过程迈向现代化。它旨在在团队之间搭起一座桥梁并帮忙团队成员清晰看到软件输入给客户的蓝图。
DevOps 侧重于文化，而 CI/CD 则侧重于必须的过程和工具，这些过程和工具能够帮忙团队适应一直变动的文化。
二、见龙在田
2.1 CI/CD 如何落地
企业推广 DevOps 不是欲速不达的事件，也不是全副的利用零碎都适宜构建继续集成。企业须要依据本人的理论状况组建专门的专项团队，抉择适合的畛域，逐渐发展构建 CI/CD 流动。
《DevOps 实际指南》一书中，陈说了 5 个方面：
- 抉择适合的价值流作为切入点。企业包含绿地我的项目和棕地我的项目，绿地我的项目次要指一些试点 DevOps 的我的项目，棕地我的项目指的是企业运行了很多年的零碎。从理论的专项教训来看，须要疾速适应市场变动的软件，更适宜作为突破点首先发展 CI/CD 试点我的项目。获取成功经验后，可逐渐发展外围零碎的 CI/CD。
- 了解、可视化和使用价值流。应用看板、技术工具将了解选定的价值流，并进行可视化。
- 组建专门的转型团队。无论是 DevOps 实际指南还是从实践经验来看，组建专门的转型团队使得企业进行 CI/CD 落地成功率更高。
- 用工具强化预期行为。应用适合的工具进行 CI/CD，固化流程和行为。
- 将运维融入开发团队。CI/CD 并不只是开发团队的事件，运维团队独特合作同样重要。
2.1.1 CI/CD 过程体系
在企业数字化转型的趋势下，DevOps 作为数字化企业架构的重要支柱之一，是企业数字化经营体验的要害使能因素。同时，DevOps 逐步演进为软件工程的思维框架，旨在交融人员、流程与工具疾速继续地向用户交付软件价值。
继续集成 / 继续交付（CI/CD，Continuous Integration/Continuous Deployment）在 DevOps 理念中具备支柱性位置，因此 CI/CD 流水线至关重要，将实现应用程序的构建、测试、部署与公布等自动化，晋升软件交付的效率与品质。
CI/CD 如何落地呢？
从上图 CI/CD 过程体系中能够看出 CI/CD 处于需要与打算和技术经营的两头地位。CI/CD 过程体系分为配置管理、构建与继续集成、测试治理、代码治理、数据管理、环境治理和公布治理 7 局部。
这七局部如何治理执行呢？看看其余企业在这方面是如何做的。
2.1.2 企业 CI/CD 工具
咱们收集并统计了各大行和网易的 DevOps 工具，发现：一些重要的根底工具基本相同，在自主掌控的策略布局下，越来越多自研的个性化工具也涌现了进去，从图中能够看出 CI/CD 局部工具的抉择：
- 代码治理大部分企业抉择了 Git。
- 主动构建无一例外都应用 Jenkins。
- 镜像工具绝大部分都是 Docker。
- 自动化测试工具中，JUnit 和 JMeter 应用程度较高。
- 制品治理，Artifactory 应用比拟多。
- 主动部署，用 K8s 则占据少数。
网易 CI/CD 工具
重点介绍网易在 CI/CD 方面是如何施行的。
与绝大多数互联网公司一样，网易外部各业务方的继续集成也大都是由研发团队的 QA 负责的，CI 工具抉择了比拟罕用的 Jenkins，同时在流水线的上下游整合了其它的支流 CI 工具。整个流水线平台依靠于 Kubernetes，基于 K8s 的 CRD（自定义资源）从新设计了流水线下层模型，并通过 Operator 驱动流水线执行过程。
当流水线触发一次执行时，会产生一个 PipelineRun 对象，Operator 依据对应的流水线事后定义好的阶段生成对应的 Job，而后通过 Jenkins 的 API 触发 Job 执行。Job 执行实现后，通过 Webhook 回调下层服务接口，将状态回写到 PipelineRun 中，而后触发下一个阶段的执行。
继续集成工具比照
继续集成工具的选型。
图中列出了当初比拟风行的继续集成工具 Jenkins、Gitlab CI、CircleCI、Travis CI 的比照。
次要区别在于 Jenkins、Gitlab CI 收费，但须要专用服务器，而 CircleCI、Travis CI 是商业的，但无需专用服务器。
2.2 继续集成常见的施行问题和反模式
2.2.1 继续集成常见的施行问题
继续集成常见的施行问题有 3 大类：
- 工程师的开发习惯。在没有进行继续集成实际之前，工程师习惯于长时间不与其他人的代码进行集成，到了最初集中联调，甚至马上要进入提测阶段时，才提交代码。很难达到小步提交、代码残缺、不影响已有性能等继续集成的最佳状态。强调开发品质和品质打磨周期的继续缩短是影响工程师习惯的动手点。
- 熟视无睹的扫描问题。继续集成的一个重要工作就是“可能疾速验证以后构建产物的品质”，打包测试、代码标准扫描、代码品质检测绝对投入老本比拟低、执行老本不高，容易施行。但扫描的后果常会被忽视。
- 自动化测试用例的不足。自动化测试的益处不必细说，但目前大部分自动化测试用例仍旧是由人编写的代码，须要稳固且正确的执行，谬误的反馈后果（如随机失败）很容易产生误导、浪费时间。
(参考资料：乔梁老师的《继续交付 2.0》)
2.2.2 影响继续集成的常见反模式
当短少教训的团队试图采纳 CI 时，很可能谬误地采纳反模式，这最终导致他们岂但没有取得预期的益处，反而遇到一大堆麻烦。可怜的是，在这种状况下，团队经常将麻烦归罪于 CI 自身。
11 种常见反模式：
- 提交不够频繁导致集成提早。在应用 CI 的我的项目中，倡议开发人员每天至多提交一次代码，最好每天屡次检入代码。
- 构建失败导致团队无奈继续执行其余工作。避免构建失败的有用技术之一是在将代码提交到主线之前集成其余开发人员的批改并运行公有构建，包含在本地或 CI 服务器上的公有流水线。
- 克制反馈妨碍采取纠正措施。在设置 CI 零碎时，有时团队会认为接管电子邮件等同于垃圾邮件，因而会抉择不接管任何告诉。然而，如果没有从构建中收到反馈，就无奈采取任何措施。通过施展创造力，团队能够利用各种反馈机制，使成员不会疏忽构建状态音讯。
- 垃圾反馈导致反馈音讯被疏忽。少数 CI 服务器能够对邮件告诉进行配置，比方无论构建胜利与否，技术主管总是会收到电子邮件，仅在构建失败时项目经理才会收到电子邮件，并且最近更改代码的开发人员也会收到电子邮件。
- 机器迟缓导致反馈提早。通过放慢构建速度而节俭的工夫可帮忙开发团队取得更快和更无效的反馈。
- 收缩的构建升高反馈速度。如果发现构建过程耗时太长，而且曾经实现了其余改良技术（比方改用更快的机器）并优化了测试执行工夫，那么就有必要思考创立所谓的构建管道（build pipeline）。构建管道的用处是异步地执行长时间运行的过程，这样开发人员签入代码之后，不须要长时间期待反馈。
- 等到一天完结时才提交批改，造成瓶颈提交。通过频繁提交，就会领有更小但更频繁的集成构建，而且在呈现构建谬误时，谬误会较少，而且更容易修复。
- 构建中只蕴含很少的主动过程，构建总是胜利但造成继续漠视和集成提早问题。可能须要思考创立一个构建管道，在运行完首次提交构建之后再运行那些比较慢的过程，这样做可能失去更快的反馈，并提供更灵便的软件验证机制。
- 应用定时构建而非提交触发构建，不利于构建修复。将定时构建改成更加频繁的操作很容易，只有正确地配置一台继续集成服务器即可。
- 置信代码在本人的机器上失常，只能在其余环境中发现问题。为了克服这种意识，继续集成系统不应该有任何先入为主的想法（在正当的限度内）。要缩小这种想当然的想法并不难，只有删除特定于平台的束缚并将它们变成可替换的，例如通过属性文件进行设置。
- 未革除旧的构建制品，造成环境凌乱，引起误判和漏判。在进行任何相干的构建流动之前要将环境置于已知状态，这一点再怎么强调也不过分。清理部署环境最大的益处就是提供了更快排除问题故障的路径。为能够比拟的环境制作基准，就能对它们一一进行比拟，所以在环境转换之间呈现问题时，就能更快地进行修补。
（源自 https://www.ibm.com/developer…）
以上提到许多反模式，如果可能防止某些反模式，就能享受到更多继续集成的益处。开发团队应用其中一些实际是有其理由的，只是这些实际会造成反模式。例如，有时运行定时构建是适合的。反模式从实质上讲并不是坏实际，只是在某些状况下，它们并不是良好的办法。
2.3 继续集成和继续部署实际
这是 Martin Fowler 在 2006 年名为继续集成的文章中总结的 11 条继续集成实际，当初已成为所有施行继续集成的团队都认可的根底实际。所有实际的目标都是为了缩小代码抵触产生的可能性及代码合并的工作量，获取疾速、实在的反馈，以及通过自动化缩小人工出错的可能。
- 保护繁多源码库。
- 自动化构建。
- 让构建自动测试。
- 每人每天向骨干提交代码。
- 每次提交都触发集成服务器构建骨干。
- 失败构建应被立刻修复。
- 放弃疾速构建。
- 在类生产环境中测试。
- 所有人都能轻松获取最新的可执行文件。
- 所有人都能看到正在产生什么。
- 自动化部署。
（源自 https://martinfowler.com/arti…）
以下实际是对开发团队更全面的要求，是实现继续构建必不可少的：
- 提交前在本地或继续集成服务器运行所有测试。一直的增量提交代码尽管是件轻量级的事儿，却也是一件庄重的事，须要在本地进行欠缺的自动化测试，尽量确保服务器构建的胜利，不至于影响其他人的及时提交。
- 提交测试通过后再持续工作。提交代码触发构建后，开发人员应该监督这个构建过程，直到构建胜利，构建完结之前，不应该被散会或其余事烦扰。
- 构建失败后不要提交新代码。继续集成的第一禁忌就是构建曾经失败了，还向版本控制库中提交新代码。如果某人提交代码后构建失败了，他就是修复构建的最佳人选，应尽快找出失败的起因并修复构建。这也是强调上一节提到的“失败构建应被立刻修复”。
- 上班之前构建必须处于胜利状态。这是协同研发应该具备的根本集体素质，不让本人的工作成为团队的阻塞。
- 时刻筹备着回滚到前一个版本。如果某次提交失败了，最重要的是尽快让所有再次失常运行，当无奈疾速修复问题，应该将它回滚到上一个版本。
- 在回滚之前要规定一个修复工夫。对于是否应该期待持续问题定位，还是回滚版本，项目组之间应该有个约定，20 分钟或是更久，须要有个工夫界定。
- “不要将失败的测试正文掉”。自动化测试是为了裸露问题，疾速反馈，正文掉失败的测试就像自欺欺人，但有时的确会有开发人员这样做。
- “为本人导致的问题负责”。这看似是一个责任心的问题，然而本人挖的坑本人填，一方面填坑效率更高，另一方面也能够减少挖坑的老本，从根本上缩小坑的产生。
- “测试驱动开发”。这也是 XP 的一个外围实际，通过测试来推动整个开发的进行，有助于编写简洁可用和高质量的代码，并减速开发过程。
（参考华为云《DevOps 职业认证训练营》课程）
2.4 企业采纳的 CI/CD 实际
正如前文所言，团队应用一些实际是有其理由的，在引入实际时，团队理解其优缺点，抉择适宜团队的实际，防止反模式，这样就能享受到更多继续集成 / 继续部署的益处。
上面介绍一些企业的 CI/CD 实际。
2.4.1 谷歌繁多代码库和骨干开发
繁多代码库：2016 年《ACM 通信》有一篇论文《为什么 Google 要把几十亿行代码放在一个库？》，作者是谷歌基础设施小组的工程师。作者具体讲述了 Google 的代码为什么全副放在一个库外面。
过后这个代码仓库蕴含 10 亿个文件，3500 万次提交记录，大小为 86TB，用户达到几万人。工作日每秒有 50 万次申请，顶峰时 80 万次，大部分来自主动构建和测试零碎。谷歌 90% 以上的代码，放在 Piper 里。对于那些开源的、须要内部合作的我的项目，代码放在 Git，次要是 Android 我的项目和 Chrome 我的项目。Git 的特点是，所有历史记录都会复制到用户的本地机器，所以不适宜大型项目，必须拆分成更小的库。
骨干开发：因为不采纳“分支开发”，谷歌引入新性能，个别在代码中应用开关管制。这防止了另起一个分支，也使得通过配置切换性能变得容易，一旦新性能产生故障，很容易切换回旧性能。等到新性能稳固，再彻底删除旧代码。
（源自 http://m.cacm.acm.org/magazin…）
2.4.2 华为云个性分支、骨干公布
（内容起源 - 华为云《DevOps 职业认证训练营》课程）
华为云实际如图所示，3 种不同角色的我的项目成员分工协作，保障最终合入主干分支的代码品质。
- 开发在实现代码开发和自验证后，发动代码入库申请，别离抉择评审人员和提交者。
- IT 工具触发门禁查看，门禁查看胜利后，告诉评审人员检视。
- 评审人员收到代码检视告诉后，对代码进行检视并提出代码检视意见。
- 开发收到检视意见后，欠缺代码并闭环检视意见，更新代码入库申请。
（内容起源 - 华为云《DevOps 职业认证训练营》课程）
从上图能够看出：
- 分支规定：Feature 分支向 Master 分支合入。
- 从 Master 分支拉取 Feature 分支。
- 依据版本节奏，Feature 分支向 Master 合入公布版本代码。
2.4.3 华为代码查看
（内容起源 - 华为云《DevOps 职业认证训练营》课程）
华为在代码查看方面的一些实际：
- 代码查看曾经被集成到华为的软件生命周期当中，作为其中的重要一环存在；
- 不通过代码查看就无奈合入代码仓库；
- 在集体级和版本级的流水线当中，都会被主动触发执行；
- 通过多年的开发教训，现已积攒了大量的代码查看规定，并将这些教训能力提供至华为云 DevCloud 平台的 CodeCheck 当中。
（内容起源 - 华为云《DevOps 职业认证训练营》课程）
动态代码查看前通过单元测试、黑盒测试、代码审查等办法进行查看，这样做会有一些资源上的束缚，比方：
- 人力上的束缚：对测试人员的能力要求较高, 人员、精力的投入带来的回报是否能够满足冀望。
- 工夫无限：产品疾速迭代，公布周期短，集体工夫无限。
- 空间无限：测试用例查看范畴小，测试覆盖率不够大。
- 精力有限：人类大脑精力等无限。
动态代码查看后克服束缚：
- 在不运行程序的前提下找出问题。
- 不依赖于好的测试用例。
- 不单单测试单个代码片段全门路笼罩。
- 不须要晓得软件到底想干什么。
2.4.4 华为云 iLearning 蓝绿部署
华为云 iLearning 在后期的麻利转型中曾经建设了基于 Scrum 流程的麻利交付，两周一个迭代进行交付。然而如果每两周都要将产品部署到生产环境交付给用户，团队十分苦楚，因为每两周就须要周末加班熬夜进行部署，并赶在用户下班应用之前验证部署后果。
因而即使团队能够两周交付一些个性，也很难每两周都将其公布给用户，难以进一步缩短交付周期，对业务的响应能力不够快。
要进一步缩短交付周期，就必须做到生产环境部署公布的不停机，既要对用户无感知不影响用户体验，同时也要保障部署是胜利和平安的。华为引入了“蓝绿部署”（在华为也称为“双活”）的实际胜利解决这个问题。
蓝绿部署应用两套统一的环境，一套在线提供服务，一套闲置筹备用于下个版本的部署。有时也将两套环境都在线提供服务，可互为容灾，但留神这种模式下在部署过程中零碎的容量会有稳定，应防止在零碎负载峰值时进行。iLearning 采纳的是后一种形式。
（内容起源 - 华为云《DevOps 职业认证训练营》课程）
2.4.5 华为云 DevCloud 灰度公布
（内容起源 - 华为云《DevOps 职业认证训练营》课程）
整个华为云 DevCloud 的产品中采取的灰度公布服务次要特色有 3 个:
- 依据用户画像，精准分层用户，灰度逐渐递进，全副保障可能检测到所有的用户分群。
- 提供了多种灰度策略，如个性开关、AB 测试、在线验收测试、友好用户测试等模式。
- 精准把控灰度批次比例，借助 SLB 服务，严格依照 1%、9%、45%、45% 的审慎比例逐渐放大灰度群体。
2.4.6 公布模式及比照
说到灰度公布，咱们来看 4 种公布模式及其比照。
单服务器组 - 单体公布：机器资源比拟缓和，不像当初云计算、虚拟化、容器技术这么发达，利用机器根本是事后动态调配好的，原来利用 A 在这 n 台机器上，下次降级公布的利用 a 也在这 n 台机器上，所以成为单服务器组公布形式。
单体公布模式比拟传统，公布时先把服务停掉，而后部署新版本再启动服务，这种形式会引入服务中断。
单服务器的金丝雀公布模式是对单体公布模式的一种改良。就是把应用程序的某个新版本部署到生产环境的局部服务器中，从而疾速失去反馈。就像通过金丝雀发现矿井是否有氧气一样，金丝雀公布能够疾速而无效地发现软件新版本存在的问题。
单服务器组 - 滚动公布：在金丝雀公布根底上的进一步优化改良，这是一种自动化程度较高的公布形式，用户体验比拟平滑，是目前成熟型技术组织所采纳的支流公布形式。先公布一台，再公布一台，逐渐公布的形式。
随着云计算和虚拟化技术的成熟，特地是容器等轻量级虚拟化技术的引入，计算资源受限和申请迟缓问题曾经逐渐解决，能够做到弹性按需分配。为一次公布调配两组服务器，一组运行现有的 V1 老版本，一组运行待上线的 V2 新版本，再通过 LB 切换流量形式实现公布，这就是所谓的双服务器组公布形式。
双服务器组 - 蓝绿公布：蓝绿公布仅实用于双服务器组公布，一种简略优化公布形式。
4 种公布模式的比照：
- 单体公布模式：长处是简略成本低，毛病是服务中断用户受影响，出了问题回退也慢。实用于开发测试环境、非关键利用（用户影响面小）、初创公司什么都缺、找夜深人静用户访问量小的工夫干，对于产生中断不敏感的业务零碎。
- 金丝雀公布：长处是用户体验影响小，金丝雀公布过程呈现问题只影响大量用户，毛病是公布自动化水平不够，公布期间可引发服务中断。实用于：对新版本性能或性能不足足够信念、用户体验要求较高的网站业务场景、不足足够的自动化公布工具研发能力。
- 滚动公布：长处是用户体验影响小，体验较平滑，毛病是公布和回退工夫比拟迟缓公布工具比较复杂，Loadbalance 须要平滑的流量摘除和拉入能力。实用于用户体验不能中断的网站业务场景，并且有肯定的简单公布工具研发能力。
- 蓝绿公布：长处是降级切换和回退速度十分快，毛病为切换是全量的，如果 V2 版本有问题，则对用户体验有间接影响，须要两倍机器资源。实用于对用户体验有肯定容忍度的场景；机器资源有充裕或能够按需分配（AWS 云，或自建容器云），暂不具备简单滚动公布工具研发能力。
2.4.7 企业自建 or 外购工具
DevOps 落地过程中 CI/CD 工具选型是自建还是外购，跟企业本身相干，没有标准答案，只有最适宜本人的计划。联合企业自身的 IT 战略目标和 IT 架构来抉择适宜本人的工具，搭建什么样的流水线，达到什么样的成熟度。
打个比方：大企业才会建“房地产”，以满足企业规模体量下的定制化需要，个别基础设施建设复杂度高，对工夫、资金、能力有肯定的要求。中小企业、非 IT 企业只有找套房子就能够了，这类客户对研发效力晋升有诉求，但又对价格敏感，租房模式 - 公共云是很好的承接模式；对平安有很高的要求基本上只能抉择公有部署模式。待能力倒退到肯定阶段，无奈满足定制化需要时，再放松机会尝试自研，晋升组织能力。
如果自建或外购抉择不对，可能会毁坏企业无效的扩大能力，并损坏股东价值。人们对自建有一种天生的偏好，如自主掌控等，强烈建议坚定拥护这种偏好。以老本为核心重点升高整体老本，因为不聚焦可能失去策略机会；以策略为核心重点对标公司长期需要，但不思考总成本。两种办法联合集成长处躲避毛病个别是最好的抉择。
2.4.8 企业对 CI/CD 工具的抉择
（图片起源 - 中国 DevOps 现状调查报告（2020））
据中国通信研究院《2020 年 DevOps 现状调查报告》，如图能够看出采纳自研 / 对开源工具进行二次开发的 DevOps 平台类工具成为企业的首选。
超过三成的企业抉择应用自研或采纳开源工具进行二次开发的一体化平台，占比为 33.80%；其余抉择占比超过 10% 的 DevOps 平台类工具为阿里云效（20.51%）、腾讯蓝鲸（14.96%）、华为云 DevCloud（12.81%）以及微软 TFS/AzureDevOps（12.27%）。
（图片起源 - 中国 DevOps 现状调查报告（2020））
报告还提到，超过八成的受访企业已上云，其中，超过 30%(30.79%)的企业抉择混合云；将近 30%(29.49%)的企业抉择公有云；超过 20%(20.24%)的企业抉择私有云。
2.5 云原生下的 CI/CD
介绍几个大厂基于云的 DevOps 平台类工具。
2.5.1 华为云 DevCloud
华为云汇合业界先进理念和华为 30 年研发教训，总结出一套可操作可落地的端到端一站式开发方法论和工具链——华为云 HE2E DevOps 框架。
（图片起源 - 华为云 DevCloud）
首先，它是端到端的 DevOps 开发框架，包含从规划设计到迭代开发到继续测试再到继续交付的全过程。仅仅只做好工程端不足以撑持整个业务，肯定要延长并回归到业务侧，实现端到端的闭环。
其次，它的整个过程交融了大量以可信为目标的伎俩，去撑持整个 DevOps 流程。
华为云 HE2E DevOps 自 2018 年公布 1.0 版本，至今倒退为 2.0 版本，整体分为 6 大阶段：布局与设计、开发与集成、测试与反馈、平安与审计、部署与公布、运维与监控。关注七大畛域，继续优化交付粒度，放慢交付速度，晋升交付品质。
云原生架构与 DevOps 的落地与转型，须要从团队模型、分支模型、测试模型、技术架构、部署模型、基础设施、数据库模型等 7 大畛域进行相应的匹配。
（图片起源 - 华为云 DevCloud）
上图以公布频度为抓手，从 100 天公布一次，逐渐的十倍速增长，到 10 天公布一次，在两个阶段点，从七个维度来看，须要匹配与驳回的实际是什么。
这是一张能力演进地图，能够清晰地看到本人业务以后所须要的公布节奏是怎么，当十倍速地走到下一个节点，方向在哪里，对症下药地进行相应的驳回。
与此同时，这也是一个质变到量变的过程，继续优化交付粒度，放慢交付速度，晋升交付品质。从 100 天公布 1 次，到最初的 1 天公布 100 次，10000 倍的增长，回过头来看，就是一个升维的过程。
2.5.2 腾讯蓝鲸
（图片起源 - 腾讯蓝鲸）
腾讯蓝鲸智云体系由原子平台和通用的一级 SaaS 服务组成，平台包含管控平台、配置平台、作业平台、数据平台、容器治理、PaaS 平台、挪动平台等，通用 SaaS 包含节点治理、规范运维、日志检索、蓝鲸监控、故障自愈等，为各种云（私有云、公有云、混合云）的用户提供不同场景、不同需要的一站式技术经营解决方案。
（图片起源 - 腾讯蓝鲸）
在蓝鲸体系架构中，配置平台位于原子平台层，通过蓝鲸 PaaS 的 ESB 为下层 SaaS 提供笼罩研发经营 CI（继续集成）、CD（继续交付和继续部署）、CO（继续经营）畛域的配置管理能力。
2.5.3 AWS 上的 CI/CD 流程
（图片起源 -AWS）
最上面的 GIT 作为本地环境存储代码，批改代码后 push 到 CodeCommit 中，CodeCommit 是 AWS 提供的一个代码管理器，能够存储或者治理一些代码，部署能够应用 AWS 提供的 CodeDeploy，CodeDeploy 能够去 CodeCommit 拉取代码，而后将这些代码依照既定的流程部署到相应的资源当中，比方部署到 AWS 的 ES2 服务中或者是曾经筹备好的本地环境中，也能够将代码部署到 AWS 的容器服务 ECS 中，还能够部署到无服务器架构 Lambda 环境中。
提到无服务器，顺便介绍一下 Quick Start。
（图片起源 -AWS）
Quick Start 在 Amazon Web Services (AWS) 云上构建了一个无服务器的 CI/CD（继续集成和继续交付）环境，为无服务器应用程序提供了一个适宜大型企业的动静部署管道。Quick Start 应用多种 AWS 服务，使组织内的多个开发团队可能在无服务器应用程序部署上平安高效地进行合作。
2.5.4 微软 Azure
大略在 2005 年微软推出一个叫 Team foundation server 的专门用来做继续集成的服务 / 产品，通过十几年的倒退，当初最新的基于 Team foundation server 衍生进去的产品叫做 Azure DevOps。
（图片起源 -Azure）
图中能够看出微软 Azure 实用于虚拟机、容器、Azure Web 利用等的 CI/CD，此处不一一介绍。
2.6 总结
当你曾经对 CI/CD 有肯定理解后，怎么更好地在组织内落地呢？
- 须要抉择一款或建设一套兼具灵活性和规范性的工具平台。
- 制订适宜本人企业的研发模式，并将其固化下来。
- 研发模式的变更能够利用到已有的团队。
- 通过适当的卡点来管制全局危险。
- 保障交付可见可控可度量，并继续改良企业的 CI/CD 交付流程。
三、神龙摆尾
3.1 CI/CD 的度量
3.1.1 度量评估方法
想要评估 CI/CD 对研发效率晋升有多少，就须要拿数据来谈话，可行的方法是制订一套较为齐备评估的指标、评估方法和评估流程。包含 6 步：
- 第一步：找出一系列可度量的指标，波及到 CI/CD 方方面面，逐步形成度量指标体系；
- 第二步：基于建设的指标体系，评估研发 CI/CD 现状，造成 CI/CD 基线；
- 第三步：依据企业文化、研发现状、我的项目特点制订 CI/CD 落地动作，这是最为要害的一步，肯定要结合实际状况，我的项目须要制订无效的措施；
- 第四步：这一步是将动作逐渐落实，基于从易到难、从重要到主要、从部分到全面实施的步骤实方法。能够单项落地、也能够多项同时落地；
- 第五步：评估改良后的 CI/CD 各项指标，能够基于繁多维度，也能够多维度评估。
- 第六步：比照基线，造成效力晋升后果。
3.1.2 度量指标
为什么须要度量？度量是为了提供较为精确的能力评估；能够作为继续改良、优化的根据；疏导团队向更好的方向倒退。丰盛的度量指标，可能为我的项目管理者提供无关 CI/CD 的各种重要信息，以便于咱们晓得本人处于什么程度。
倡议以继续集成、代码测试和品质、继续部署、继续交付和产品稳定性 5 个方面作为度量的要害指标，提供较为精确的能力评估，和继续改良优化的根据。
1）继续集成
在阐明度量指标之前，须要抉择适合的度量周期和度量维度：
- 度量周期就是度量工夫的长短，能够以天、星期、迭代、甚至是以月为单位。通常在麻利开发模式中能够以一个迭代为单位，如果是传统开发模式能够按天为单位，或者管理人员依据理论状况抉择适合的工夫度量单位。
- 度量维度：在最后阶段，能够抉择从集体或团队维度来评估，CI/CD 较为成熟后，还能够基于我的项目、产品、或者是更大的维度来评估。
这里有一个前提条件，即抉择了适合的代码版本治理分支模型，假如咱们曾经应用了 git-flow 分支模型。
继续集成的度量指标包含：
- 代码提交频率
- 单元测试覆盖率
- MR 合并频率
- 个性公布频率
- 需要交付频率
- 制品构建频率
- 软件交付频率
- 构建胜利频率
- 我的项目构建时长
- 代码品质扫描频率
留神：这里的指标只是从开发到产生可用软件这个阶段的生产效率，其中举荐的度量指标包含代码提交频率、单元测试覆盖率、需要交付频率、构建胜利频率、我的项目构建时长、代码品质扫描频率。
继续集成是 CI/CD 推动的第一步，继续集成和代码库严密相连，是否以代码库为维度呢？这须要依据我的项目的理论状况抉择，通常抉择以我的项目维度，而不是代码库，因为一个我的项目至多波及到一个代码库。
2）继续部署
须要特地阐明的是，这里的继续部署是指构建好的包部署到测试环境、性能测试环境和生产环境。
继续部署的度量指标包含：
- 部署到测试环境的频率和失败频率
- 部署到性能测试环境的频率和失败频率
- 部署到预公布环境的频率和失败频率
- 部署到生产环境的频率和失败的频率
其中部署的频率和失败的频率是很重要的指标，如果条件不容许，至多保障测试环境部署的频率和失败频率这两个指标。部署到生产环境的频率和失败的频率，分理论状况，如果反对自动化部署，能够主动统计，否则须要手动去收集这些数据。
3）代码测试和代码品质
代码测试次要是收集 5 个率，蕴含接口测试、集成测试、功能测试、性能测试、回归测试。
当然功能测试可能比拟难用自动化伎俩实现，须要借助于工具集成来收集这些指标。
代码品质次要是为了度量代码在部署到生产环境上之前的代码品质的评估。重点监测重大破绽、重大 bug 和整体代码品质剖析的状况。其中代码品质检测通过率须要团队外部制订一套规范，通常为 bug、破绽、坏滋味三品种别的问题。
代码又分为五大类（阻断、重大、次要、主要、提醒），依据生产须要，为不同品种的问题设置不同的品质要求。比方容许每次产生一些 bug，但不能含有阻断、重大、次要级别的，而破绽和坏滋味则不能含有阻断和重大级别的。
4）产品稳定性
产品稳定性是一个要害度量指标，如果这个无奈保障，那后期所做工作就是白费劲，通常在生产环境部署时尤其重要，尽量保障零失误，即便达不到这一点，也要做到让零碎可能疾速恢复正常。
产品稳定性的度量指标包含：
- 变更失败率，软件版本更新到部署环境失败的频率。
- 问题均匀复原时长是指呈现线上问题时，零碎恢复正常所用的时长。
- 产品上线成功率，指产品级别的上线胜利几率，和变更失败率是一个蕴含关系（一对多），这个指标更为简单。
- 上线时长，是指从部署到失常运行的工夫距离，上线工夫过长，可能会影响用户的应用体验，因而也是很重要的一个指标。
5）继续交付
继续交付这一块的度量指标，基本上都是从更高的维度，基于产品的视角，在推动的后期，CI/CD 比拟难评估，能够疏忽，在后面的根底工作都欠缺当前，再施行。
- 业务价值交付的频率。业务需要价值是否达到了用户的预期，这个指标波及到的面比拟广，决定因素比拟多，仅供参考。
- 产品个性上线的频率。如果是单个我的项目，度量的维度是我的项目，如果波及到多个我的项目，度量的维度应该是基于产品的。
- 主动公布的应用软件数量。通过自动化构建而成的软件数量。
- 单个应用软件无效公布的频率。单个软件无效公布的频率，更多的是从无效的产品角度登程去思考的。
3.1.3 度量办法 - 继续改良措施
继续改良措施包含：
- 梳理研发流程：梳理研发、品质治理、测试、运维全流程。
- 体系化：将软件生产实现标准化和数字化。
- 规范化：制订流程标准及规范。
- 自动化：让更多的流程尽可能的自动化。
1）梳理研发流程
看研发流程中绝对于 CI/CD 环节，哪些流程可能优化、怎么优化。一方面是优化流程、办法，另一方面是采纳自动化工具来勾销人工操作。
研发流程次要包含：
- 需要治理：客户业务需要转化和需要正当合成，优化需要拆分，尽量拆分为具备业务价值的需要，在麻利开发流程中需要拆分又称为用户故事转化。
- 设计治理：又称为业务需要设计治理，蕴含需要设计文档、接口设计、需要原型设计等，和需要拆分密切相关。
- 配置管理：创立一个我的项目后，须要各种配置（比方创立代码库、制品库、继续集成、继续部署环境、测试环境等）。
- 开发治理：次要包含后面各阶段的文档评审，需要廓清、代码分支策略、项目风险治理、代码品质治理、继续集成、继续部署等。
- 测试治理：通常蕴含接口测试、回归测试、测试用例治理、测试环境治理等。
- 公布治理：公布版本号治理，怎么去辨别长期版本、版本晋升、m 版本、rc、release 等。
- 部署治理：行将待发布的软件包部署到某个环境中（测试环境、预公布环境或者是生产环境）。
需要治理和设计治理改良是整个流程优化的先决条件，否则后续的流程都不可能达到预期的成果。
能够通过规范化优化改良的流程有：开发治理、公布治理、测试治理，还须要借助于规范化治理来晋升效率。
通过自动化优化改良的流程有：配置管理、开发治理、测试治理、部署治理。
2）布局化
规范化次要的作用是为了有法可依，有迹可循，实现 CI/CD 的度量衡对立，更有利于改良和工作推动。
- 分支模型标准：是所有规范化的前提，须要抉择适合的代码分支模型，定义出开发分支、稳固分支、公布分支，以防止整合组内成员代码时呈现凌乱，继续集成时便于对立格调，同时防止评估需要交付频率时横七竖八等多个问题。
- 继续集成标准：定义用什么样的继续集成工具，在什么中央做品质检测，用什么分支上的代码做什么事，用什么分支上代码构建测试包、公布包，部署包，是制作成镜像包还是 war 包等等一系列问题。
- 继续部署标准：部署采纳什么形式，什么样的包能部署到测试环境，包部署到生产环境之前须要通过哪些环节的验证等等
- 测试治理标准：测试治理次要蕴含测试环境治理、冒烟测试流程、零碎测试流程、缺点治理流程、验收测试流程等，都须要制订适合的标准。
3）自动化
自动化一方面能够将耗时较长、须要人工实现的操作实现自动化；另一方面，能够通过并行的形式将原来须要串行的工作来极大地缩短工作工夫，同时将因为人工容易出错的几率降为 0。
将每一个流程造成模板，形象成通用能力，而后将各项流程实现自动化，最初整合到继续集成中。配置管理、代码集成、品质检测、测试、安装包部署、版本公布等操作都能够实现自动化。
4）体系化
把最根底的指标收集齐全之后，再从人、我的项目、组织甚至更大的维度，整合这些指标，造成一套齐备的度量体系。从点线面登程度量：
- 点：各项指标在某个工夫点度量个体、团队在这个点的综合能力。
- 线：在一段时间里，度量个体、团队的工作状态和发展趋势。
- 面：梳理各项指标，以个体、团队、组织造成比照，实现劣势。
除了制订度量体系，还有一个比拟重要的工作要做，就是将这些指标造成自动化采集的能力，目前除了商业的软件做到了这点，开源的软件并不多，然而不难做到。
3.1.4 造成度量剖析后果
最终将这些剖析后果以报表的模式展现进去，咱们便晓得哪些地方存在有余，还须要优化，哪些地方做得很好，哪些团队做得不错，后续能够拿来借鉴。
3.1.5 企业案例分享 –Capital One
上面分享 Capital One 在 2015 年、2016 年无关 CI/CD 方面的案例，这个案例比较简单，但在无关 CI/CD 度量方面，外延丰盛。
- 度量的指标都是抉择比拟易于评估、计算的度量。比方代码提交频率、集成频率、自动化频率、单元测试等。
- 度量的指标随着工夫的推动产生了变动，一开始是研发效力的指标，前面则变成了产品交付视角的指标。
- 度量次要偏向于研发生产效率方面的指标。
- 从可行性上来说，CI/CD 是逐渐分阶段施行的，而不是欲速不达的。
- 抉择度量指标不是越多越好，而是抉择适宜本身研发须要和理论状况的。
- 这个案例也给咱们提供了一种抉择度量指标的思路。
3.2 CI/CD 的瞻望
3.2.1 研发一体化 (DevOps) 能力成熟度模型
后面分享了继续集成和交付的概念、施行办法、工具及度量。企业能够利用 DevOps 能力成熟度评估一直晋升继续集成和交付的管理水平和技术水平。
（图片起源：《研发经营一体化（DevOps）能力成熟度模型》）
《研发经营一体化（DevOps）能力成熟度模型》由中国信息通信研究院牵头，联结通信及金融等行业顶尖企事业单位专家独特制订，规范评估体系次要包含研发经营一体化过程、利用设计、平安及风险管理、评估办法、零碎和工具畛域的评估 5 大方面。研发经营一体化过程包含了麻利开发、继续交付、技术经营 3 局部。目前继续交付作为其中的一部分曾经能够发展能力成熟度评估。
研发一体化 (DevOps) 能力成熟度模型：继续交付
（图片起源：《研发经营一体化（DevOps）能力成熟度模型》）
继续交付包含了如图所示的 7 个畛域。每个畛域有不同的子域，每个子域包含了不同的能力项。能力项的成熟度分为 5 个级别。
如最初一个能力域“度量与反馈”包含了“度量指标”和“度量驱动改良”两个子域。度量指标包含了“度量指标定义”、“度量指标类型”、“度量数据管理”和“度量指标更新”4 个能力项。
度量指标的 4 个能力项的第一级别衡量标准是：
- 度量指标定义：在继续交付局部阶段定义度量指标。
- 度量指标类型：无。
- 度量数据管理：度量数据是临时性的。
- 度量指标更新：无。
第五级的衡量标准为：
- 度量指标定义：继续优化的度量指标，团队自我驱动继续改良。
- 度量指标类型：建设度量指标的无效反馈机制，并继续优化度量指标分类。
- 度量数据管理：对历史度量数据进行无效的开掘剖析。
- 度量指标更新：度量指标可基于大数据分析和人工智能自动识别和举荐动静调整指标优先级。
DevOps 能力成熟度模型为 CI/CD 能力成熟度的倒退阶梯提供了领导方向。
3.2.2 将来瞻望
（图片起源：高效开发运维、企业级 AIOps 施行倡议）
1）DevOps：核心理念，万物皆由此生
通过以上介绍，能够看到 DevOps 倒退的根底思维和核心理念是把整个开发流程的界线买通，产品深刻到研发的外部，研发能够把信息疾速反馈给产品，开发和运维或者 QA 和运维之间的界线也须要买通，造成“开发团队与经营团队之间更具协作性、更高效的关系”。
尽管 DevOps 正被宽泛采纳，但要扭转某些企业领导者积重难返的古老思维及行为是不容易的。此外，DevOps 工具链目前绝对还不太成熟，特地是一些针对特定工作的脚本和自动化工具。因为开始的重点是激励开发和运维思维形式的转变，他们当初仍须要成熟的工具，来防止手动切换和过多的自定义脚本造成的低效率。
2）SRE：DevOps 在运维畛域的最佳实际
SRE，Site Reliability Engineer，作为 Google 最早提出，又经由 Google 倒退欠缺的一个簇新概念，是在运维模式上的全新摸索，也是 DevOps 思维在运维方面的真正实际。SRE 代表了一套先进的、残缺的运维体系，已成为一个涵盖运维理念、思路、组织架构和具体实际的残缺体系。
3）容器技术 Docker：DevOps 必经之路
近两年来如日中天的 Docker 就是实现 DevOps 最合适的工具之一。从物理机时代到第一代云，或者说 OpenStack 时代，再到当初的容器时代，一是工夫老本升高了很多，二是底层越来越降落。
4）AIOps：DevOps 的进化方向
近年来，人工智能技术备受关注，将 AI 引入 IT 运维畛域，AIOps 的概念由此而生。AIOps 自从 Gartner 于 2016 年提出至今已有一段时间，AIOps，艰深地讲，是对规定的 AI 化，行将人工总结运维规定的过程变为主动学习的过程。
具体而言，是对平时运维工作中长时间积攒造成的自动化运维和监控等能力，将其规定配置局部，进行自学习的“去规则化”革新，最终达到终极目标：“有 AI 调度中枢治理的，品质、老本、效率三者兼顾的无人值守运维，力争所经营零碎的综合收益最大化”。利用大数据、机器学习和其余剖析技术，通过预防预测、个性化和动态分析，间接和间接加强 IT 业务的相干技术能力，实现所保护产品或服务的更高质量、正当老本及高效撑持。
领导准则：书同文，统一的运维语言；车同轨，统一运维“办法”；行同伦，统一的运维模式。
IT 平台的复杂度和集成度将持续以指数级增长，而人的能力绝对放弃不变，从而变成制约业务倒退的外在起因，而 AIOps 能够真正晋升运维效率，晋升洞察力，让运维人员关注真正须要关注的事件 - 用户满意度。
5）ChatOps：DevOps 的终极目标
ChatOps 以聊天室，即沟通平台为核心，通过一系列的机器人去对接后盾的各种服务，工作人员只须要在聊天窗口中与机器人对话，即可与后盾服务进行交互，整个工作的开展就像是使唤一个智能助手那样简略天然。即“聊着天就把事件办了”。
ChatOps、AIOps 中的 CI/CD
从较高层面讲，可将聊天机器人划分为机器人性能（“大脑”）和一组周边要求（“主体”）。大脑包含畛域辨认组件，其中包含机器人逻辑和机器学习性能。其余组件不具备畛域常识，用于解决 CI/CD、质量保证和平安等非功能性要求。
继续机器人部署能够间接从 IDE 或命令行（例如 Azure CLI）部署机器人逻辑。然而，随着机器人的日趋成熟，最好是依据设置继续部署一文中所述，应用整合了 CI/CD 解决方案（例如 Azure DevOps）的继续部署过程。这样，就能够很好地缓解在准生产环境中测试机器人新性能和修复措施时存在的抵触。另外，一种不错的想法是创立多个部署环境，通常至多应该创立过渡和生产环境。Azure DevOps 反对这种办法。
但凡能让咱们的生存变得更美妙、更简略、更不便的技术，肯定会具备弱小的生命力，也必然会成为发展趋势。CI/CD 作为 DevOps 最外围的内容，为以上各方面的倒退提供源源不断的能源。
参考资料：
- 李帅 DevOps DevOps 技术说
- https://www.kubernetes.org.cn… 社区首页 >DevOps> 为什么须要 CI/CD
- DevOpsDsys 2017 – 北京站
- Amol Muratkar.What is DevOps Lifecycle and How to Manage Yours [OL].(2020-03-26)
- 《CI/CD: The driving force behind DevOps》https://sdtimes.com/cicd/cicd…
- 《CI/CD：DevOps 背地的推动力》https://www.oschina.net/trans…
- 《DevOps 实际指南》
- 网易、华为、腾讯、AWS、Azure CI/CD 实际
- 乔梁老师的《继续交付 2.0》
- https://www.ibm.com/developer…
- 《Continuous Integration》https://martinfowler.com/arti…
- 华为云《DevOps 职业认证训练营》课程
- http://m.cacm.acm.org/magazin…
- 中国 DevOps 现状调查报告（2020）
- 《研发经营一体化（DevOps）能力成熟度模型》
- 高效开发运维、企业级 AIOps 施行倡议
内容起源：DevOps 案例深度钻研第 6 期——CI/CD 实际钻研战队
本案例内容贡献者：陈裕华、崔龙波、高亚军、何中山、刘晓玲、秦榕蓉、王君
