DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. Join them; it only takes a minute:

Our current software deployment lifecycle looks like this (using git-flow);

We test locally or on a development environment.

We submit a pull-request to merge the feature into the develop
branch

Our testers test the feature.

** If rejected ** we create a new bugfix, which we test locally and submit a new pull-request to merge with the develop branch.

At the end of the sprint we create a release from the develop branch.

Deploy the release to the acceptation environment.

** When accepted by all the stakeholders ** We finish the release, thus merging the release branch into the master branch.

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

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

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)
– simbo1905Jan 25 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 CornilescuJan 26 at 3:46