如何在连续交付结束时执行手动步骤？

Question

对我关于"持续集成与持续交付/部署有何关系？“的问题的公认回答也解释了连续交付和持续部署之间的细微差别。这似乎与以下问题的答案有关：“您希望如何部署到生产中，而这些是(独占的)选项：

• 汽车(马季奇)。
• 手册。

我无法想象在DevOps墙的另一边会有一个可怜的“操作员”，他将不得不做一些与“手册”的意思相对应的事情.我的问题：

• 我对“分发”和“安装”的引用(在我的问题中)是否接近于这种“手动”-thing的可能实现？以下是我有关问题的相关引语：

• 分发到某些目标环境，使用类似FTP (如果标准副本无法弥补差距)，但尚未在目标中激活它。这应该是类似的/接近连续交付，还是不？
• 在某些目标环境中安装(或激活)，并结合绑定、停止/启动操作等操作。这是否应该与连续部署类似/接近？
• 它的其他可能实现是什么？

Answer 1

就我个人而言，我认为将软件分发给目标只是部署的中间步骤--仍然需要安装/激活该软件才能完成部署。

对我来说，当要部署的软件创建并可供部署(即用于分发、安装和激活)时，交付(如连续交付)停止。

因此，要回答您的第一个问题:不，我不认为发行版和安装反映了区分连续交付和连续部署的手动步骤。

是的，在一些(希望是罕见的)情况下，人工步骤只是部署到生产中的最终人工决定，反映了在流程自动化方面的文化不信任，以及让人对部署决策进行重复检查和签名(从而承担责任)的精神慰藉，即使该决定完全基于一种可以自动化的算法(比如计算通过/失败测试结果)。

但是总的来说，它仅仅反映了这样一个事实，即在生产中执行部署的决策并不仅仅是自动化算法的结果。以下是一些这样的例子：

• 自动决策是覆盖的。
  • 即使不符合所有的质量标准，部署也可以签署(我们都知道，这不仅仅是理论上的情况)。
  • 部署是出于任何原因，即使符合所有标准(例如，由于市场时机的影响)

• 自动化算法尚未实现/部署
• 该算法包括根据人工决策(比如人工测试的结果)检查某些标准。
• 部署实际上是在第三方客户环境中完成的，以下是额外的客户检查。

因此，我不会简单地把手动步骤看作是一个实现问题。

Answer 2

另外一个考虑因素是，如果您发布的是您期望其他项目使用的东西，deploy也具有“供其他人使用的发布”的含义。

考虑将库部署到公共工件存储库的工作流。流程的这一部分可能是部署另一个组件的一部分，该组件在构建时需要该工件，也可能只是对公共库的更新。但是，无论如何，对于这个工件来说，它的生命周期并不一定以供其他人使用而结束，但是将该工件部署到工件存储库可能是开发人员在决定削减新版本和其他人能够安全使用新版本之前工作的最后阶段。