Frequent Feature Deployments with large teams

tl;dr : If you want to do regular feature releases multiple times a day with a large team, just go with Trunk based development.

Not many people realise that their git branching strategy plays a very important role in their ability to do daily deployments in a consistent manner.

I’ve seen most teams follow the widely popular GitFlow which advocates having a master and develop branch and creating feature branches off develop and merging them back into develop. Once a release is cut out from develop, its released to production and merged into master. The problem with GitFlow is, it doesn’t quite allow you to create small features releases, that can be deployed frequently but there is also a bit of a cognitive overload when you are working on a feature vs a hot fix. Where if its a feature you branch off develop but if its a hotfix you branch off master, and every hotfix needs to be merged into master and develop.

To be able to deploy frequently one needs a far simpler Git branching strategy and that’s where GitHubFlow or Trunk based development comes in.

Trunk Based Development

Trunk based development is a highly simplified and efficient branching strategy to help teams move faster and deploy more frequently.

Trunk based development mandates we have a single master branch, and we branch off master to create our feature branches.

For Trunk based development to be really successful one needs to realise that there is one subtle but very important difference in the workflow before you go live and after you have done your first production deployment.

During Active Development

When the project is in an active development phase, team members create feature branches and merge back into mater once the PR has been approved.

As part of your CI builds you are probably running a bunch of automated unit tests on every PR before it gets merged into master and you are also hopefully running a suite of Integration and end to end tests nightly on your master branch. This is to ensure if something is broken in master the team is alerted at the earliest.

After first release

What’s important to keep in mind is once your first cut of master is released to production, then the merging strategy changes a bit.

The teams continue to create feature branches, branching off master like before, however once the feature release has been tested and signed off, you would release it directly from the feature branch into production, and only when the release is stable in production, is when you merge that feature branch into master.

Some of the benefits of following this process are:

• The master branch is always in sync with the stable & current version in production.
• In case the team finds any glitches or minor issues during a feature deployment, they have an opportunity to fix forward, re-deploy the branch with the fixes, and get it to be stable before it can be merged into master.
• Since master always mimics the current version of production, the process to deploy a feature or a hot fix is exactly the same.
• When every merge it master is always after a release, there is little to no chance of master being broken. A broken master can bring a large development team to a halt.

With Trunk based development there are 2 important things to keep in mind.

• Make sure you have rebased from Master one last time just before you deploy your feature branch. This is to make sure your feature branch contains all the previous deployments that have gone out while you were working on your feature.
• DO NOT Squash and Merge your PR into master. This is something we learnt the hard way. When using github, we commonly use the Squash and merge option while merging PRs into develop or say our feature branch, which is a good thing, However, after you have released your feature to production and you want to merge your feature into Master, always use the Create a Merge Commit option. This will ensure that other teams don’t land up with conflicts when they rebase master the next time after your release has been merged.

A lot of people think Trunk based development is meant for small 2–3 member teams, when infact we’ve seen and realised it is far more suited for large teams that work in small squads or pods.

So go ahead and give Trunk based Development a try and let me know how it goes.