Brief Intro

• Who's heard of Trunk Based Development before? ✋
• All developers work on a single branch, committing multiple times per day

  • Requires good development practices

  • Drives Continuous Integration

  • Facilitates Continuous Deployment and Lean Experimentation

Many different workflows

• 🌊Waterfall
• 🐙Octopus Merge (or gitflow)
• 🌿Branch🌿per🌿feature🌿
• 🌳Trunk based development

💖🌳-Based Benefits💖

• Focus on quickly delivering great code and collaborating with peers rather than the process of shipping it
• Used exclusively by major software development shops that need not be named

What is Trunk Based Development?

A source-control branching model, 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, avoid merge hell, do not break the build, and live happily ever after.

-trunkbaseddevelopment.com

A source control branching model, where developers collaborate on code in a single branch

• 📚In contrast to Gitflow or branch-per-feature workflows..

• ✍️✍️✍️Commit directly on master (AKA trunk) with small and frequent changes

Resist any pressure to create other long-lived development branches

• 🕑Create short lived branches for the purposes of code review or CI runs

• ❌Promptly delete them when they are no longer needed (1-2 days, not weeks)

Easy to merge

• 🛣️Small & frequent commits minimize merge conflicts, even for deeper refactors

Never break the build

• ✔️🔍Each commit is atomic and includes tests that are run before merge, both locally and by CI

• ❌↩️If tests fail, the work can be automatically rolled back so others can continue to work while a fix is pursued.

Live Happily Ever After

• 🔀Avoid painstaking merges

• ✨Encourage refactors on the go

• ⏩Changes quickly made available for use and review by stakeholders and team members

• 🔁Shorten feedback loop to make bug fixes and tweaks

• 🌌Avoid scope creep and big bang releases

• 😌Less cognitive load - get things DONE DONE quicker

Dealing with large & complex stories

• 🔷▪️▪️By keeping story sizes small and breaking them down when possible
• 🚩By using feature flags to switch off code that is not yet feature complete
• 👁️By using techniques like branch by abstraction or strangulation 

Continuous Code Review

• ⏲️Quick turnaround time to minimize time till useful code can be deployed or shared with team. “Tens of minutes” is “acceptable” More than an hour or two impacts cycle times.

• 🙋‍♀️🙋‍♂️Pair programming also provides a mechanism for quick feedback and review of code and is often used rather than a Pull Request

Confidence in Testing

• 🗺️TDD if possible, but..
• 📐Follow the Test Pyramid
• 🔭Strong production monitoring and alerting a bonus for Continuous Delivery

Cutting a Release

• 🚒If following Continuous Delivery, possible to firehose commits to production
• ↗️Otherwise, use release branches from trunk can be used. Any bug fixes performed in trunk and cherry-picked to the release branch