Is Trunk-Based Development Still a Key to Success?

What is it?

Trunk-Based Development is key to enabling Continuous Integration and by extension, Continuous Delivery. Where developers collaborate on code in a single branch called 'trunk', resist any pressure to create other long-lived development branches by employing documented techniques. As a result, they avoid 'merge hell', do not break the build, and live happily ever after. 

But is it key to the success of your team?

We started with Conway's Law.

Specialised teams worked on code, configuration and content for the mobile app. Consequently, there were separate repos. These were released separately in choreographed steps by release teams. This segregation of work created teams that had significant gaps in engineering and automation skills. In the end, any team could become a bottleneck for any feature. 

Creating a culture of Trunk Development

The ship began turning when the company started a top-down transformation with an executive decision to operate using agile ways of working. It stimulated a persistent engineering effort to embrace CICD practices. The leadership team stayed committed to the success of the two transitions.

Although applying DevOps principles at scale demands inclusive technical solutions, it fundamentally depends on changing how people work. One of the most important cultural change needed for aligning the work across the organisation was to have all the squads continually integrating and testing their code in a production-like environment.

Benefits flow on.

As squads began to do so, they witnessed an easing of bottlenecks, a freeing of the mind to do things right the first time: 

• Always-releasable code: keeping the trunk stable with green builds, is decreed as the top job for everyone.
• Frequent releases: monthly release train.
• Eager PR merges - small story slices, no scary merges since long-running siloed feature branches are actively discouraged.
• Automated tests at PR merge. 
• Evolutionary design - incremental steps to the final goal, refactor on the go.
• Feature flag - protect release from untrusted contributors.
• Engineers own the release pipeline.
• Observability, Decoupled deployment and more.

Today, we are at the point where squads have become used to this way of working and cannot imagine working any other way.

Good, but not quite enough.

With frequent releases, engineers began making constant changes to the three repos. They needed all the code to come together when executing automated tests and during code-cut for production release. For this, they had to liaise with several squads across timezones. The synchronisation points between these repos became starkly painful. While they could ease it solely by process change and leadership enforcement, ideally, though, the strategic solution is to design a continuous integration process to help drive the required changes in behaviour.

Clearly, when engineers were creating and also releasing code, then placing together all code that changes together, would give them the autonomy needed to establish CI practices. Here's where having a Single Trunk shines. 

Easier said than done! It took a few releases to execute the merge of configuration and content with the mobile app code repo. 

Due to large team size, and the rate of commits, short-lived feature branches are preferred for code-review and checking the validity of the build before merging into the trunk. 

Alongside, we guided the impacted squads and stakeholders through the changing landscape by educating squads on the concepts of eager merge strategy for trunk development.

Value Unlocked.

Now, with Trunk Development, squads have become self-governing:

• Releases are cohesive. All moving parts go out together.
• PRs for all components are visible to all engineers, thus enabling sharing knowledge and engineering practices.
• All PRs are subject to the rigour and quality of the CI pipeline checks. 
• We've eliminated the stress of manually coordinating between teams, giving time back to the engineers.
• Tests truly give assurance in the end to end feature.
• We still retain the ability for out of cycle releases, but now these are automated too. 
• Automated pipelines that package and deploy.
• Slack notifications. 
• As a bonus, engineers can optimise and automate all manual checkpoints.
• They work across teams and Tribes if they need to, to automate CI steps.

Trunk development was a natural progression in our Continuous Delivery journey, by our long-lived product teams who build, own and operate services. Who focus on automation and demonstrate the inclination, capability and grit to learn and grow using the right mindsets and practices.

Now, is that the makings of a successful team? You tell me!