什么是 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 团队将应用程序代码暂存到生产环境。
  • 安全性和合规性:质量保证团队根据项目的要求验证构建。 在此阶段,组织会部署容器扫描工具,以对照常见漏洞和暴露 (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 管道。 如果您仔细考虑一下,这是有道理的。 在当前的远程工作时代,甚至对于新员工的远程入职,这都更有意义。 例如,一个组织可以将文档 Wiki 集成到其管道中,其中包含内部流程的文档。

一个更有雄心的组织可以将学习管理系统 (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

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