Menu
At my company we have a CI/Build server that we use to test and build releases (as well as features and the develop branch). In the git flow branching model when it is time to release you branch off develop and name it (for instance) release-1.4. The CI/Build server would then automatically build the branch and we would deploy it to a staging server for manual integration testing. Once we are satisfied with the build we would like to deploy it. But in the git flow branching model we need to merge to master and tag first. The question is, do we need to run another build and test cycle after this merge or what?
It seems weird to merge and tag ending up with the tag pointing at a different (technically) commit than the release was built off of. It also seems bad to rebuild after we get into master because we would then feel compelled to test that build to make sure it is ok too.
The options I've come up with are:
352
As a general rule, when merging a pull request from a feature branch with a messy commit history, you should squash your commits. There are exceptions, but in most cases, squashing results in a cleaner Git history that's easier for the team to read.
Once all the testing is completed and it is ready to be promoted in production then you need to first merge your release branch with master and then later with develop. So the next time, when you are working on a hotfix or on a release or feature then you can start working by just creating a branch from develop.
A separate merge of the Gitflow release branch into the develop branch is also required. This ensures that any fixes made to the release after the initial branching make it back into development. The Gitflow release branch is made from the develop branch and gets merged into both master and develop when finished.
The question is, do we need to run another build and test cycle after this merge or what?
That merge shouldn't break anything because it should be a fast-forward merge, all the commits on master are on the release branch. Therefore, you can not create a bug on master post-merge that wasn't on the release branch.
So technically yes, it isn't the precise commit you built, but the philosophy is that everything on the master branch is in production. At anytime, if someone pulls the master branch he should get the current production code. That's why you don't merge and then build, and test, and wait, and fix things on master for a release.
Now things does not always go smoothly. By the time the release has been validated and is ready to ship, you may have encounter major production bugs that needed a hotfix, in that case some commits have been pushed to master and develop but not to the release branch. If this happens, I'd rebase (be careful with that when working in team, merge is safer) the release branch on develop (to catch up with the hotfixes) and rebuild again. To sum up, if there are no hotfixes between the time the release branch was created and the time it is validated, no need to rebuild.
79
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
