Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-06T01:24:54.750Z
Answers: 2017-03-06T01:24:54.750Z
Answers: Dan Cornilescu
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-05T23:46:21.407Z
Answers: 2017-03-05T23:46:21.407Z
Answers: ᴳᵁᴵᴰᴼ
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-06T00:14:02.880Z
Comments: 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
Comments: Evgeny Zislis
Tags: <deployment><release-management><feature-toggles>
Title: Which ways are there to decouple deployment from release?
UserDisplayName: Fabian Schmengler
ThreadText: # 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.
  
  
  ---
  
  