Trunk-based development

Learn why this version control management practice is common practice among DevOps teams.

Kev Zettler Kev Zettler

Résumé : le développement basé sur le tronc est une pratique de contrôle de version où les développeurs mergent de petites mises à jour fréquentes vers un « tronc » principal ou une branche principale. Étant donné qu'il simplifie les phases de merge et d'intégration, il contribue à rendre possible la CI/CD et améliore la livraison de logiciels ainsi que les performances organisationnelles.

In the early days of software development, programmers didn’t have the luxury of modern version control systems. Rather, they developed two versions of their software concurrently as a means of tracking changes and reversing them if necessary. Over time, this process proved to be labor-intensive, costly, and inefficient.

As version control systems matured, various development styles emerged, enabling programmers to find bugs more easily, code in parallel with their colleagues, and accelerate release cadence. Today, most programmers leverage one of two development models to deliver quality software -- Gitflow and trunk-based development.

Gitflow, which was popularized first, is a stricter development model where only certain individuals can approve changes to the main code. This maintains code quality and minimizes the number of bugs. Trunk-based development is a more open model since all developers have access to the main code. This enables teams to iterate quickly and implement CI/CD.

What is trunk-based development?

Gitflow vs. trunk-based development

Benefits of trunk-based development

Allows continuous code integration

Le modèle de développement basé sur le tronc utilise un dépôt avec un flux régulier de commits vers la branche principale. L'ajout d'une suite de tests automatisés et d'une surveillance de la couverture de code pour ce flux de commits ouvre la voie à l'intégration continue. Lorsque le nouveau code est mergé dans le tronc, des tests automatisés d'intégration et de couverture de code s'exécutent pour valider la qualité du code.

Ensures continuous code review

The rapid, small commits of trunk-based development make code review a more efficient process. With small branches, developers can quickly see and review small changes. This is far easier compared to a long-lived feature branch where a reviewer reads pages of code or manually inspects a large surface area of code changes.

Enables consecutive production code releases

Les équipes doivent effectuer des merges quotidiens fréquents dans la branche principale. Le développement basé sur le tronc s'efforce de garder la branche « trunk » fonctionnelle, ce qui signifie qu'elle est prête à être déployée à chaque commit. Des tests automatisés, la convergence du code et les revues de code permettent de garantir qu'un projet de développement basé sur le tronc est prêt à être déployé en production à tout moment. L'équipe peut ainsi déployer fréquemment en production et fixer d'autres objectifs pour les livraisons en production quotidiennes.

Trunk-based development and CI/CD

As CI/CD grew in popularity, branching models were refined and optimized, leading to the rise of trunk-based development. Now, trunk-based development is a requirement of continuous integration. With continuous integration, developers perform trunk-based development in conjunction with automated tests that run after each committee to a trunk. This ensures the project works at all times.

Trunk-based development best practices

Trunk-based development ensures teams release code quickly and consistently. The following is a list of exercises and practices that will help refine your team's cadence and develop an optimized release schedule.

Develop in small batches

Trunk-based development follows a quick rhythm to deliver code to production. If trunk-based development was like music it would be a rapid staccato -- short, succinct notes in rapid succession, with the repository commits being the notes. Keeping commits and branches small allows for a more rapid tempo of merges and deployments.

Small changes of a couple of commits or modification of a few lines of code minimize cognitive overhead. It's much easier for teams to have meaningful conversations and make quick decisions when reviewing a limited area of code versus a sprawling set of changes.

Feature flags

Les feature flags complètent bien le développement basé sur le tronc en permettant aux développeurs d'encapsuler de nouveaux changements dans un chemin de code inactif et de l'activer ultérieurement. Les développeurs ne doivent ainsi pas créer une branche de fonctionnalité de dépôt distincte, et peuvent directement commiter le code des nouvelles fonctionnalités dans la branche principale, sans chemin de feature flag.

Feature flags directly encourage small batch updates. Instead of creating a feature branch and waiting to build out the complete specification, developers can instead create a trunk commit that introduces the feature flag and pushes new trunk commits that build out the feature specification within the flag.

Implement comprehensive automated testing

Automated testing is necessary for any modern software project intending to achieve CI/CD. There are multiple types of automated tests that run at different stages of the release pipeline. Short running unit and integration tests are executed during development and upon code merge. Longer running, full stack, end-to-end tests are run in later pipeline phases against a full staging or production environment.

Automated tests help trunk-based development by maintaining a small batch rhythm as developers merge new commits. The automated test suite reviews the code for any issues and automatically approves or denies it. This helps developers rapidly create commits and run them through automated tests to see if they introduce any new issues.

Perform asynchronous code reviews

In trunk-based development, code review should be performed immediately and not put into an asynchronous system for later review. Automated tests provide a layer of preemptive code review. When developers are ready to review a team member's pull request, they can first check that the automated tests passed and the code coverage has increased. This gives the reviewer immediate reassurance that the new code meets certain specifications. The reviewer can then focus on optimizations.

Have three or fewer active branches in the application's code repository

Once a branch merges, it is best practice to delete it. A repository with a large amount of active branches has some unfortunate side effects. While it can be beneficial for teams to see what work is in progress by examining active branches, this benefit is lost if there are stale and inactive branches still around. Some developers use Git user interfaces that may become unwieldy to work with when loading a large number of remote branches.

Merge branches to the trunk at least once a day

Les équipes ultra performantes s'appuyant sur le développement basé sur le tronc doivent fermer et merger toutes les branches ouvertes et prêtes à être mergées au moins une fois par jour. Cet exercice aide à maintenir la dynamique et établit une cadence pour le suivi des versions. À la fin de la journée, l'équipe peut alors étiqueter le tronc principal en tant que commit de livraison, ce qui a pour effet secondaire de générer un incrément de livraison Agile.

Reduced number of code freezes and integration phases

Agile CI/CD teams shouldn’t need planned code freezes or pauses for integration phases -- although an organization may need them for other reasons. The “continuous” in CI/CD implies that updates are constantly flowing. Trunk-based development teams should try to avoid blocking code freezes and plan accordingly to ensure the release pipeline is not stalled.

Build fast and execute immediately

In order to maintain a quick release cadence, build and test execution times should be optimized. CI/CD build tools should use caching layers where appropriate to avoid expensive computations for static. Tests should be optimized to use appropriate stubs for third-party services.

Conclusion…

Trunk-based development is currently the standard for high-performing engineering teams since it sets and maintains a software release cadence by using a simplified Git branching strategy. Plus, trunk-based development gives engineering teams more flexibility and control over how they deliver software to the end user.