Reading through a few articles and tweets related to TBD⚡️, I cannot avoid taking this to my own field (📱 ), stretch my arms and fingers and publish a note on this. app development So, what is TBD? 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. 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 ) for your source control and you will probably start considering concepts like and how to adapt your CI/CD process ♻️ to use ⚡️ git flow branch by abstraction 🧙‍♂️, feature flags 🚩 TBD workflow. Let’s review together some of the key things. Feature flags 🚩 Feature flags concept or attached specifically to TBD⚡️ is noting new 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 🚩 will help you try new code and change it back on the fly if something goes really wrong feature flags 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 🧙‍♂️ is a way of , needed for TBD⚡️ because it helps merging “work in progress” changes 🚧 in trunk and keep it stable. Branch by abstraction performing changes incrementally 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 or 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⚡️ Clean architecture SOLID 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 🚩, 🧙‍♂️, 📣, cleaner code and simpler CI/CD process ♻️ feature flags branch by abstraction increase in collaboration 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 from Feature toogles Martin Fowler from Branch by abstraction ContinuousDelivery.com from trunk based development ThoughtWorks from Why feature branching is evil Guillem CANAL

Flow

trunk based development (TBD) for apps

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

10 Creative Ways to Use OTG Adapter with Smartphones

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

10 Creative Ways to Use OTG Adapter with Smartphones

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps