Git Development vs Release branch best practices

Question

I have been monitoring two branches starting from each sprint - Release and Master.

Master branch is from where developers create new branch(task specific), implement their changes, and creates pull request which gets merged into the Master.

Release branch is sprint specific which remains always submittable to the production. We only merge branches committed to the Master and verified by the QA into Release branch.

This approach works best for us as we submit Release at fix regular interval with specific functionality implemented and verified, and hence we exactly know what's going in the next release.

This question is continuation of avoid-merging-master-into-development-branch and git-merging-only-branch-specific-commits

In one line I want to

"Make sure that only development branches which are verified by QA goes to the next Release Candidate."

I have thought of to use following workflow options from my previous discussions;

git pull --rebase master taskA
//Work on taskA branch, do multiple commits, and also execute this command multiple times whenever required;
At time of Rebasing taskA to Master
git checkout taskA
git rebase -i origin/Master // Remove any commits that are not belongs to taskA.
git checkout origin/master
git merge taskA

This workflow will give me clear history for each of my branches rebased on the Master which will be verified by QAs. I can easily rebase verified branch back to the Release branch.

Am I going in right direction? Would this git-flow works best? Is there any better way of doing what I want to achieve?

Answer 1

Here's your problem.

We only merge branches committed to the Master and verified by the QA into Release branch.

This means you have to integrate feature branches twice. Once into Master and again into Release. You're struggling with the obvious problem: how do you make sure everything integrated into Master is integrated into Release? And because features build on other features, they have to be in a similar order.

Don't try to solve this problem. It's hard and messy and you'll always have to be careful. Better to have a process that's more foolproof. Let's go back to your stated goal.

Make sure that only development branches which are verified by QA goes to the next Release Candidate.

(Emphasis mine) That's not really a goal, that's a solution to implement a goal. What's your real goal? How about this...

Make sure that only code which has been verified by QA goes to the next Release.

See what I did there? A quality release doesn't care about where the code came from, its cares about the state of the code being released. You want to make sure nothing that hasn't been checked by QA goes into the release. To do that, I would suggest changing your workflow to a version of the Gitflow Workflow. It goes like this.

1. Developer has a task to do.
2. Developer branches off master, let's call it task.
3. Developer works on task.
   1. Developer writes their own unit tests for the task.
4. Developer gets updates from master when they need them.
   1. They can rebase or they can merge, doesn't matter.
5. Developer finishes task.
   1. Developer does a final update from master.
   2. Developer makes sure their unit tests and all regression tests pass.
   3. Optional Developer submits the task to QA for acceptance testing.
   4. Developer merges into master.
   5. Developer deletes task.

Because developers are writing their own unit tests, at this point you know everything in master has been unit and integration tested. Some important or hairy features have been acceptance tested in 5.3, but generally you don't bother QA with that at this point.

It is very important to a healthy workflow that master is always kept in a state of high quality. This means developers have to be involved in the testing process. There's no throwing it over the wall to QA and hoping for the best, QA should be spending their time on acceptance and blackbox testing to catch bugs the developers will not think of. Master is always your Release Candidate.

When you decide you're ready for a release...

1. Match the testing branch to master.
   1. You can merge with master, rebase on master or delete and recreate the testing branch. They each have slight advantages and disadvantages which will become apparent.
2. QA gets a list of all changes which have been added since the last release.
   1. They can get this from the issue tracker.
   2. If testing is rebased off master they can git log and look at the merge commits since the last release.
3. Have QA acceptance test the change list against testing.

Let's pause here and explain why step 3 is important. QA is the final line before users see it. It's important that QA is testing what the users will actually use. Users will see the integrated code base, not individual feature branches working in isolation, so QA should focus their efforts on the integrated release.

Features can work great in isolation, and have weird bugs when they're combined. A simple example would be a feature which changes the project's encoding from ASCII to Unicode. The developer dutifully changes the whole system to use Unicode and it's great. Meanwhile another developer works on a task which includes changing some views. They're not thinking about character encoding, and they write their views with ASCII assumptions. Developers are horrible about testing views. Tested in isolation, but feature branches work fine. Combined together, QA can catch the view which is still using the wrong character encoding.

Moving on.

4. QA finds bugs and reports them back to the developers.
   1. Developers patch testing (directly for small things, in a branch for big things)
   2. Optional Developers cherry-pick those fixes back to master. It's optional because it will be taken care of later.
5. QA declares testing ready for release.
   1. release is git merge --ff-only testing. If it doesn't fast-forward, you have hotfixes in release which need to be backported.
   2. Tag release with a version number.
   3. release is pushed to production.
6. testing is merged back into master.

That final step ensures any patches to bugs found in the QA process will be merged back into master. This is why I said earlier it doesn't really matter how you reset testing, it will all be merged back into master anyway.

There you have it. A process for ensuring all code which is released has gone through QA. Except for developing the change log for QA, there is no careful tracking of what's been integrated where necessary.