有哪些方法可以使部署与发布脱钩？

连续部署的一种方法是将部署与发布脱钩，即在不立即激活更改的情况下部署更新。

我知道可以使用功能切换，但是我想知道是否还有其他“非功能”技术。

例如，您会为错误修正构建功能切换吗？可能不是，而且有人可能会争辩说应该尽快部署错误修正，因为它只会变得更好。而且，在发布错误修正后，我当然不想再将其关闭。但是是这样吗？您想以受控方式发布可能是一项冒险的更改。如果有有意想不到的副作用，这是很好的能够回滚。那么，每项更改的功能标志？

视觉变化又如何呢？例如，您可以在CSS中实现类似功能标记的功能吗？有道理吗？

对于网络应用类别中的软件，取决于您的基础设施/托管提供商，这种解耦可能会在软件的不同部署版本之间切换传入流量（或在其之间进行拆分），实际上涵盖了您提到的任何更改：错误修正，视觉效果等

这种支持通常不需要功能切换。无论应用程序是单块的还是在微服务中拆分的，它都可能适用。

例如，Google的App Engine Paas产品支持流量拆分和迁移。

从流量分割中：

您可以使用流量拆分来指定服务中两个或多个版本之间流量的百分比分布。划分流量可让您在各个版本之间进行A / B测试，并控制推出功能时的进度。

从迁移流量：

流量迁移可在应用程序服务的各个版本之间切换请求路由，从而将流量从一个或多个版本转移到单个新版本。

尽管使用整体式服务器，您可能仅限于使用微服务架构的交换机，但您可以拆分提供服务的节点的每个部署池（即Pod）。然后，在池子集中激活新更改的产品的部署，并仔细监视它；您甚至可以选择将更改部署到的池数量，例如，为流量的15％激活更改。您可能会在文献中找到称为“滚动更新”的功能。