<p>For software in the web app category, depending on you infra/hosting provider such decoupling <em>might</em> 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. </p>

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

<p>For example Google's <a href="https://cloud.google.com/appengine/" rel="noreferrer">App Engine</a> Paas offering has support for traffic splitting and migration. </p>

<p>From <a href="https://cloud.google.com/appengine/docs/standard/python/splitting-traffic" rel="noreferrer">Splitting Traffic</a>:</p>

<blockquote>
  <p>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 href="https://wikipedia.org/wiki/A/B_testing" rel="noreferrer">A/B testing</a> between your versions
  and provides control over the pace when rolling out features.</p>
</blockquote>

<p>From <a href="https://cloud.google.com/appengine/docs/standard/python/migrating-traffic" rel="noreferrer">Migrating Traffic</a>:</p>

<blockquote>
  <p>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.</p>
</blockquote>

CC BY-SA 3.0
2017-03-06T01:24:54.750Z
2017-03-06T01:24:54.750Z
Dan Cornilescu
<p>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.</p>

CC BY-SA 3.0
2017-03-05T23:46:21.407Z
2017-03-05T23:46:21.407Z
ᴳᵁᴵᴰᴼ
<p>One method of continuous deployment is to decouple deployment from release, i.e. deploy updates without activating the changes immediately.</p>

<p>I know that <a href="/questions/tagged/feature-toggles" class="post-tag" title="show questions tagged &#39;feature-toggles&#39;" rel="tag">feature-toggles</a> can be used for this, but I'm wondering if there are other techniques for "non-features".</p>

<p>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 <em>are</em> unexpected side effects, it's good to be able to roll it back. So, feature flags for every change?</p>

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

CC BY-SA 3.0
2017-03-06T00:14:02.880Z
Pete Hodgson wrote extensively about the various categories of feature toggles, including bugfixes, and other situations where those are suitable. https://martinfowler.com/articles/feature-toggles.html
Evgeny Zislis
<deployment><release-management><feature-toggles>
Which ways are there to decouple deployment from release?
Fabian Schmengler
# Which ways are there to decouple deployment from release?

(Asked by: username_0 on 2017-03-05)

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](/questions/tagged/feature-toggles "show questions tagged '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?

**Tags:** deployment, release-management, feature-toggles

> **Comments:**
> **username_1**: Pete Hodgson wrote extensively about the various categories of feature toggles, including bugfixes, and other situations where those are suitable. https://martinfowler.com/articles/feature-toggles.html  

---

## 2 answers

### Answer by username_2 on 2017-03-06. Score: 7

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](https://cloud.google.com/appengine/) Paas offering has support for traffic splitting and migration.

From [Splitting Traffic](https://cloud.google.com/appengine/docs/standard/python/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](https://wikipedia.org/wiki/A/B_testing) between your versions
> and provides control over the pace when rolling out features.

From [Migrating Traffic](https://cloud.google.com/appengine/docs/standard/python/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 by username_3 on 2017-03-05. Score: 5

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.


---

