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

Wietse de Vries
  • 123
  • 4

1 Answers1

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

Dan Cornilescu
  • 6,780
  • 2
  • 21
  • 45