2

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.]

Improve this question

1 Answer 1

Reset to default
2

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):

"Branch by Abstraction" is a technique [1] 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 :)

Improve this answer
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)
    – simbo1905
    Commented Jan 25, 2019 at 21:30
  • 1
    @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 ;)
    – Dan Cornilescu
    Commented Jan 26, 2019 at 3:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.