Streamlining Mobile App Delivery with Trunk-Based Development by Patrick Powell

First talk from November 2023, by Patrick Powell

Join us for an insightful talk on Trunk-Based Development, a modern software development approach that promises to re-evaluate the way you build and deliver software. We will explore the principles, benefits, and best practices of trunk-based development, helping you understand how it can streamline your development process and accelerate the software delivery pipeline of your mobile apps.

Transcript

1. Streamlining Mobile App Delivery with Trunk-Based Development
2. Patrick Powell Technical Specialist Jaguar Land Rover
3. Mobile Apps at Jaguar Land Rover
4. Not just a branching strategy…
6. 📈 Reduce time to merge 💪 Improve your codebase stability 🚀 Deploy more frequently ⏱ Deliver features faster
7. The Trunk
8. Scaled Trunk-Based Development
9. What’s the difference?
10. No long-lived branches*
11. What’s wrong with my branches?
12. Developing features with long-lived branches Engineers build new features here sometimes over weeks Builds released here Code review happens here Testing performed here
13. Releasing with long-lived branches Release branch created from develop Release is readied from this branch Builds released from this branch to continuously test fi xes Once released is merged into main and develop
14. Replacing long-lived branches with feature fl ags deployment != release
15. Continuously deploy and test production code Feature fl ag creation Incremental changes Testing done here Release here Deploy here
16. Don’t break the build • Trunk should always be in a state to release • Commits into the trunk should never break the build • This goes beyond the build itself • Includes existing functionality • Automation is key for ensuring the build remains unbroken
17. How we implemented Trunk-Based Development
18. Why we wanted to adopt trunk-based development • Our code reviews were taking a long time (and a lot of effort!) • Distributing builds was complicated as we would release different types of builds depending on the type of branch • Managing releases was complicated and confusing • Low con fi dence in the stability of the main branch • Merge hell
19. Day to day Create a feature fl ag for new feature Small incremental changes here Raise merge request back into the trunk Incremental snapshot builds are deployed here for testing
20. Deployments The aim is that trunk should always be in a state to release We create a tag and release a release candidate to a staging track for fi nal validation Bug fi xes are merged directly into the trunk We use different tag syntaxes to determine where to deploy builds
21. Feature fl ags are your friend • We use feature fl ags to release features, not feature branches • Feature fl ags can be turned on for speci fi c segments of users • We can turn features on only for the engineers and testers working on a particular feature • We can also use feature fl ags as kill-switches in production or to create a concept of permissions • Feature fl ags are our safety net • https://martinfowler.com/articles/feature- toggles.html
23. Segmenting Users
24. Changes don’t have to be ready for production, we actively encourage small iterative changes… Even if they’re un fi nished
25. Feature fl ags allow us to continuously integrate changes into the production branch whilst being con fi dent we’re not going to break anything
26. Trunk-Based Development Engineers create feature fl ags to disable features that aren’t ready to release in the trunk Engineers create small incremental code changes Snapshot builds are released with every merge into the trunk When it’s time to release we tag the trunk which will deploy a build to the App/Play Store When we want to release a feature to customers we enable this feature fl ag in production
27. 🤔 So how’s it going?
28. 🤔 So how’s it going? • Our mean-time to merge pull requests reduced from 9 days to 1 day • We only release from the trunk • We aim for the trunk to always be in a state to release so creating releases is straight-forward. No more release branches, hot- fi xes etc • We always test the trunk so we have more con fi dence that our changes are stable. Feature fl ags provide us with a safety net • We are constantly integrating with production code
29. 🤔 So how’s it going? • More Code Reviews! But drastically smaller in size • Feature fl ags across multiple platforms requires effective communication • Required systemic adoption across the team • Effective tooling for feature fl agging is a must
30. 🏅 Making Trunk-Based Development Successful • Little and often merge requests - sweet spot < 300LoC • Comprehensive test suites - don’t break the build! • Feature fl ags, feature fl ags, feature fl ags • Don’t be scared of merging • Discipline and trust the process • Be open minded, things will go wrong at some point
31. 🙌 Thank you!
32. 🧐 Questions?