Reputation: 159
First of all, I know very well about Gitflow, and try to push my team to follow it completely. However, operation team only allows to release the application version that QA certified. If we follow Gitflow, the release version should always come from master branch, but since QA tests release branch, they only certifies release candidates. In order to have QA certify master cut, they need to run another regression test which is why they are pushing back. All the release candidates have RC# in the version which is not good maven versions following major.minor.patch pattern.
My question is how to avoid extra regression test after merging release into master, before production release? Any advices are welcome. Thanks
Upvotes: 0
Views: 186
Reputation: 12295
master
represents what is currently in production. In gitflow you create a release
branch off of develop. QA would then test the release
branch. Once QA is happy, the release
branch is deployed and then merged to master
.
There should be nothing to test when you merge a release
branch to master
. It's already been tested.
But what's important is whenever master
is updated (by merging in release branches), you also need to merge master
into develop
. This way when you cut the next release
branch from develop
you know it has all of the code that has been deployed.
Upvotes: 2