Trunk-Based Development — définition, principes et travail dans une seule branche

Qu'est-ce que Trunk-Based Development ?

Trunk-Based Development (TBD) est une méthodologie de gestion de versions où tous les développeurs intègrent leurs modifications dans une seule branche principale (trunk, main ou master) plusieurs fois par jour. Contrairement à Git Flow avec ses branches de fonctionnalités à longue durée de vie, TBD minimise la durée de vie des branches à quelques heures, rarement à 1 à 2 jours. L'objectif principal est d'éviter « l'enfer de la fusion » (merge hell), lorsqu'une grosse fonctionnalité est fusionnée dans le trunk après des semaines de développement.

Selon Google Cloud DevOps, 2024, Trunk-Based Development est l'une des pratiques clés des équipes DevOps à haute performance. Le State of DevOps Report (Puppet, 2023) a montré que les équipes utilisant TBD récupèrent 30 % plus rapidement des pannes et rencontrent 50 % moins de défauts critiques en production. TBD est obligatoire pour Continuous Deployment.

Trunk-Based Development ne signifie pas que les développeurs commitent directement dans le trunk sans révision. Dans TBD, on utilise des branches de fonctionnalités de courte durée qui, après création d'un MR et une révision de code rapide (en quelques heures), sont fusionnées dans le trunk. Si la révision prend plus d'un jour, la fonctionnalité doit être décomposée en parties plus petites.

State of DevOps Report : données sur TBD

Le State of DevOps Report annuel (Puppet/DORA) suit les pratiques des équipes à haute performance. Depuis 2015, TBD fait partie des 3 principales pratiques corrélées à une fréquence de déploiement élevée (deploy frequency) et un faible temps de récupération (MTTR). Les équipes pratiquant TBD déploient du code 2 à 3 fois plus souvent et récupèrent 30 % plus rapidement des pannes (DORA, 2023).

Feature Toggles : gestion du code incomplet sans branches

Feature Toggles (indicateurs de fonctionnalités, feature flags) sont un mécanisme pour activer et désactiver des fonctionnalités sans modifier le code. Dans TBD, les feature toggles remplacent les branches de fonctionnalités : le développeur commit du code incomplet dans le trunk mais le cache derrière un indicateur conditionnel. Lorsque la fonctionnalité est prête à être affichée, l'indicateur est basculé dans la configuration sans redéploiement.

Selon Martin Fowler, 2024, les feature toggles sont divisés en quatre types : release toggles (gestion de la visibilité des fonctionnalités), experiment toggles (tests A/B), ops toggles (gestion des paramètres opérationnels) et permission toggles (accès basé sur les rôles). Dans les projets mobiles, les release toggles sont particulièrement utiles : la nouvelle fonctionnalité est cachée jusqu'à la date de sortie, mais le code est déjà dans le trunk et passe par CI/CD.

// Feature Toggle dans Android sur Kotlin
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

    fun isEnabled(key: String): Boolean {
        return remoteConfig.getBoolean(key)
    }
}

// Utilisation dans le code
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD dans Trunk-Based Development : pratiques obligatoires

Continuous Integration (CI) est le composant le plus important de TBD. Chaque push dans le trunk (ou dans une branche temporaire avant le MR) déclenche un pipeline complet : compilation, tests unitaires, tests d'intégration, linters, analyse statique, vérification de couverture de code. Si au moins une étape échoue, l'auteur corrige le code avant le commit suivant. « Trunk cassé — développement arrêté » est la règle principale de TBD.

Selon Jez Humble, Continuous Delivery, 2024, Trunk-Based Development nécessite un pipeline CI qui s'exécute en 10 à 15 minutes. Si la compilation prend plus de temps, les développeurs committent moins souvent, ce qui détruit le sens de TBD. Dans les projets mobiles, les compilations Android et iOS peuvent prendre 20 à 30 minutes, rendant TBD moins pratique. Dans ces cas, les équipes utilisent des Short-Lived Feature Branches (branches d'un jour) avec CI immédiat.

# GitHub Actions pour TBD (Android)
name: CI - TBD Check
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew testDebugUnitTest
      - name: Static analysis
        run: ./gradlew ktlintCheck detekt

Branches de courte durée : règles de travail dans TBD

Les branches de courte durée (short-lived branches) sont un compromis entre le TBD pur (commits directs dans le trunk) et Git Flow. Une branche vit au maximum 1 à 2 jours, contient des modifications de 1 à 3 commits et, après révision (pas plus de 4 heures d'attente), est fusionnée dans le trunk. Si une fonctionnalité nécessite plus de temps, elle est divisée en sous-tâches, chacune avec sa propre branche de courte durée.

Selon TBD Documentation, 2024, les règles des branches de courte durée : la branche est créée à partir d'un trunk frais (pas plus d'une heure), n'est pas synchronisée avec le trunk via merge/rebase (si plus de 4 heures se sont écoulées, une nouvelle branche est créée), le MR/PR est créé immédiatement après le premier commit (même si le travail n'est pas terminé — en tant que Draft).

Pre-tested Commits : commits avec garantie

Pour Trunk-Based Development, la technique des pre-tested commits est importante : le développeur exécute le pipeline CI dans sa branche avant de commiter, et seulement après un statut vert, le commit atteint le trunk. Dans GitLab, cela est implémenté via des Merge Request pipelines avec l'option « Merge when pipeline succeeds ». Dans GitHub — via des branch protection rules avec Required status checks. Cela garantit que le trunk ne contient jamais de code cassé.

• 1 à 2 jours — durée de vie maximale d'une short-lived branch
• 1 à 3 commits — taille optimale des modifications
• 4 heures — temps d'attente maximal pour la révision de code
• Créez le MR immédiatement après le premier commit, même en statut Draft

Branch by Abstraction : remplacement de code sans branchement

Branch by Abstraction est une technique qui permet de remplacer ou de modifier considérablement une partie du système sans créer de branche de fonctionnalité à longue durée de vie. Au lieu de créer une branche dans Git, le développeur crée une abstraction (interface) sous laquelle fonctionnent à la fois l'ancienne et la nouvelle implémentation. Progressivement, tous les consommateurs sont migrés vers la nouvelle implémentation, après quoi l'ancienne est supprimée.

Selon Branch by Abstraction, 2024, les étapes de Branch by Abstraction : 1) créer une abstraction pour le composant à remplacer, 2) implémenter la nouvelle version sous l'abstraction, 3) basculer les consommateurs vers la nouvelle implémentation via la configuration, 4) supprimer l'ancienne implémentation. Toutes les étapes sont commitées dans le trunk en petites portions, chacune ne cassant pas CI/CD.

TBD vs Git Flow : comparaison des approches

Trunk-Based Development et Git Flow sont deux approches opposées de la gestion des branches. Git Flow utilise des branches à longue durée de vie et une hiérarchie stricte, TBD utilise une seule branche et des cycles d'intégration courts. Le choix entre eux dépend de la taille de l'équipe, de la fréquence des versions et du niveau d'automatisation CI/CD.

Erreurs typiques lors de l'implémentation de Trunk-Based Development

Les erreurs de TBD sont le plus souvent liées à un CI/CD insuffisant ou à une faible discipline de commit. La première erreur est d'implémenter TBD sans CI, qui se brise dès le premier commit échoué. Si le trunk ne peut pas être réparé en 15 minutes, l'équipe perd confiance dans le processus et revient aux branches longues. La deuxième erreur est d'autoriser des branches à longue durée de vie « uniquement pour cette fonctionnalité », ce qui détruit tout le concept.

Selon Paul Hammant, 2023, la troisième erreur est une mauvaise modularité du code. Trunk-Based Development nécessite que le code soit divisé en modules indépendants. Si un changement dans une classe casse trois autres modules, les développeurs ne peuvent pas commiter en petites portions. La quatrième erreur est d'ignorer les feature toggles : tenter de commiter du code incomplet sans indicateur casse le trunk pour toute l'équipe.

Trunk-Based Development dans le développement mobile

Trunk-Based Development dans les projets mobiles a des particularités en raison des longs temps de compilation (20 à 30 minutes pour Android et iOS) et des exigences de qualité strictes. Google et Spotify utilisent TBD dans le développement mobile, en appliquant des branches de courte durée avec CI obligatoire avant la fusion. Les feature toggles sont gérés via Firebase Remote Config ou LaunchDarkly.

Selon LaunchDarkly Docs, 2024, dans le développement mobile, TBD offre un avantage : les fonctionnalités sont testées dans le trunk avec le reste du code avant la date de sortie, ce qui réduit le risque de problèmes d'intégration. Si le pipeline CI prend plus de 15 minutes, les branches de courte durée d'un jour avec CI automatique à chaque push sont optimales. Pour Apple App Store et Google Play, TBD nécessite la configuration de déploiements progressifs via des feature toggles.

Feature Flags en tant que service : LaunchDarkly et Firebase

Pour gérer les feature toggles dans TBD, des plateformes sont utilisées : LaunchDarkly (entreprise, complet), Firebase Remote Config (gratuit pour les petits projets), Split.io (open-source). Elles fournissent : activation ciblée des fonctionnalités par pourcentage d'utilisateurs, tests A/B, surveillance d'utilisation et désactivation automatique en cas d'erreurs. Dans les projets mobiles, Firebase Remote Config est le choix le plus populaire en raison de son intégration avec Firebase et de son seuil gratuit jusqu'à 1000 utilisateurs.