davy_wei
davy_wei

Reputation: 159

Gitflow branching strategy

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

Answers (1)

Philip Pittle
Philip Pittle

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

Related Questions