Answers: <p>You could use the same tools used in Trunk Based Development (TBD) to carry work-in-progress in the trunk (the only non-release TBD branch with a longer lifespan):</p>
  
  <ul>
  <li><a href="/questions/tagged/feature-toggles" class="post-tag" title="show questions tagged &#39;feature-toggles&#39;" rel="tag">feature-toggles</a>/<a href="/questions/tagged/feature-flags" class="post-tag" title="show questions tagged &#39;feature-flags&#39;" rel="tag">feature-flags</a></li>
  <li><a href="https://martinfowler.com/bliki/BranchByAbstraction.html" rel="nofollow noreferrer">branch by abstraction</a>:</li>
  </ul>
  
  <blockquote>
    <p>"Branch by Abstraction" is a technique <a href="https://martinfowler.com/bliki/BranchByAbstraction.html#footnote-coin" rel="nofollow noreferrer">[1]</a> for making a
    large-scale change to a software system in gradual way that allows you
    to release the system regularly while the change is still in-progress.</p>
  </blockquote>
  
  <p>These would allow merging a feature in develop/master at any time, without the feature being actually (completed/functional and) enabled. </p>
  
  <p>If technically these are implemented using configurable means then at any time the software can be tested both with and without a feature enabled, simply by flipping the config flag in the respective test environment. Otherwise special builds may be needed to enable them (still a lot easier than doing a branch merge with the feature's full/partial code).</p>
  
  <p>And you could then run all your feature testing in develop/master to get your features enabled, one at a time.</p>
  
  <p>But if you go in this direction - why would you even struggle with git_flow and run into all these problems? Just go TBD and CI/CD all the way :) </p>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-25T21:30:51.730Z
Answers: this is how I have seem big teams work. the only thing that was slightly annoying isn't at the feature toggled for small changes were easy to clean up but the feature toggled for larger features tended to leave "surgery scars" and dead code paths behind after the features were switched on (but the toggle left around for "just in case". so you have to apply a lot of disapline (eg each feature flag as an expiry date" that in some way forces you to clear out the old code)
Answers: simbo1905
Answers: CC BY-SA 4.0
Answers: 2019-01-26T03:46:50.590Z
Answers: @simbo1905 Yep, I saw that, too. Partially a matter of discipline, indeed, but I often saw cleanup efforts losing ground/falling off the priority list - typically not under developers' control in larger teams. Still, all things considered, some dead code is nothing compared to branch spaghetti and integration Hell ;)
Answers: Dan Cornilescu
Answers: CC BY-SA 4.0
Answers: 2019-01-23T16:46:18.323Z
Answers: 2019-01-26T03:48:46.433Z
Answers: 2019-01-26T03:48:46.433Z
Answers: Dan Cornilescu
Body: <p>Our current software deployment lifecycle looks like this (using git-flow); </p>
  
  <ol>
  <li><p>We test locally or on a development environment.</p></li>
  <li><p>We submit a pull-request to merge the feature into the develop
  branch</p></li>
  <li><p>Our testers test the feature.</p></li>
  <li><p>** If rejected ** we create a new bugfix, which we test locally and submit a new pull-request to merge with the develop branch.</p></li>
  <li><p>At the end of the sprint we create a release from the develop branch.</p></li>
  <li><p>Deploy the release to the acceptation environment.</p></li>
  <li><p>** When accepted by all the stakeholders **  We finish the release, thus merging the release branch into the master branch.</p></li>
  <li><p>The master branch is then deployed to the production environment.</p></li>
  </ol>
  
  <p>This used to work fine, but now we’re forced to create a new release at the end of each sprint, which means that the develop branch might contain  rejected features awaiting a bugfix at the time of release.</p>
  
  <p>To make it more complicated, we have two repositories, one for front-end and one for back-end and they have to be in sync. i.e. our front-end cannot contain features dependent on, an api endpoint that has been rejected by a tester and won't be finished before the release. </p>
  
  <p>I'm at a loss and could really use some advice. </p>
  
  <p>[<em>Sorry for the long comment, but I thought this question needed some context.</em>]</p>
  
Tags: <continuous-integration><dtap>
Title: How to deal with untested features in the develop branch before deployment?
UserDisplayName: Wietse de Vries
ThreadText: # How to deal with untested features in the develop branch before deployment?
  
  (Asked by: username_0 on 2019-01-22)
  
  Our current software deployment lifecycle looks like this (using git-flow);
  
  1. We test locally or on a development environment.
  2. We submit a pull-request to merge the feature into the develop
     branch
  3. Our testers test the feature.
  4. \*\* If rejected \*\* we create a new bugfix, which we test locally and submit a new pull-request to merge with the develop branch.
  5. At the end of the sprint we create a release from the develop branch.
  6. Deploy the release to the acceptation environment.
  7. \*\* When accepted by all the stakeholders \*\* We finish the release, thus merging the release branch into the master branch.
  8. The master branch is then deployed to the production environment.
  
  This used to work fine, but now we’re forced to create a new release at the end of each sprint, which means that the develop branch might contain rejected features awaiting a bugfix at the time of release.
  
  To make it more complicated, we have two repositories, one for front-end and one for back-end and they have to be in sync. i.e. our front-end cannot contain features dependent on, an api endpoint that has been rejected by a tester and won't be finished before the release.
  
  I'm at a loss and could really use some advice.
  
  [*Sorry for the long comment, but I thought this question needed some context.*]
  
  **Tags:** continuous-integration, dtap
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-01-23. Score: 2 | Accepted answer
  
  You could use the same tools used in Trunk Based Development (TBD) to carry work-in-progress in the trunk (the only non-release TBD branch with a longer lifespan):
  
  * [feature-toggles](/questions/tagged/feature-toggles "show questions tagged 'feature-toggles'")/[feature-flags](/questions/tagged/feature-flags "show questions tagged 'feature-flags'")
  * [branch by abstraction](https://martinfowler.com/bliki/BranchByAbstraction.html):
  
  > "Branch by Abstraction" is a technique [[1]](https://martinfowler.com/bliki/BranchByAbstraction.html#footnote-coin) for making a
  > large-scale change to a software system in gradual way that allows you
  > to release the system regularly while the change is still in-progress.
  
  These would allow merging a feature in develop/master at any time, without the feature being actually (completed/functional and) enabled.
  
  If technically these are implemented using configurable means then at any time the software can be tested both with and without a feature enabled, simply by flipping the config flag in the respective test environment. Otherwise special builds may be needed to enable them (still a lot easier than doing a branch merge with the feature's full/partial code).
  
  And you could then run all your feature testing in develop/master to get your features enabled, one at a time.
  
  But if you go in this direction - why would you even struggle with git\_flow and run into all these problems? Just go TBD and CI/CD all the way :)
  
  > **Comments:**
  > **username_2**: this is how I have seem big teams work. the only thing that was slightly annoying isn't at the feature toggled for small changes were easy to clean up but the feature toggled for larger features tended to leave "surgery scars" and dead code paths behind after the features were switched on (but the toggle left around for "just in case". so you have to apply a lot of disapline (eg each feature flag as an expiry date" that in some way forces you to clear out the old code)  
  > **username_1**: @username_2 Yep, I saw that, too. Partially a matter of discipline, indeed, but I often saw cleanup efforts losing ground/falling off the priority list - typically not under developers' control in larger teams. Still, all things considered, some dead code is nothing compared to branch spaghetti and integration Hell ;)  
  
  ---
  
  