Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Streamlining Mobile App Delivery with Trunk-Bas...

Leeds Mobile
November 22, 2023

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.

Leeds Mobile

November 22, 2023
Tweet

More Decks by Leeds Mobile

Other Decks in Programming

Transcript

  1. 📈 Reduce time to merge 💪 Improve your codebase stability

    🚀 Deploy more frequently ⏱ Deliver features faster
  2. Developing features with long-lived branches Engineers build new features here

    sometimes over weeks Builds released here Code review happens here Testing performed here
  3. 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
  4. Continuously deploy and test production code Feature fl ag creation

    Incremental changes Testing done here Release here Deploy here
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. Changes don’t have to be ready for production, we actively

    encourage small iterative changes… Even if they’re un fi nished
  11. 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
  12. 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
  13. 🤔 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
  14. 🤔 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
  15. 🏅 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