Which ways are there to decouple deployment from release?

Question

One method of continuous deployment is to decouple deployment from release, i.e. deploy updates without activating the changes immediately.

I know that feature-toggles can be used for this, but I'm wondering if there are other techniques for "non-features".

For example, would you build a feature toggle for a bugfix? Probably not and one could argue that bugfixes should be deployed as soon as possible, because it can only get better. And after a bugfix has been released, I sure don't want to toggle it off anymore. But is this the case? It might be a risky change that you want to release in a controlled way. And if there are unexpected side effects, it's good to be able to roll it back. So, feature flags for every change?

And what about visual changes? For example, can you implement something like a feature flag in CSS? Does it even make sense?

Answer 1

For software in the web app category, depending on you infra/hosting provider such decoupling might be possible to switch incoming traffic across (or split it between) different deployed versions of the sw, practically covering any of the changes you mention: bugfixes, visuals, etc.

Such support would typically not require feature toggles. And it might be applicable regardless of the app being monolithic or split in microservices.

For example Google's App Engine Paas offering has support for traffic splitting and migration.

From Splitting Traffic:

You can use traffic splitting to specify a percentage distribution of traffic across two or more of the versions within a service. Splitting traffic allows you to conduct A/B testing between your versions and provides control over the pace when rolling out features.

From Migrating Traffic:

Traffic migration switches the request routing between the versions within a service of your application, moving traffic from one or more versions to a single new version.

Answer 2

While with monoliths you might be restricted to switches, with microservice architectures, you can split every deployment pool of nodes providing a service (ie. pods). You then activate the deployment of the newly changed product in a subset of pool, and carefully monitor it; you can even choose which amount of the pool to deploy the change to, say for instance, activate the change for 15% of the traffic. You might find the feature called "rolling update" in literature.