snippetMinor
How to deal with untested features in the develop branch before deployment?
Viewed 0 times
thebeforehowwithdevelopuntestedfeaturesbranchdeploymentdeal
Problem
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.]
-
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.]
Solution
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 :)
- feature-toggles/feature-flags
- branch by abstraction:
"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 :)
Context
StackExchange DevOps Q#6070, answer score: 2
Revisions (0)
No revisions yet.