什么是手动，什么是连续交货的自动化？

Question

我在互联网上读过很多关于这个概念的文章。我以为我明白了，但其他文章中的一些陈述让我感到困惑。

为了简化和澄清事情，我假设我使用Git作为VCS，我只有主分支(以及基于它的特性分支)，只有生产环境，这是一个Node.js项目。

连续部署是明确的。一切都会自动释放。

持续集成就是确保更改不会破坏代码库中的内容:主。一旦一个PR是从功能分支创建到主人，我的CI工具将运行测试，皮棉，风格等，公关将能够合并一旦管道通过。

我的第一个问题:创建可交付产品( js包、码头形象等)是否被视为“持续集成”的一部分。一旦PR被合并为主人，就把它推到一个注册表上？我自己的回答是，不，这应该是“持续交货”的一部分。对吗？

我的第二个问题:是否必须至少有一个阶段/测试环境(以及与此环境相对应的另一个分支)才能实现持续交付？我之所以这么问，是因为我读了一些暗示这一点的文章:例如https://aws.amazon.com/devops/continuous-integration/ https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment

如果我创建了一个阶段/测试环境，那么连续交付的含义会改变吗？同一篇文章暗示，部署到测试环境是在连续交付中自动完成的。

我确信CI/CD可能有不同的实现和方法。总之，我搞不懂在连续交付过程中将自动和手动完成什么工作。

提前谢谢。

Answer 1

首先要做的是定义“连续集成”、“连续交付”和“持续部署”的含义。它们对不同的人来说意味着不同的东西。

持续集成来自极限编程，由Kent Beck和其他人开发。在中解释:拥抱改变，Beck说这是关于持续集成的：

整合和建立完整的产品。如果目标是刻录一张CD，那就刻录一张CD。如果目标是部署一个网站，那么就部署一个网站，即使它是一个测试环境。持续集成应该足够完整，因此系统的第一次部署并不是什么大事。

从极端编程的角度来看，持续集成将产生可交付的结果，例如注册表中的库、包或容器。如果目标是制定一揽子计划，那就足够了。但是，如果团队负责构建系统，那么真正的持续集成将更进一步，并将该包或容器部署到环境中。团队需要定义它的目标和可交付的内容--它是面向用户的软件系统还是软件包？

在执行极端编程的连续集成形式或今天通常被称为连续交付时，几乎可以肯定需要有一个控制良好的阶段或测试环境。这些实践要求您对将软件部署到按需生产环境的能力有信心。如果不将其部署到某个地方，最好部署到一个与生产环境非常类似的环境中，那么您打算如何获得必要的信任呢？但是，这只适用于团队构建系统--团队构建包可能会通过在某个地方创建一个包而不是发布它来自信。

至于分支，您不需要每个环境的分支。您可以继续使用基于主干的开发(直接到树干或使用短暂的功能分支)和从后备箱释放出来或发布分支。如果您正在实践XP对CI或连续交付的定义，则每次提交主干都会导致在某个地方创建和部署构建。当您决定开始生产时，一个人会决定将与特定构建相关的工件推广到生产中。如果您正在为发布进行分支，这将与从主干创建发布分支相关联。否则，它将促进特定的提交哈希或标记。