【分享实录】降龙十八掌—CI/CD持续集成持续部署 | IDCF DevOps案例研究

很高兴参加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实践研究战队
本案例内容贡献者：陈裕华、崔龙波 、高亚军、何中山、刘晓玲、秦榕蓉、王君