持续集成持续部署持续交付_持续集成和持续交付之间有什么区别？

最新推荐文章于 2024-08-22 16:50:33 发布

dfsgwe1231

最新推荐文章于 2024-08-22 16:50:33 发布

阅读量355

点赞数

文章标签： java 人工智能大数据 python 编程语言

原文链接：https://hackernoon.com/the-real-difference-between-ci-and-cd-smu363p

版权

持续集成持续部署持续交付

有很多内容描述什么是持续集成，持续交付和持续部署。但是这些过程首先要做什么？

了解正确使用CI和CD所解决的问题至关重要。这将使您的团队可以改善您的流程。并避免花力气追求那些不会给您的过程带来任何价值的幻想指标。

持续集成是一个团队问题

如果您在团队中工作，那么您是在同一个存储库上工作的多个开发人员。存储库中有一个主分支，其中载有最新版本的代码。开发人员在不同分支上从事不同的工作。变更完成后，他会将其推送或合并到主分支。最终，整个团队将拉动这一变化。

我们要避免的情况是错误的提交使其进入了main分支。错误意味着代码无法编译或应用程序无法启动或无法使用。为什么？不是因为应用程序损坏了，还是因为所有测试必须始终为绿色。这不是问题，您可以永远不要部署该版本并等待修复。

问题是您的整个团队都陷入了困境。所有提出错误提交的开发人员都将花5分钟时间思考为什么它不起作用。有些人可能会尝试查找错误的提交。有些人会尝试与错误的代码作者并行解决问题。

这对您的团队来说是浪费时间。最糟糕的是，重复发生的事件加剧了对主分支机构的不信任，并鼓励开发人员分开工作。

持续集成就是为了防止主分支被破坏，从而使您的团队不会陷入困境。而已。这是不是有所有测试的绿色所有的时间和主枝部署到生产的每一个承诺。

持续集成的过程独立于任何工具。您可以手动验证分支和主分支的合并在本地是否有效。然后仅实际将合并推送到存储库。现在那将是非常低效的。这就是使用自动检查实现持续集成的原因。

检查应确保最低限度：

该应用程序应构建并启动
最关键的功能应始终保持工作状态（用户注册/登录过程以及关键的业务功能）
所有开发人员都依赖的应用程序的通用层应该是稳定的。这意味着对这些零件进行单元测试。

实际上，这意味着您需要提取适用于您的任何单元测试框架并保护应用程序的公共层。有时，代码不是很多，可以很快完成。另外，您还需要添加“烟雾测试”以验证代码是否已编译以及应用程序是否启动。对于像Java Spring或.NET core这样具有疯狂依赖注入的技术，这尤其重要。在大型项目中，很容易误解依赖项，因此必须确认该应用程序至少总是始终启动。

如果您有成百上千的测试，则无需为每个合并运行所有测试。这将花费大量时间，并且大多数测试可能会验证“非团队阻止者”功能。

我们将在接下来的部分中看到连续交付的过程将如何充分利用这许多测试。

与工具无关

工具和自动检查都可以。但是，如果您的开发人员仅合并他们工作了几个星期的巨型分支机构，那么他们将无济于事。团队将花费大量时间合并分支并修复最终将出现的代码不兼容问题。浪费时间就像被错误的提交阻塞一样。

持续集成与工具无关。这是关于小块工作并将新代码集成到主分支并频繁提取的问题。

通常至少每天一次。将您正在处理的任务拆分为较小的任务。经常合并您的代码，并经常提取。这样一来，没有人能分开工作超过一两天，问题就没有时间滚雪球了。

一项大型任务不需要全部都在一个分支中。应该永远不会。将进行中的工作合并到主分支的技术称为“抽象分支”和“功能切换”。有关更多详细信息，请参见博客文章“ 如何开始进行持续集成 ”。

优质CI的关键点

非常简单 保持简短。 最多3-7分钟 。这与CPU和资源无关。这与开发人员的生产力有关。生产力的首要规则是专注。做一件事，完成它，然后移到下一件事。

上下文切换成本很高。研究表明，当您被打扰时，大约需要23分钟才能重新专注于某件事。

假设您推动分支以合并它。开始另一个任务。您花了15到20分钟才能进入。在您进入区域后的一分钟，您会从20分钟长的CI构建中收到针对先前任务的“构建失败”通知。您回来修复它。您再按一次。您来回移动很容易超过20分钟。

每天浪费一到两次的20分钟是您团队中开发人员的数量……这是浪费很多宝贵的时间。

现在想象一下反馈在3分钟之内到来。而且您知道会的。您可能根本不会启动新任务。您将有证据再次阅读您的代码，或者在等待时检查PR。通知失败。您将修复它。然后继续下一个任务。这就是您的流程应启用的焦点。

保持CI的构建时间短，这是一个折衷方案。在CI范围内运行时间更长或几乎没有价值的测试应移至CD步骤。是的，那里的故障也需要修复。但是，由于它们不会阻止任何人做他们的事情，因此您可以在完成工作后将这些修补程序作为“下一项任务”。只需在工作时关闭通知并不时检查即可。保持上下文切换到最小。

持续交付和部署是工程问题

让我们解决一下定义，以消除这些障碍。

持续交付是指能够随时部署任何版本的代码。实际上，它是指代码的最新版本。您不会自动部署，通常是因为您不必或不受项目生命周期的限制。但是只要有人愿意，就可以在最短的时间内完成部署。有人可以成为想要在暂存或预生产环境中进行测试的测试/ QA团队。或者实际上可能是时候将代码推向生产了。

连续交付的想法是准备与您要在环境中运行的物品尽可能接近的文物。如果使用Java，则可以是jar或war文件，如果使用.NET，则可以是可执行文件。它们也可以是已转译的JS代码的文件夹，甚至是Docker容器的文件夹，无论使部署变得更短（即，您已经尽可能地预先构建了）。

通过准备人工制品，我并不是要把代码变成人工制品。这通常是一些脚本和执行时间。准备方式：

运行所有测试，以确保一旦部署，该代码便会真正起作用。如果可以自动执行单元测试，集成测试，端到端测试，甚至性能测试。

这样，您可以过滤主分支的哪些版本实际上已准备好生产，哪些尚未准备就绪。理想的测试套件：

确保应用程序关键功能正常工作。理想情况下，所有功能
确保没有引入性能破坏因素，因此当您的新版本受到众多用户的欢迎时，它就有机会持续
空运行您的代码需要的任何数据库更新，以免出现意外

它不需要非常快。 30分钟或1小时是可以接受的。

持续部署是下一步。您将最新和生产就绪版本的代码部署到某些环境。如果您对CD测试套件足够信任，则是理想的生产方式。

请注意，根据上下文，这并非总是可能或值得付出。持续交付通常足以提高生产力。特别是如果您在封闭的网络中工作并且环境有限，则可以部署到该环境。也可能是软件的发布周期阻止了计划外的部署。

持续交付和持续部署（从现在起将它们称为CD）不是团队问题。他们的目的是在执行时间，维护工作和测试套件的相关性之间找到适当的平衡，以便能够说“此版本按预期运行”。这是一个平衡。如果您的测试持续30个小时，那就有问题了。有关Oracle数据库测试套件的外观，请参见这篇史诗般的帖子。如果您花费大量时间使测试与最新代码保持最新，从而阻碍了团队的进步，那也不是一件好事。而且，如果您的测试套件几乎没有任何保证，那基本上是没有用的。

在理想的世界中，我们每次提交到主分支都需要1组可部署的工件。您可以看到我们有一个垂直的可扩展性问题：我们从代码转移到工件的速度越快，我们就越准备好部署最新版本的代码。