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


自动（自动） 。
手册。

我无法想象在DevOps墙的另一侧会有一个可怜的“操作员”，他将不得不做与“手册”的意思是...我的问题：我的问题（在我的问题中）是“分发”还是“安装”，与这种“手动”内容的可能实现接近吗？以下是我的相关问题的相关引文：但尚未在目标中激活它。这应该类似于/接近连续交付吗？

在某些目标环境中安装（或激活），并结合诸如绑定，停止/开始操作等。这应该是类似的/接近连续部署还是不连续？





它还有哪些其他可能的实现？

评论

对于AWS部署，我创建了仅团队经理有权访问的上传/部署脚本。因此，为了部署到生产中，团队经理需要运行脚本。
抱歉，您的梦想破灭了，但我们仍然有一个“部署”团队，Oek将与ARCAD一起在Db2-iSeries上启动数据库更新，然后在Tomcart服务器上进行厨师安装，以每2周四晚上8点至午夜部署生产版本。因此，可悲的是，有时候操作员很差（希望这不是他们唯一的工作）

#1 楼

我个人认为针对目标的软件distribution只是部署的中间步骤-必须完成该部署的安装/激活该软件。当要部署的软件创建并可供部署（即用于分发，安装和激活）时，

因此，回答您的第一个问题，不，我不会认为分发和安装反映是的，在某些（希望很少见）的情况下，手动步骤只是最终部署到生产中的人为决定，反映了过程自动化和生产过程中的文化误解即使是纯粹基于可自动计算的算法（例如，计算通过/失败的次数）做出的决定，也需要人工仔细检查并批准部署决策（因此，对此负责）测试结果）。

但是，总的来说，它只是反映了一个事实，即在生产中执行部署的决策不仅是自动化算法的结果。例如： （我们都知道，这不只是理论上的案例）
即使满足所有条件，部署仍会出于任何原因而暂停（例如，由于市场时机的影响）


（尚未）实现/部署自动算法
该算法包括根据人工决策（例如人工测试的结果）检查某些标准的方法
部署实际上是在第三方客户环境中完成的进行额外的客户检查后

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

评论

Merci（对不起，谢谢）分享了您对此的看法。看起来我们对“分布”有不同的理解。因此，让我仅添加一种情况：在周日清晨，您有一个1个小时的在线银行系统窗口，用于“激活” 150.000个更新的可执行文件。而且，如果出于任何原因需要回滚，那么就无法进行谈判来扩大该期限。您是否真的想在“分发”上浪费时间，而不是将其所需的时间用于“以防万一需要回滚？”请三思：如果花费的时间超过1个小时，您就会被解雇... ???

– Pierre.Vriens♦
17 Mar 12 '17 at 19:32
恕我直言，这只是部署本身的优化或实施细节，适用于您的情况（但这并不构成规则）。仅仅因为您要在实际上关闭旧的sw执行之前执行部分部署，并不意味着相应的工作就属于交付阶段。这也不一定意味着一旦开始部署，您就也需要完成它。即使您实际上没有进行部署，也可以有效地交付sw（即可用/准备部署）。

–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 12 '17 at 21:51


#2 楼

如果要发布期望其他项目使用的内容，则需要考虑的另一个问题是，部署还具有“发布供他人使用”的含义。工件存储库。该过程的这一部分可能是您部署另一个在构建时需要该工件的组件的一部分，或者可能仅仅是对公共库的更新。但是无论如何，对于该工件而言，它的生命周期并不一定会因可供其他人使用而结束，但是将该工件部署到工件存储库中可能是开发人员决定削减产品成本的最后阶段。新发行版本，然后其他人才能安全使用新版本。