在连续交付结束时如何实施手动步骤？

关于“ 持续集成如何与持续交付/部署有何关系？ ”这一问题的公认答案也解释了持续交付和持续部署之间的微小差异。它似乎与以下问题的答案有关：“您想如何将其部署到生产中，而这些（专有）选项是您可以从中选择的：

• 自动）。
• 手册。

我无法想象在DevOps墙的另一侧会有一个可怜的“操作员”，他将不得不做与“手动”所指的内容相对应的事情……我的问题：

• （在我的问题中）我对“分发”与“安装”的引用是否接近这种“手动”东西的可能实现？这是我相关问题的相关报价：

• 使用FTP之类的工具（如果标准副本无法弥合差距）将其分发到某些目标环境，但尚未在目标中激活它。那应该类似于/接近连续交付吗？
• 在某些目标环境中安装（或激活），并结合诸如绑定，停止/启动操作等内容。这应该类似于/接近于连续部署吗？

• 它还有其他可能的实现方式吗？

我个人认为将distribution软件定向到目标只是部署的中间步骤-要完成该部署，必须安装/激活该软件。

对我而言，delivery（如中continuos delivery）停止了要创建的软件的部署并使其可用于部署（即，用于分发，安装和激活）

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

是的，在某些（希望很少）的情况下，手动步骤只是部署到生产中的最终人工决策，反映出对流程自动化的文化不信任以及人为的双重检查和批准部署决策所带来的心理舒适感（因此假设即使对此决定完全基于可自动执行的算法（例如，对通过/失败测试结果进行计数）也是如此。

但是总的来说，它只是反映了一个事实，即在生产中执行部署的决策不仅是自动化算法的结果。这是一些此类情况的示例：

• 自动决策被覆盖
  • 即使不满足所有质量标准，也可以批准部署（我们都知道这不仅是理论上的情况）
  • 即使满足所有条件，部署也会以任何原因暂停（例如，由于市场时机的影响）
• 尚未（尚未）实施/部署自动算法
• 该算法包括根据人工决策检查某些标准（例如人工测试的结果）
• 部署实际上是在第三方客户环境中进行的，之后还要进行其他客户检查

因此，我不会将手动步骤仅视为实现问题。

如果要发布期望其他项目使用的内容，则部署时还需要考虑的另一点是，部署也具有“发布供他人使用”的含义。

考虑一个工作流程，在该工作流程中您将库部署到通用工件存储库。该过程的这一部分可能是您部署另一个在构建时需要该工件的组件的一部分，或者可能只是对公共库的更新。但是无论如何，对于该工件而言，它的生命周期并不一定会因可供其他人使用而结束，但是将该工件部署到工件存储库可能是开发人员在决定削减一个工件之后的最后阶段。新版本，并且其他人可以放心使用新版本。