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

我知道可以使用功能切换，但是我想知道是否还有其他功能“非功能”的技巧。例如，您是否会为错误修正构建功能切换？可能不是，而且有人可能会争辩说应尽快部署错误修正，因为它只会变得更好。而且，在发布错误修正后，我当然不想再将其关闭。
是这种情况吗？您想以受控方式发布可能是一项冒险的更改。而且，如果有意外的副作用，最好将其回滚。那么，每个更改的功能标志呢？

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

评论

皮特·霍奇森（Pete Hodgson）广泛撰写了有关功能切换的各种类别的文章，包括错误修正以及适用的其他情况。 martinfowler.com/articles/feature-toggles.html

#1 楼

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

这种支持通常不需要功能切换。不管应用程序是单块的还是在微服务中拆分的，它都可能适用。例如，Google的App Engine Paas产品支持流量拆分和迁移。

来自拆分流量：


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


来自迁移流量：


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


#2 楼

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