Trunks are not just for trees: from git flow to trunk-based development

Ask yourself, what happens if someone accidentally deployed your master branch to production?

First we implemented…

SafetyCulture has a long-standing tradition of using the git flow branching model. Spotlight, being a new team, we did not want to break tradition, and this is what we found: git flow is a perfectly good model, but it comes with its challenges in a dynamic, collaborative environment such as SafetyCulture. It can have a severe impact on testing and inherently gives testing the dreaded stigma of being the bottleneck.

Not only were we a new team trying to get valuable features and fixes quickly into the hands of customers; we were not practicing continuous delivery, which is something most organisation aim to achieve.

git flow implementation

Some of the limitations we faced using this model include:

1. Deployment to production: Let’s go to prod, yay…. More like nay. An unpredictable develop branch made it impossible to hit our delivery goals. We felt bound by the two week sprint but always ran over, which was not good for team morale.
2. Testing in isolation: With multiple features being developed, it was difficult to analyse the impact and risk of what was in develop, as confidence in the quality of the code base was low.
3. Regression testing became a nightmare: Whilst testing what was in develop, something else was merged so back to the drawing board.
4. Automation: It was difficult to find time for automation and automated tasks.
5. Feature segregation: We could not separate and cherry-pick features to deploy to production.

Yet we continued… everything was fine. Until it wasn’t.

…then we iterated

Something had to change, we then made the decision to try trunk-based development.

Yay, solution to our problems…… it wasn’t. Well not immediately.

The trunk-based model was not a direct replacement for git flow. We had to be smart about embracing the model by changing our way of working.

1. Stories and Tasks: Creating small deliverable tasks that deliver customer value allowed us to develop isolated feature branches that could be completed and pushed to production once verified and validated.
2. Quality as a process: We could now focus on the different aspects of quality. As a team we started to test from requirements, to design, all the way to delivery and post production monitoring. No more just testing at the end.
3. Testing with confidence: We could validate a feature in its branch before merging it to master and be confident that is was ready for production.
4. Regression testing: It was now easier to perform regression testing once a feature or change was completed.
5. Automation: Automated activities improved and they were done in small chunks as part of each story or change. This increased coverage and increased confidence when changes were made.
6. End-to-end solution: This approach was also applied to the backend microservices, tested, validated and deployed together.
7. Continuous delivery: We could now deploy to production whenever a feature or fix was complete.

We went from deploying every few weeks to a few times a week.

trunk-based implementation

In the end

Trunk-based development was a change to the team’s way of working that allowed them to think iteratively and work in small branches and commits. This improved the overall quality of the product as it allowed the team to focus, unpack and understand the functionality and complexities involved to deliver a feature.

It made the team more flexible; we can analyse and hypothesize customer needs, deliver it iteratively, measure and then reevaluate. It allowed (and continues to allow) us to test more effectively and increase confidence when deploying to production. We can release master at any time if all the checks and balances are followed. It is now becoming the new tradition at SafetyCulture.

Keen to be part of a autonomous team that builds products that impact lives? Think about a career at SafetyCulture.