问题描述
在阅读关于持续交付的概念的文章时，对其中的一些陈述感到困惑。为了简化和澄清问题，用户假设使用Git作为版本控制系统，只有一个主分支（以及基于主分支的功能分支），只有一个生产环境，并且这是一个Node.js项目。用户对以下两个问题感到困惑：
1. 在将功能分支合并到主分支后，是否将可交付物（例如js包、docker镜像等）创建并推送到注册表中，是否被视为“持续集成”的一部分？用户自己的答案是，不是，它应该是“持续交付”的一部分。这个答案正确吗？
2. 是否必须至少拥有一个预发布/测试环境（以及与该环境对应的另一个分支）来实现持续交付？用户之所以问这个问题，是因为他读到一些暗示这一点的文章，例如：https://aws.amazon.com/devops/continuous-integration/ https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
如果创建一个预发布/测试环境，持续交付的含义会发生变化吗？同一篇文章暗示在持续交付中，部署到测试环境是自动完成的。
用户对持续交付中的手动和自动的具体操作流程感到困惑，希望能够得到解答。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
持续集成、持续交付和持续部署的定义
首先，我们需要明确“持续集成”（Continuous Integration）、“持续交付”（Continuous Delivery）和“持续部署”（Continuous Deployment）的定义。这些术语在不同的人群中有不同的含义。
“持续集成”源自于极限编程（Extreme Programming），由Kent Beck等人开发。在《极限编程解释：拥抱变化》（Extreme Programming Explained: Embrace Change）一书中，Beck对“持续集成”有以下定义：
集成并构建一个完整的产品。如果目标是刻录一张CD，那就刻录一张CD。如果目标是部署一个网站，那就部署一个网站，即使是到测试环境。持续集成应该足够完整，以至于系统的第一次部署不是什么大不了的事情。
从极限编程的角度来看，持续集成会产生一个可交付的内容，例如库、包或注册表中的容器。如果目标是创建这个包，那就足够了。然而，如果团队负责构建系统，真正的持续集成会更进一步，将该包或容器部署到一个环境中。团队需要定义其目标和可交付内容——是面向用户的软件系统还是一个包？
在执行极限编程的形式的持续集成或者今天通常所说的持续交付时，几乎肯定需要一个受控的预发布或测试环境。这些实践要求您对能够随时将软件部署到生产环境中有信心。如果没有将其部署到某个地方，最好是部署到与生产环境足够相似的环境中，您打算如何获得必要的信心呢？这仅适用于构建系统的团队，构建包的团队可以通过在某个地方创建包而不发布它来获得信心。
至于分支，您不需要为每个环境创建一个分支。您可以继续使用基于主干的开发（直接提交到主干或使用短期功能分支）以及从主干发布或为发布创建分支。如果您正在实践极限编程的CI或持续交付的定义，每次提交到主干都会创建并部署一个构建。当您决定进入生产环境时，一个人会决定将与特定构建相关的构件推广到生产环境。如果您为发布创建分支，这将与从主干创建发布分支相关。否则，它将推广特定的提交哈希或标签。
持续交付中的手动和自动操作
在持续交付中，有一些操作是自动完成的，有一些操作是需要手动干预的。下面是持续交付中常见的手动和自动操作：
自动操作：
- 持续集成：当功能分支合并到主分支时，自动运行测试、代码检查、代码风格等，并生成可交付的构建物（如js包、docker镜像等）。
- 部署到预发布/测试环境：自动将构建物部署到预发布/测试环境中，以进行进一步的测试和验证。
手动操作：
- 部署到生产环境：手动决定将哪个构建物部署到生产环境中，以确保对生产环境的更改是有意的，并且具备足够的可靠性和稳定性。
需要注意的是，持续交付中的手动操作是为了确保对生产环境的更改是有意的，并且具备足够的可靠性和稳定性。手动操作的目的是为了提供一个额外的层面的保障，以确保在将更改部署到生产环境之前进行适当的验证和审查。
总结
在持续交付中，持续集成是自动完成的操作，它包括运行测试、代码检查、代码风格等，并生成可交付的构建物。部署到预发布/测试环境也是自动完成的操作，它将构建物部署到预发布/测试环境中进行进一步的测试和验证。而部署到生产环境是手动操作，需要人工决定将哪个构建物部署到生产环境中。
希望这个解答能够帮助您理解持续交付中的手动和自动操作。如果您有任何进一步的问题，请随时提问。