什么是 CI/CD 管道?

您如何定义持续集成/持续部署管道取决于您组织的需求。
85 位读者喜欢这个。
Plumbing tubes in many directions

持续集成/持续部署 (CI/CD) 管道是每个 DevOps 计划的基础。CI/CD 管道打破了传统的孤岛,使开发和运维团队能够在整个软件开发生命周期中进行协作。

更好的是,转向 DevOps 和 CI/CD 管道可以帮助您的组织以更高的速度更安全地交付软件

CI/CD 管道分解

关于 CI/CD 管道有很多定义,所以我总是建议组织定义他们自己版本的 CI/CD 管道和其他 DevOps 概念,而不是使用别人的。开源 CI/CD 工具使您可以自由选择和构建满足您组织需求的 CI/CD 管道。

构成 CI/CD 管道的阶段是将任务的不同子集分组到管道阶段中。典型的管道阶段包括

  • 构建:开发人员编译应用程序代码。 
  • 测试:质量保证 (QA) 团队使用自动化测试工具和策略测试应用程序代码。 
  • 发布:开发团队将应用程序代码交付到代码仓库。
  • 部署:DevOps 团队将应用程序代码暂存到生产环境。 
  • 安全和合规性:QA 团队根据项目的需求验证构建。在此阶段,组织部署容器扫描工具,以根据常见漏洞和暴露 (CVE) 检查映像的质量。 

这些是 CI/CD 管道的标准阶段,但有些组织会调整 CI/CD 管道模型以适应其需求。例如,为医疗保健市场构建应用程序的组织,由于其严格的合规性标准,可能会在其工具链中分布测试、验证和合规性关卡。

其他示例可能包括依赖于具有开源软件 (OSS) 的复杂软件供应链的组织。商业组件可能会设立一个关卡,开发团队成员可以在其中为 OSS 软件包生成软件物料清单 (SBOM),或者外部商业软件供应商必须交付 SBOM 作为其合同可交付成果的一部分。

CI/CD 管道的障碍

实施 CI/CD 管道会改变团队的流程和文化。虽然许多开发人员乐于接受某些任务和测试的自动化,但人可能是 CI/CD 采用的障碍。

从瀑布流程转向 CI/CD 可能会动摇某些组织中基本和隐含的权力结构。由于 CI/CD 管道提高了软件交付速度,因此您旧的手动流程的“守门人”可能会感到这种变化的威胁。

集成机会

构成 CI/CD 工具链的工具的开源根基为一些令人兴奋的集成创造了机会,随着您在文化、流程和工具方面实现更高的 DevOps 成熟度。

分析公司 Forrester 在 2020 年预测,即时学习将加入 CI/CD 管道。如果您考虑一下,这是有道理的。在当前的远程工作时代,甚至对于新员工的远程入职而言,这更有意义。例如,组织可以将内部流程的文档维基集成到其管道中。

更雄心勃勃的组织可以将学习管理系统 (LMS)(例如 Moodle)集成到其 CI/CD 管道中。它可以使用 LMS 发布关于开发人员在入职或工具在整个管道中更新时需要学习的新的 DevOps 工具链功能的简短视频。

一些组织正在将群聊和其他协作工具直接集成到其 CI/CD 管道中。聊天平台提供警报,并实现团队之间的协作和沟通。将 Mattermost、Rocket.Chat 或其他 企业聊天平台集成到您的 CI/CD 管道中需要预先计划和分析,以确保管道用户不会淹没在警报中。

另一个值得探索的集成机会是在您的 CI/CD 管道中构建分析和高级报告。这有助于您利用流经管道的数据。

最后的想法

CI/CD 管道是 DevOps 的基础。开源使其能够适应和灵活地应对您在 DevOps 之旅中实施的运营变更所产生的新需求。

我希望看到对统一 DevOps 平台趋势的开源响应,其中组织寻求端到端的 CI/CD 解决方案。这种解决方案的要素已经存在。毕竟,GitLab 和 GitHub 将其平台追溯到开源根基。

最后,不要忘记每个成功的 CI/CD 工具链背后的教育和推广。记录您的工具链和随附的流程将改善开发人员入职和持续的 DevOps 团队培训。

您和您的组织如何定义您的 CI/CD 工具链?请在评论中分享您的反馈。

接下来要阅读什么

什么是 CI/CD?

持续集成 (CI) 和持续交付 (CD) 在软件生产中是非常常见的术语。但是您知道它们真正的含义吗?

标签
User profile image.
Will Kelly 是一位产品营销人员和作家。他的职业生涯一直致力于撰写署名文章、白皮书、营销材料以及关于云和 DevOps 的技术内容。Opensource.com、TechTarget、InfoQ 等已发表了他关于 DevOps 和云的文章。他居住和工作在弗吉尼亚州北部地区。在 Twitter 上关注他:@willkelly。

2 条评论

或许同样有趣的是,不同的 CI/CD 系统之间对于术语“管道”的含义没有强烈的共识。我所知道的 CI/CD 系统最早明确使用“管道”是在 Zuul 中,它从 9 年前的第一个版本开始就一直在使用它:https://zuul-ci.org/docs/zuul/reference/glossary.html#term-pipeline

简而言之,因为它被设计为排队/排序“项目门控”系统,所以它使用“管道”来指代队列的集合,这些队列为特定结果提供上下文(因此在您的示例中,测试、构建和部署将是 Zuul 中配置的不同管道)。主要示例是依赖队列,它由更改审批构建而成,其中每个更改进入“门”管道,等待其依赖的更改或那些在其之前批准的相关项目的预测合并状态以反映现实。

持续交付基金会(Linux 基金会的一个基金)内的互操作性特别兴趣小组一直在尝试调查此术语与其他相关术语之间的差异:https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md

我还应该指出,Zuul 对“管道”的使用(很像它的许多其他术语)是从处理器设计中借鉴的。Zuul 对更改进行管道化以执行预测并行化,很像 CPU 对操作进行管道化以实现推测执行。

回复 作者 fungi

知识共享许可协议本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.