trunk based development (TBD) for apps

Reading through a few articles and tweets related to TBD⚡️, I cannot avoid taking this to my own field (📱 app development), stretch my arms and fingers and publish a note on this.

So, what is TBD?

Trunk based development is:

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. They therefore avoid merge hell, do not break the build, and live happily ever after.

Reading through it you can perceive the evil 👹 side of over-structured branching models (like git flow) for your source control and you will probably start considering concepts like branch by abstraction 🧙‍♂️, feature flags 🚩 and how to adapt your CI/CD process ♻️ to use TBD⚡️ workflow.

Let’s review together some of the key things.

Feature flags 🚩

Feature flags concept is noting new or attached specifically to TBD⚡️ but you’ll need to start using feature flags it if you want to move to TBD⚡️.

When everyone collaborates in a single branch you need a mechanism to hide or fade out those sections that are under current development.

The release process in apps is of special relevance due to the difficulty of making your users get the new code.

It’s not new that the iOS store requires a review process that can take up to 3 days⏳(Android does not), but in both, once you “release” can last up to 1 week to get >90% of your users in the new version.

Adopting feature flags 🚩 will help you try new code and change it back on the fly if something goes really wrong

Additionally you’ll also love it because it increases your code quality by forcing decoupling, and enables natively your product A/B testing capabilities.

Branch by abstraction 🧙‍♂️

Branch by abstraction is a way of performing changes incrementally, needed for TBD⚡️ because it helps merging “work in progress” changes 🚧 in trunk and keep it stable.

The basic idea is to abstract the current implementation, swapping it with a new one in a small series of releasable changes at each stage.

This simple concept is quite easy to apply and will help you have a less coupled code 🏚 and get feedback in the “work in progress” changes 🚧 sooner and more often.

All this benefits are inherent to concepts like Clean architecture or SOLID design principles but even though branch by abstraction is a must-do in any team that wants to encourage excellence and improve collaboration despite the desire of adopting TBD⚡️

Conclusions

Given the benefits described above and the app release madness ⏳ most of the improvements you’ll notice with TBD⚡️ are related or direct consequence of that, like:

• Less coupled code 🏚
• Better code review process 👀
• Avoid evil feature branches 👹
• Leaner CI/CD process ♻️
• Safer, quicker and sooner release 🚀

While working in other technologies releasing to trunk might mean to release in production.

In apps development that’s not the case, it’s necessary to state a clear release policy 🚀.

When you release your app, you’re not just phased out a week of >90% of your users getting the new changes, you’re also forcing them to download dozen if not hundreds of MB on every update, you cannot simply release on every change merged in trunk.

If you’re adopting TBD⚡️ you’ll need to make your release process periodic ⏲ (maybe aligned with your sprint planning) so whatever is in trunk in time gets released 🚀, it’ll help you keeping a constant release pacing, which will lead to a more engaged team around it increasing the team feeling of fulfillment by seeing the impact of their work more often and forcing you to test sooner.

However, trunk branch becomes more important and you’ll need to have a high commitment towards automating checks in that branch to ensure it’s stability.

In any case you’ll need to agree on when to release automatically and how to block it, how to release manually if needed, but more important is create a set of automated checks in trunk to ensure it’s stability. If possible, before merging any PR to It.

TL;DR — LOL 😂

There are several valid points on TBD ⚡️and everything that surrounds it, like feature flags 🚩, branch by abstraction 🧙‍♂️, increase in collaboration 📣, cleaner code and simpler CI/CD process ♻️

My conclusion is that nothing stops you from adopting this now for your apps development process, just setting harder checks for trunk stability and the fear to the unknown.

Articles related:

• trunkbaseddevelopment.com
• Feature toogles from Martin Fowler
• Branch by abstraction from ContinuousDelivery.com
• trunk based development from ThoughtWorks
• Why feature branching is evil from Guillem CANAL

trunk based development (TBD) for apps was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.