The advent of Git brought a new era to software development. As a consequence, new approaches to developing applications were discovered. One of them is Gitflow, a development model based on branches. However, the integration part of the work exhibits a series of challenges regarding how developers get feedback, their frequency and the time phase.
As opposed to Branch Based Development, Trunk-Based Development (TBD) assumes no stages (or almost none) and tries to avoid conflicts by living close to where the source of truth is. It is a way to support fast-moving organisations and bring back the agile dilemma to the customer's collaborative response to change at its core. Ultimately, the goal is to get the most value in production and not in the staging environment.
TBD is much older that you may think. It can be traced back to CVS (Concurrent Version System) and SVN (Subversion) where the prominent philosophy was “Everyone is on one trunk, with occasional short-lived branches for bug-fixing or experimental development”.
In fact, many authors in the 1990´s, including Jez Humble, the co-author of 'The DevOps Handbook', 'Lean Enterprise', and 'Continuous Delivery', talked about Version Control and the need for getting fast feedback by avoiding long-lived branches. This is just one example to show that TBD is not a new concept.
The following list is an opinion-based collection of practices essential to implementing TBD in your team. Some of them might be already incorporated into your day-to-day workflow. Still, others might be a novelty to you - in any case, feel free to try them out and give us your feedback.
Let's get started!
First and foremost, it would be best to reach specific agreements with the team to have TBD running and adopt the following practices. After all, if the team is not happy, it will most likely fail.
A Trunk-Based Development environment is characterised by having a trustworthy CI/CD pipeline in place. This will allow the team to find issues earlier in the development process due to the shorter feedback loop. Not to mention that automation facilitates rapid change across the code base, making the process more efficient. Without automation, the TBD process becomes more challenging and less impactful.
In the cloud era, opting for a blue-green deployment for TBD is highly recommended, although other approaches, like canary also, are effective as well. The ultimate goal is to establish a secure environment for continuous releases, ensuring a smooth experience for end users without disruptions.
Toggles are a developers' new best friends as they enable the incorporation of changes without a big bang release. Additionally, toggles facilitate continuous integration of work in progress, becoming a crucial turning point in one's feature development approach.
Various third-party tools are available to enable developers to toggle features on/off seamlessly; however, the tried-and-true method of using old plan environment variables can also be used.
The trick is to always start with the toggle off. In fact, pushing just the set of the toggle is a good initial step. The second step involves confirming if it works as expected and iterating from there.
Toggles offer a more agile approach to work: once the toggle is set and working, changes are integrated faster and without fear of breaking things, or breaking things in a much more controlled way. You have the option of enabling the toggle for only a few users if needed.
TBD facilitates a reduction in batch size, ensuring a smoother flow of work throughout the development process.
Constant work in progress is the prevailing Modus Operandi for TBD. There is no perfect time to integrate changes or push things to production. By following this philosophy, teams no longer require code freezes to meet and review large changes - therefore eliminating any downtime associated with integrating new modifications.
Demos and user input can take place directly in the production environment, where it truly matters.
When it comes to monitoring, logging is essential. It allows you to monitor any spikes and mitigate any potential issues that may arise while doing TBD. Logging should be a fundamental aspect for any application, but it becomes even more critical in the context of TBD.
A short-lived branch is a temporary branch created for a specific task, intended to live less than a feature branch and to be pushed by the end of the day. While the primary focus of pure TBD is to push directly to trunk, these short-lived branches can be useful for testing, bug-fixing or saving work at the end of the day or when switching roles during pairing sessions. If needed, these branches can be merged back into the trunk by creating a "pull request."
The key aspect of this practice lies in the size of the branch's file before it is merged and eventually deleted due to its staleness. As a rule of thumb, they should never live longer than 48h, as extending their lifespan can convert them into feature branches, which contradicts the main objective of TBD. Typically, 1 developer (or 2 when pairing) should be responsible for contributing to these branches.
It is ok to merge code from the trunk to the branch to bring them closer, but merging the branch back into the trunk should be regarded as the final step in completing that small feature. Once this merge is done, the branch should be deleted.
As the entire team works mainly on the same branch, the potential risk of conflicts increases. To mitigate this issue, consider pushing smaller chunks of code and pulling more often. Also, keep in mind that communication among team members is important. Just by trying to avoid coding on the same piece of code at the same time you can reduce the likelihood of encountering of unwanted conflict and merging.
Having a lot of developers working on the same codebase can also create conflicts. Consider splitting the teams and/or the applications in microservices or smaller packages if needed.
Despite the hype surrounding TBD and the numerous benefits it offers to agile teams, resistance to shift still persists.
Over the past decade, developers have been ''trained'' to adhere to different environments in order to complete several tasks, such as development, quality assurance, and production. When presented with the option of switching to TBD, some resistance inevitably arises, as the fear of impacting production affects all developers no matter their domain. This highlights the importance of considering the human aspect of software development, especially in fast-paced, ever-changing environments.
Extreme Programming, with its set of values, provides the necessary foundation for high-performance teams. When Kent Beck, creator of XP, released the second edition of the book, he introduced the value of respect, alongside feedback, simplicity, communication, and courage.
Many teams across the industry lack the courage and respect required to adopt practices like TBD. However, our advice is that if you ever get the chance to try and experiment with this approach, you should seize the opportunity to explore its potential.
This blog was collaboratively written by Matheus Marabesi, Fernando del Caz, Javier Chacana and Arturo Menéndez. If you'd like to know more about them, check out Our People's page.
As a CTO, your daily responsibilities revolve around making informed decisions to guide your team and achieve strategic business objectives. However,..
In today’s competitive business environment, the quality of software and systems supporting operations is crucial for achieving positive business..
If you're new to Test-Driven Development (TDD) and eager to integrate it into your projects, you've come to the right place. Here's a step-by-step..
Join our newsletter for expert tips and inspirational case studies
Join our newsletter for expert tips and inspirational case studies
