每个产品一个 CI/CD 管道以统领一切

当我加入云运营团队时，负责云运营和工程流程精简，在 WorkSafeBC，我分享了我对一个仪表化管道的梦想，每个产品都有一个持续集成构建和持续交付。

根据 Lukas Klose 的说法，流程（在软件工程的背景下）是“当一个系统以稳定和可预测的速度产生价值时的状态。”我认为这是最大的挑战和机遇之一，尤其是在新兴解决方案的复杂领域。努力实现持续和增量的交付模型，提供一致、高效和高质量的解决方案，构建正确的东西并让我们的用户满意。找到将我们的系统分解为更小的、自身有价值的片段的方法，使团队能够以增量方式交付价值。这需要业务和工程思维模式的转变。

持续集成和交付 (CI/CD) 管道

CI/CD 管道是一种 DevOps 实践，用于更频繁、一致和可靠地交付代码更改。它使敏捷团队能够提高部署频率和减少变更前置时间、变更失败率和平均恢复时间关键绩效指标 (KPI)，从而提高质量并更快地交付价值。唯一的前提条件是扎实的开发流程、对质量和从构思到弃用对功能负责的思维模式，以及全面的管道（如下所示）。

它简化了工程流程和产品，以稳定基础设施环境；优化流程；并创建一致、可重复和自动化的任务。这使我们能够将复杂的任务转化为复杂的任务，正如 Dave Snowden 的 Cynefin 认知框架 模型所述，从而降低维护成本并提高质量和可靠性。

简化我们流程的一部分是最大限度地减少 浪费实践类型 Muri（过载）、Mura（变异）和 Muda（浪费）的浪费。

• Muri： 避免过度工程、与业务价值无关的功能以及过多的文档
• Mura： 改进审批和验证流程（例如，安全签核）；推动 左移 倡议，以推动单元测试、安全漏洞扫描和代码质量检查；并改进风险评估
• Muda： 避免浪费，例如技术债务、错误和前期的详细文档

似乎 80% 的关注和意图都集中在提供集成和协作工程系统的产品上，该系统可以获取一个想法和计划，开发、测试和监控您的解决方案。然而，成功的转型和工程系统只有 5% 与产品有关，15% 与流程有关，80% 与人有关。

我们有很多产品可供使用。例如，Azure DevOps 为持续集成 (CI)、持续交付 (CD)、可扩展性以及与开源和商业现成 (COTS) 软件即服务 (SaaS) 解决方案（如 Stryker、SonarQube、WhiteSource、Jenkins 和 Octopus）的集成提供了丰富的支持。对于工程师来说，总是会受到产品的诱惑，但请记住，它们只占我们旅程的 5%。

最大的挑战是打破基于数十年规则、规章和令人沮丧的舒适区域的流程：“我们一直都是这样做的；为什么要改变？”

开发和运营人员之间的摩擦导致各种碎片化、重复和持续的集成和交付管道。开发部门希望访问所有内容，持续迭代，启用用户，并持续快速发布。运营部门希望锁定所有内容以保护业务和用户并提高质量。这无意中并且经常需要难以自动化的流程和治理，从而导致比预期更慢的发布周期。

让我们通过最近白板讨论的片段来探索管道。

管道的多样性难以支持且成本高昂；版本控制和可追溯性的不一致使现场事件复杂化，并且持续简化开发过程和管道是一个挑战。

我提倡一些原则，这些原则可以实现每个产品一个通用管道

• 自动化一切可自动化的事物
• 构建一次
• 维护持续集成和交付
• 保持持续精简和改进
• 维护一个构建定义
• 维护一个发布管道定义
• 尽早且经常扫描漏洞，并快速失败
• 尽早且经常测试，并快速失败
• 维护发布的可追溯性和可观察性

但是，如果我捅了马蜂窝，最重要的原则是保持简单。如果您无法解释管道的原因（什么、为什么）和过程（如何），您就不了解您的工程过程。我们大多数人不是在寻找最好、最现代和革命性的管道——我们需要一个功能性、有价值且能够支持工程的管道。首先解决 80% 的问题——文化、人和他们的思维模式。请您的 CI/CD 闪亮盔甲骑士，带着他们盾牌上的 TLA（两个/三个字母的缩写）符号，加入实用和经验工程的力量。

统一管道

让我们回顾一下我们的一个设计实践白板会议。

定义一个 CI/CD 管道，每个应用程序有一个构建定义，用于触发拉取请求预合并验证和持续集成构建。生成带有调试信息的发布版本并上传到 符号服务器。 这使开发人员能够在本地和生产环境中远程调试，而无需担心他们需要加载哪个构建和符号——符号服务器为我们执行了这种魔术。

在构建中执行尽可能多的验证 - 左移 - 允许功能团队快速失败，不断提高整体产品质量，并在每次拉取请求中包含对审阅者来说非常宝贵的证据。您更喜欢包含无数次提交的拉取请求吗？还是包含几次提交和支持证据（例如安全漏洞、测试覆盖率、代码质量和 Stryker 变异体残余）的拉取请求？就我个人而言，我投票给后者。

不要使用构建转换来生成多个特定于环境的构建。创建一个构建并执行发布时转换、令牌化和/或 XML/JSON 值替换。换句话说，右移特定于环境的配置。

安全地存储发布配置数据，并根据数据的信任和敏感性级别，使其可供开发和运营团队使用。使用开源 Key Manager、Azure Key Vault、AWS Key Management Service 或许多其他产品之一——记住，您的工具包中有许多锤子！

使用组而不是用户来将审批者管理从多个管道的多个阶段转移到简单的组成员身份。

不要复制管道来让团队访问他们感兴趣的领域，而是创建一个管道并授予对交付环境特定阶段的访问权限。

最后但并非最不重要的一点是，拥抱拉取请求，以帮助提高对代码库的洞察力和透明度，提高整体质量，协作并将预验证版本发布到选定的环境；例如，开发环境。

这是整个白板草图的更正式视图。

那么，您对 CI/CD 管道有什么想法和学习经验？我一个管道统领一切的梦想是痴人说梦吗？