前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >CI 不是 CD

CI 不是 CD

作者头像
云云众生s
发布2024-03-28 10:50:33
1000
发布2024-03-28 10:50:33
举报
文章被收录于专栏:云云众生s云云众生s

术语“持续集成”和“持续交付”经常一起使用,以至于很容易忘记它们之间的区别。

许多人将 CI 与 CD 混淆,本文做了清晰的讲解。 译自 CI Is Not CD,作者 Steve Fenton 是 Octopus Deploy 的 Octonaut,DORA 社区指南,拥有 20 多年软件交付经验的六届 Microsoft MVP。他已经撰写了关于 TypeScript(Apress、InfoQ)、Octopus Deploy 和网络运维的书籍......

持续集成/持续交付(CI/CD)。这组两个首字母缩写词组被广泛使用,以至于许多人对它们的含义并不完全了解。许多人忽略了各个部分的重要性、它们为何有所不同以及它们各自的优势如何相辅相成。

什么是持续集成?

CI/CD 中的 CI 代表持续集成(Continuous Integration),即持续地将代码合并到源代码控制中的主分支。Kent Beck 在他的《极限编程(XP)详解》一书中谈到了这一实践。

概念很简单: 编码几个小时后,您将更改提交到主分支。为使这种方式良好地工作,它必须借助一些额外的实践来支持。在 XP 中,测试驱动开发、结对编程和持续重构都是持续集成的关键支持实践:

  • 测试驱动开发可使您高度确信更改不会意外改变系统行为
  • 结对编程可减少合并冲突的可能性,并加速代码审查。
  • 重构将系统分解为小对象和方法,这使冲突更不太可能发生。

当您提交更改时,您希望尽快知道是否存在问题。一个快速的自动化测试套件可使您对更改按预期工作具有高度信心,并在出现问题时减少问题解决的范围。

在市场上出现强大的持续集成工具之前,你可以通过手动方式实现这个过程。团队使用共享的物理对象,如构建帽或合并锤,以确保每次只有一个团队成员集成代码。你可以从可见的架子上取下这个物体,按照简单的检查表来获取最新的主分支更改到你的本地副本。你会构建代码,运行测试,如果一切正常就提交新版本。如果出现问题,你会解决它并重复这个过程。

关键点在于,无论你使用哪些工具来支持,持续集成都是一个由人引导的过程。这个过程是处理个体生产力与利用团队共同开发共享代码的需求之间的权衡的最有效方式。

什么是持续交付?

CI/CD中的CD代表持续交付,是一种基于写软件的原则的软件交付方法,确保软件随时可以部署。Dave Farley和Jez Humble在他们的书《Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation》中详细介绍了这种方法。受XP的启发,持续交付提供了一套具体的技术实践,帮助你实现始终可部署的软件。

您的部署流水线不需要满足持续集成中找到的相同权衡,部分原因是 CI 流程已经处理了对更改的协作。完全有可能拥有一个完全自动化的流水线,它仅在出现问题时请求人工干预(或正如丰田生产系统创始人大野耐一称之为“自治化”,即“带有人性化的自动化”)。

一旦您有了一个好的软件版本,您必须在将其推进到环境中时防止工件和流程的更改。应用相同的工件和流程可确保两者在将代码部署到生产环境之前一起经过了多次测试。如果不将它们锁定在一起,可能会导致使用与软件版本不兼容的新部署流程,或者在预生产部署之前就使用生产部署的流程。

Farley 和 Humble 在他们的持续交付书中专门为持续集成流程和部署流水线各自专门分配了整章。尽管我们可能会将它们合而为一,但这些都是需要独立理解的重要主题。

具有不同驱动因素的两半

持续交付方法包括持续集成和自动化部署流水线。当我们说“CI/CD”时,我们真正谈论的就是这两个概念。CI 过程以源代码为中心,面向开发人员,而部署则是围绕工件和环境的更广泛的协作。

许多团队越来越将 CI 视为 CD,这给他们带来了头疼。当您试图使构建服务器意识到基础设施、环境和配置时,事情会变得痛苦。您基本上是在倒退,因为这更像过去的脚本部署,而不是现代部署流水线。

您的构建过程包括获取最新更改、构建软件、运行一些测试并生成最终工件的步骤。构建过程中的任何问题都会使工件无效,并阻止构建完成。一旦您在存储库中存储了工件或者拒绝了软件版本,构建过程就完成了。

相反,您的部署过程必须处理暂时性问题,如过期令牌、网络故障和不活动的部署目标。您不希望因为这些问题而失败构建,重试部署和部署步骤是有效的策略。此外,如果不使用过度复杂的构建步骤,就很难使用构建步骤对部署过程建模。

超越开发团队

我经常观察到的一个关键区别是,CI 和 CD 工具具有不同的受众。虽然开发人员经常在 CI/CD 的两侧都很活跃,但 CD 工具常被更广泛的群体使用。

例如,测试分析师和支持团队成员可能会使用您的 CD 工具将特定软件版本拉入环境以重现 bug。您的产品经理可能会使用 CD 仪表板来查看哪些软件版本已部署到每个环境、客户或位置。

CD 工具具有一系列细微的功能,可更易于处理部署场景。它们有一种管理环境和基础设施的机制。此机制为每个部署应用正确的配置,并提供一种大规模处理部署的方式,例如管理特定租户的基础设施或部署到不同位置(如零售店、医院或云区域)。

除了实际的部署功能之外,CD 工具还使所有需要了解哪些软件版本所在位置的人都能看到部署状态。这消除了人们需要状态更新的必要,就像您的任务板处理工作项一样。如果您想知道您的银行账户余额,您不想打电话给您的银行;您想立即自助查询答案。您的部署也一样。

解耦的 CI 和 CD 会更好

“CI/CD”中间的斜杠是自然界罕见的解耦机会之一。松散耦合的这样的愉快例子很少。您的构建服务器已经创建了一个工件。它的工作完成了。

虽然您不太可能通过构建过程(尽管可能通过支持它的技术实践)使您的产品与众不同,但您确实可以通过部署流水线为其增加巨大价值。使用可靠的、可重复的部署具有竞争优势。

本文参与?腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2024-01-122,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客?前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与?腾讯云自媒体分享计划? ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 什么是持续集成?
  • 什么是持续交付?
  • 具有不同驱动因素的两半
  • 超越开发团队
  • 解耦的 CI 和 CD 会更好
相关产品与服务
持续集成
CODING 持续集成(CODING Continuous Integration,CODING-CI)全面兼容 Jenkins 的持续集成服务,支持 Java、Python、NodeJS 等所有主流语言,并且支持 Docker 镜像的构建。图形化编排,高配集群多 Job 并行构建全面提速您的构建任务。支持主流的 Git 代码仓库,包括 CODING 代码托管、GitHub、GitLab 等。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档


http://www.vxiaotou.com