Answers: <p><a href="https://martinfowler.com/bliki/BranchByAbstraction.html" rel="nofollow noreferrer">Branch-by-abstraction</a> and <a href="/questions/tagged/feature-flags" class="post-tag" title="show questions tagged &#39;feature-flags&#39;" rel="tag">feature-flags</a>/<a href="/questions/tagged/feature-toggles" class="post-tag" title="show questions tagged &#39;feature-toggles&#39;" rel="tag">feature-toggles</a> are the typical techniques allowing development of any combinations of features in various degrees of readiness in the same branch. For a proper CI/CD approach that should be the <code>main</code>/<code>master</code> branch. Each feature being developed can be tested independently by turning the respective flag on or off. "Releasing" the feature in that branch simply means that the respective flag is enabled in the source code</p>
  
  <p>To be effective, all the relevant combinations of the feature flags' values should be subjected to the respective CI/CD QA verifications in this branch. The complication, of course, is the number of such combinations which can cause cost/time "explosions" in these verifications, especially in large scale projects with many features.</p>
  
  <p>Grouping multiple feature flags under a single "super-flag" is an effective method of reducing the number of such relevant combinations. Turning on (in the code base) these super-flags are often time-driven according to a release schedule. Which can be either periodical or based on certain specified/seasonal time/dates, it doesn't really matter (as long the respective features meet the expected quality level by that time, of course, but that's a different discussion).</p>
  
  <p>Turning on the super-flags is all that's needed for the software products that are continuously deployed. But for the products which can't be continuously deployed (like OSes or most of the embedded software products) release branches in which only the super flag(s) (or directly feature flags) applicable to the respective releases are enabled is the typical way to keep the release time/costs under control. They can also serve as the CI/CD branch vehicles for subsequent hot fixes, service packs and/or minor releases. </p>
  
  <p>Release branches would be pulled off the main/master branch (or parent major release branch) whenever the quality level is good enough for the very next release and trouble to support the delta to the 2nd next release remains acceptable (as soon as the branch for the next release is pulled the parent branch can diverge, heading towards the 2nd next release).</p>
  
  <p>And no, release branches aren't (necessarily) evil: they are not feature branches and they can completely avoid any massive branch sync/reparent/merge operation, thus remaining true to the CI principles.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-12-13T12:19:59.670Z
Answers: 2018-12-13T12:19:59.670Z
Answers: Dan Cornilescu
Body: <p>There is possibility that client may want certain functionality or feature to be available based on certain season or specific date/time/zeo location. This could grow more complex based on code logic or database changes spreading or impacting to other screens/logical layers.</p>
  
  <p>How can a team handle above situation with CI/CD or DevOps as a process?</p>
  
Tags: <continuous-deployment><cicd>
Title: Release based on restricted timeline with CI/CD
UserDisplayName: user1480864
ThreadText: # Release based on restricted timeline with CI/CD
  
  (Asked by: username_0 on 2018-12-13)
  
  There is possibility that client may want certain functionality or feature to be available based on certain season or specific date/time/zeo location. This could grow more complex based on code logic or database changes spreading or impacting to other screens/logical layers.
  
  How can a team handle above situation with CI/CD or DevOps as a process?
  
  **Tags:** continuous-deployment, cicd
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-12-13. Score: 1
  
  [Branch-by-abstraction](https://martinfowler.com/bliki/BranchByAbstraction.html) and [feature-flags](/questions/tagged/feature-flags "show questions tagged 'feature-flags'")/[feature-toggles](/questions/tagged/feature-toggles "show questions tagged 'feature-toggles'") are the typical techniques allowing development of any combinations of features in various degrees of readiness in the same branch. For a proper CI/CD approach that should be the `main`/`master` branch. Each feature being developed can be tested independently by turning the respective flag on or off. "Releasing" the feature in that branch simply means that the respective flag is enabled in the source code
  
  To be effective, all the relevant combinations of the feature flags' values should be subjected to the respective CI/CD QA verifications in this branch. The complication, of course, is the number of such combinations which can cause cost/time "explosions" in these verifications, especially in large scale projects with many features.
  
  Grouping multiple feature flags under a single "super-flag" is an effective method of reducing the number of such relevant combinations. Turning on (in the code base) these super-flags are often time-driven according to a release schedule. Which can be either periodical or based on certain specified/seasonal time/dates, it doesn't really matter (as long the respective features meet the expected quality level by that time, of course, but that's a different discussion).
  
  Turning on the super-flags is all that's needed for the software products that are continuously deployed. But for the products which can't be continuously deployed (like OSes or most of the embedded software products) release branches in which only the super flag(s) (or directly feature flags) applicable to the respective releases are enabled is the typical way to keep the release time/costs under control. They can also serve as the CI/CD branch vehicles for subsequent hot fixes, service packs and/or minor releases.
  
  Release branches would be pulled off the main/master branch (or parent major release branch) whenever the quality level is good enough for the very next release and trouble to support the delta to the 2nd next release remains acceptable (as soon as the branch for the next release is pulled the parent branch can diverge, heading towards the 2nd next release).
  
  And no, release branches aren't (necessarily) evil: they are not feature branches and they can completely avoid any massive branch sync/reparent/merge operation, thus remaining true to the CI principles.
  
  
  ---
  
  