Effective GIT Branching Strategy

Question

I am trying to figure out the optimal branching strategy for my organization. And I have few doubts.

We have 3 main environments, Live(Production), UAT (pre-release) and Staging. Similary in GIT we have 2 Major branches. Master(State of Prod) , and Dev.

Developers start with checking out Git Dev and creating a feature branch from it. Suppose they developed feature F1, F2 and F3. And once they are happy with it they merged those feature back in DEV. A CI job deploys DEV code to our Staging environment.

Staging environment is where QA Tests. Lets assume QA Approves F1 and F3 and rejects F2. Now I want to move only F1 and F3 to the Release Branch. Release branch is auto deployed to UAT where end user can have sanity tests or user training for new release.

Now my question is should I create Release Branch from Master and Merge F1 and F3 into it? Or Stick with creating Release Branch from Dev? I am more inclined about creating release branch from Master as I dont have to revert F2 from Dev.

Can anyone help me out with this dilemma?

Answer 1

Feature Branches

• Do not merge into dev for deployment.
• deploy a feature branch
• only deploy feature branches which have a fast-forward only merge from the tip of the dev branch.
• every deployment burns the test environment to the ground, (with the possible exception of deploying from the the same "feature" branch).
• QA sign off, is the quality gate for allowing a feature to deploy to UAT.
• Only with QA and UAT signoff does a feature move to dev for deployment
• Essentially dev represents the next releasable product.

Obviously there are a number of issues with this.

• QA and UAT must signoff before merging
• Big bang merges.
• All other features must re-undergo QA/UAT as merges will likely introduce bugs.
• The problem has been pushed one branch deeper, how do you efficiently merge "feature" branches.
• The QA systems only every see "feature" branches, unless double deployments are done.

Feature Toggles

• All dev work is done on the dev branch.
• The dev branch is releasable at anytime.
• This implies that every commit passes all current unit/integration/other automated tests.
• Features are guarded by "feature toggles" with each toggle supplied by a configuration file with the default of being disabled.
• Progression tests can be associated with the toggle, when all are defined and green the "feature" is deployable.
• QA, and UAT can accept a feature by updating the deployment configuration file
• Production can rollback a feature by toggling it in the configuration.

Obviously there are a number of issues with this:

• Diligence to cleanup and not reuse old feature toggles to prevent incidents like those that afflicted Knight Capital.
• Issues determining dead code form not yet enabled features.
• Increased Risks associated with features controlled by configuration.

Use Both

Personally use both techniques in-so-far as they are more a benefit than a hindrance.

If something is risky, and probably won't make the code-base. Feature Branches are your friend. Should it not work out, which is the admitted potential, the branch can be discard with no further issues. The big-bang merge is a problem, but that can be avoided more-or-less by daily pulls from the development branch into the feature branch.

In contrast Feature toggles are great for low-risk changes, new functionality, or decommissioning functionality. Low-risk changes by definition usually cosmetic, or on the periphery of the system core, so switching them on and off is reasonably safe even when toggled incorrectly. New Functionality, and functionality decommissioning are also good examples as they allow a border to be constructed between good and bad parts of the system, permitting a change back to before as necessary.