patternMinor
Which ways are there to decouple deployment from release?
Viewed 0 times
fromarewaysreleasewhichtheredecoupledeployment
Problem
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?
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?
Solution
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.
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.
Context
StackExchange DevOps Q#351, answer score: 7
Revisions (0)
No revisions yet.