问题描述
在持续部署中，有一种方法是将部署与发布解耦，即在部署更新时不立即激活更改。除了使用特性开关（feature toggles）之外，是否还有其他适用于“非特性”更改的技术？
比如，对于修复bug，是否应该构建一个特性开关？可能不需要，因为bug修复应尽快部署，因为只会变得更好。而且在bug修复发布后，肯定不想再切换它。但是真的是这样吗？这可能是一个风险较大的更改，你可能希望以受控的方式发布。如果出现意外的副作用，能够回滚是很好的。所以，每次变更都需要特性开关吗？那么对于视觉变化呢？比如，能否在CSS中实现类似特性开关的功能？这是否有意义？
解决方案
在软件的Web应用类别中，根据你的基础设施/托管提供商，可以使用一些方法来实现解耦部署与发布，实现你所提到的各种更改，包括bug修复和视觉变化。这通常不需要使用特性开关。无论应用程序是单体架构还是微服务架构，这都是适用的。
举例来说，Google的App Engine平台即服务（PaaS）提供了流量分割和迁移的支持。从流量分割的说明中可以了解到：
你可以使用流量分割来指定在一个服务的两个或多个版本之间的百分比分布。流量分割允许你在版本之间进行A/B测试，并且可以控制功能发布的速度。
从迁移流量的说明中可以了解到：
流量迁移会在应用程序的一个服务内的多个版本之间切换请求路由，将流量从一个或多个版本移动到一个新版本。
在微服务架构中，你可以将每个服务（例如，Pods）的部署池进行分割。然后，你可以在池的一个子集中激活新更改的部署，并进行仔细监控。你甚至可以选择将更改部署给池中的一部分流量，例如，激活15%的流量。你可能会在文献中找到这种特性称为“滚动更新”。
无论是在单体应用程序还是微服务架构中，都有多种方法可以实现解耦部署与发布，以满足不同类型的更改需求。特性开关可能适用于某些情况，而流量分割、迁移和滚动更新等方法则适用于其他情况。根据具体情况选择合适的方法，以实现更加灵活和可控的部署与发布流程。