持续集成

Question

这三个术语有什么区别？我的大学提供以下定义：

持续集成基本上只是意味着开发人员的工作副本每天都会与共享主线同步几次。

持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！

持续部署被描述为持续交付后的逻辑下一步：无论何时通过QA，都会自动将产品部署到生产环境中！

它们还提供警告：如果您能够连续部署到测试系统，有时也会使用术语“持续部署”。

所有这些让我感到困惑。任何更详细的解释（或附带一个例子）都表示赞赏！

Answer 1

持续集成

我同意你大学的定义。 持续集成是一种策略，用于开发人员如何持续地将代码集成到主线 - 而不是经常。

您可能会声称它只是您的版本控制系统中的分支策略。

它与您分配给开发人员的任务的大小有关;如果一项任务估计需要4-5个人日，那么开发人员将不会煽动在接下来的4-5天内提供任何东西，因为他还没有做任何事情 - 但是。

因此规模很重要：

small task = continuous integration
big task   = frequent integration

理想的任务规模不会超过一天的工作量。这样开发人员每天至少会有一次集成。

持续交付

持续交付中基本上有三个学校：

持续交付是持续集成的自然延伸

这所学校，查看Addison-Wesley "Martin Fowler" signature series，并假设自2007年发布以来被称为＆＃34;持续集成＆＃34; 和2011年之后被称为＆＃34;持续投放＆＃34; 它们可能是与连续某事相同的概念性概念的第1 + 2卷。

持续交付与敏捷软件开发有关

这所学校认为持续交付的全部意义在于能够支持敏捷运动中的原则，而不仅仅是作为概念性想法或意向书但真实 - 在现实生活中。

在Agile Manifesto中的第一个原则中取消偏移，其中术语＆＃34;持续交付＆＃34;实际上是第一次使用：

我们的首要任务是通过尽早和持续交付有价值的软件来满足客户。

这所学校声称＆＃34;持续交付＆＃34;是一种范例，包含实施"definition of done"的自动验证所需的一切。

这所学校接受＆＃34;持续交付＆＃34;而且，在他们都试图接受或封装这种新范式或方法而不仅仅是一种技术的情况下，流行词或大趋势"DevOps"是同一枚硬币的翻转面。

持续投放是持续部署的同义词

第三所学校主张持续部署和持续交付可以互换使用，意思相同。

当开发人员准备好某些东西时，它会立即传递给最终用户，这在大多数情况下意味着它应该部署到生产环境中。因此＆＃34;部署＆＃34;和＃34;交付＆＃34;意思是一样的。

加入哪所学校

您的大学明显加入了第一所学校，声称我们指的是同一出版物系列的第1 + 2卷。我的观点是，这是滥用持续交付一词。

我个人主张理解持续交付与实现对敏捷运动所提出的想法和概念的现实支持有关。所以我加入了学校，说这个词包含了一个完整的范例 - 比如＆＃34; DevOps＆＃34;。

使用交付作为部署的同义词的学校主要由创建部署控制台的工具供应商提倡，试图从更广泛的使用中获得一些宣传持续交付一词。

持续部署

对持续部署的关注主要与最终用户访问软件更新依赖于此信息的某些集中源更新以及此集中源并不总是易于更新的域相关，因为它＆＃ 39;单片或具有（太）高度连贯性（网络，SOA，数据库等）。

对于许多生成软件的域名，其中没有集中的信息源（设备，消费者产品，客户端安装等）或者集中的信息源易于更新（应用程序存储工件管理系统，开源存储库等），几乎没有关于持续部署一词的炒作。他们只是部署;它并不是一件大事 - 它不是一种需要特别关注的痛苦。

持续部署不是每个人都普遍感兴趣的事实，这也是学校宣称“交付”的理由。和＆＃34;部署＆＃34;是同义词弄错了。因为持续交付实际上对每个人都非常有意义 - 即使您在设备中进行嵌入式软件或为框架发布开源插件。

您所在大学的定义是，持续部署是持续交付的自然下一步隐含地假设每个QA＆t的交付应该立即对最终用户可用，更接近于定义我的部落用来描述“连续释放”这个术语，而这又是另一个对每个人都没有意义的概念。

发布可能是一个非常具有战略性或政治性的事情，并且没有理由假设每个人都希望一直这样做（除非他们是在线书店，一种流媒体服务类型的公司）。然而，那些不会盲目地一直发布所有内容的公司可能有许多理由说明为什么他们希望成为部署的主人，所以他们也做持续部署。不是发布到生产，而是发布 - 候选到类似生产的环境。

我相信你的大学弄错了。他们误以为是“连续部署”＃34; for＆＃34; Continuous Release＆＃34;。

持续部署只是持续能够将开发过程的结果转移到类似生产环境的规则，在这种环境中可以全面执行功能测试。

持续交付故事情节

在图片中，一切都活跃起来：

持续集成过程是状态转换图中的前两个操作。其中 - 如果成功 - 启动实现定义的Continuous Delivery管道。部署只是必须在此管道中持续完成的众多操作之一。理想情况下，从开发人员提交到VCS的位置到管道确认我们拥有有效候选发布版本的点，该流程是自动完成的。

Answer 2

问题和答案都不符合我的简单思考方式。我是一名顾问，并将这些定义与一些开发团队和DevOps人员进行了同步，但我很好奇它与整个行业的匹配程度：

基本上我认为连续交付的敏捷实践就像一个连续统一体：

不连续（一切手动）0％----＆gt; 100％持续交付价值（一切自动化）

持续交付的步骤：

零。开发人员检查代码时没有任何事情是自动化的......如果他们在办理登机手续之前编译，运行或执行了任何测试，那么你很幸运。

持续构建：自动构建每次签入，这是第一步，但无法证明新代码的功能集成。
持续集成（CI）：自动构建和执行至少单元测试，以证明新代码与现有代码的集成，但最好是集成测试（端到端）。
持续部署（CD）：当代码至少将CI传递到测试环境时自动部署，当质量通过CI或将较低的环境标记为手动测试后通过。在某些情况下，测试可能是手动的，但是自动升级到下一个环境。
持续交付：自动发布并将系统发布到生产环境中。这是CD投入生产以及任何其他配置更改，如A / B测试设置，向用户通知新功能，通知支持新版本和更改注释等。

编辑：我想指出，＆＃34;持续交付＆＃34;的概念之间存在差异。正如敏捷宣言的第一个原则（http://agilemanifesto.org/principles.html）和持续传递的做法所引用的那样，似乎是在问题的背景下引用的。持续交付的原则是努力减少库存浪费，如精益思想（http://www.miconleansixsigma.com/8-wastes.html）所述。自敏捷宣言于2001年编写以来，灵活团队持续交付（CD）的实践已经出现多年。这种敏捷实践直接解决了这一原则，尽管它们是不同的东西，显然很容易混淆。

Answer 3

我认为亚马逊的定义很简单易懂。

＆＃34; 持续交付是一种软件开发方法，其中发布过程是自动化的。每个软件更改都会自动构建，测试并部署到生产环境中。在最终推向生产之前，人员，自动化测试或业务规则决定何时应该进行最终推送。虽然每次成功的软件更改都可以通过持续交付立即发布到生产中，但并不是所有更改都需要立即发布。

持续集成是一种软件开发实践，团队成员使用版本控制系统并将其工作频繁地集成到同一位置，例如主分支。每个更改都通过测试和其他验证进行构建和验证，以便尽快检测到任何集成错误。 持续集成专注于自动构建和测试代码，与持续交付相比，可以将整个软件发布流程自动化到生产。＆＃34;

请查看http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

Answer 4

Atlassian对Continuous integration vs. continuous delivery vs. continuous deployment发布了一个很好的解释。

简而言之：

持续整合 - 是每当新的提交被推入分支时，自动构建和测试应用程序。

持续交付 - 是持续集成 + 通过“点击按钮”将应用程序部署到生产中（通常会向客户发布，但是按需）。

持续部署 - 是 持续交付但没有人为干预（正在向客户发布）。

Answer 5

持续集成基本上只意味着开发人员的工作副本每天都会与共享主线同步几次。

每天或多次。基本上，任何给定的离散任务都经常完成。例如，考虑一个开发人员在一个业务应用程序上工作。在许多环境中，可能会发生以下情况：

一两个开发人员会在几天内保留本地更改，因为“它还没有准备好”。
一个或两个开发人员在源代码管理中创建分支，以便他们可以“处理他们的功能”，而不会被其他人的更改所困扰。

这些可能会导致问题。糟糕的代码/任务组织导致分支，分支导致合并，合并......导致痛苦。持续集成作为一种实践通过鼓励每个人使用相同的共享源来解决这个问题。个别工作项目应足够离散，以便在短时间内完成（最多几小时）。

基本上，一般的想法是在少量工作中集成一个小的变化。整合大的变化是一项不成比例的大量工作。如果以恒定的小步骤完成，集成工作的总量会更小。这使开发人员可以将更多时间用于业务可见功能而不是开发流程开销。

持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！

这遵循离散的，定义明确的工作项的相同想法。如果只有一个主代码库只能通过完整，经过测试的已知工作特性以较小的增量进行调整，那么该代码库始终是稳定的。自动测试是关键，只需按一下按钮即可证明稳定性。

需要完成的稳定性较低的工作（同样，开发过程开销并且应该被消除），代码库可以更频繁地推送到任何给定的环境。在许多公司中，部署可能是一个非常艰苦的过程。即使是为期一周的全副手操作。这很昂贵，没有商业价值。通过采用良好的工作项定义，有效的自动化测试和持续集成，团队可以自动将代码库交付到任何给定的环境。

持续部署在连续交付后被描述为合乎逻辑的下一步：无论何时通过QA，都会自动将产品部署到生产环境中！

你很少会在商业环境中看到这种情况，遇到它时会非常高兴。如果代码库可以自动测试并自动部署到任何给定的环境，那么，生产就像任何其他环境一样。因此，如果团队已经建立起来，那么通过始终能够将更新部署到生产中，可以为业务带来巨大的价值。

缺陷修复程序更快地发送给客户，新功能更快地进入市场，新的想法以较小的增量对市场进行测试，以允许重定向优先级等。

例如，假设一家公司对其基于软件的产品或服务中的新功能有一个很大的想法。他们已经做了一些研究，他们了解市场，他们相信这个想法将带来强劲的新收入。现在考虑提供该功能的两个选项：

花几个月在一次性分支中开发整个事情。花几周时间将它集成到主代码库中。花几天时间测试一下。花一天时间部署它。只有然后才开始跟踪生产系统中的实际收入。
一次一个地实现该功能的一小部分。每周发布一个新的部分。每周都会获得更多有关实际收入的数据。

在第一种情况下，如果该功能没有达到预期的市场效果，那么很多的钱就会浪费在客户实际上并不想要的东西上。在第二种情况下，客户不想要它的事实很早就确定了，而其余的工作都被排除在优先级之外。

最终，这些“连续的事情”都是关于消除开发过程的开销。如果公司的收入来源是特定的服务产品，那么理想情况下，他们的所有成本都应该用于该产品。开发流程开销（合并代码，在合并后重新测试相同的功能，手动部署任务等）实际上并没有对服务的价值做出贡献，因此这些概念试图从流程中消除这些成本。

Answer 6

一个图表可以替换多个单词：

享受！： - ）

＃我已更新了正确的图片...

Answer 7

持续集成，持续交付和持续部署之间的区别

Answer 8

我认为我们过度分析并且可能会使得连续的＆＃34;连续＆＃34;一整套的话。在此背景下，连续意味着自动化对于附加到＆＃34;连续＆＃34;使用英语作为翻译指南，请不要试图让事情复杂化！在＆＃34;持续构建＆＃34;我们自动构建（编写/编译/链接/等）我们的应用程序，使其成为特定平台/容器/运行时/等可执行的东西。＆＃34;持续整合＆＃34;表示您的新功能在与其他实体交互时测试并按预期执行。显然，在进行集成之前，必须进行构建，并且还将使用彻底的测试来验证集成。因此，在＆＃34;持续整合＆＃34;一个人使用自动化为一个现有的功能桶增加价值，这种方式不会对现有功能产生负面影响，而是与它很好地集成，为整体增加一个感知价值。整合意味着，仅仅通过英语定义，事物和谐地协调，所以在代码谈话中我添加编译，链接，测试并在整体内完美运行。如果最终产品失败，你不会把它集成在一起，你呢？！在我们的背景下＆＃34;持续部署＆＃34;是＆＃34; continuos delivery＆＃34;的同义词因为在一天结束时我们为客户提供了功能。但是，通过对此进行过度分析，我可以说部署是交付的一个子集，因为部署某些东西并不一定意味着我们交付了。我们部署了代码，但由于我们没有有效地与利益相关方沟通，我们无法从业务角度提供服务！我们部署了部队，但我们还没有将承诺的水和食物送到附近的城镇。如果我要添加＆＃34;连续转换＆＃34;该怎么办？这个术语，它有自己的优点吗？毕竟，它可能更适合描述代码在环境中的移动，因为它具有＆＃34; from / to＆＃34;的内涵。更多的是部署或交付，这可能只是意味着一个地方，永远！如果我们不适用常识，这就是我们所得到的。

总之，这是一个简单的描述（做起来有点复杂！），只是使用常识，英语，你会没事的。