Trunk-Based Development

2025-03-06

#git #workflow #branches #Darkaine #CI/CD

Trunk-Based Development

Qu'est-ce que le Trunk-Based Development ?

Le Trunk-Based Development (TBD) est un modèle de gestion de branches Git où les développeurs collaborent sur un seul tronc (trunk) ou branche principale, généralement appelée main ou master. Dans cette approche, les développeurs créent des branches de courte durée à partir du tronc principal pour développer des fonctionnalités ou corriger des bugs, puis les fusionnent rapidement (généralement en moins d'une journée) dans le tronc.

Cette méthode se distingue par sa simplicité et sa focalisation sur l'intégration continue. Elle favorise des cycles de développement courts et des déploiements fréquents, ce qui en fait une approche particulièrement bien adaptée aux pratiques DevOps et aux environnements CI/CD.

Principes fondamentaux du Trunk-Based Development

Une seule branche principale : Tous les développeurs travaillent à partir d'une branche principale unique.
Intégration fréquente : Les changements sont intégrés au tronc principal plusieurs fois par jour.
Branches de courte durée : Les branches de fonctionnalités sont petites et vivent rarement plus d'une journée.
Tests automatisés : Une suite de tests complète garantit la stabilité du tronc.
Déploiement continu : Le code du tronc est toujours déployable.

Flux de travail typique en Trunk-Based Development

Développement d'une petite fonctionnalité

1. Mise à jour du tronc local
   git checkout main
   git pull

2. Création d'une branche de courte durée
   git checkout -b feature-xyz

3. Développement avec commits fréquents
   [travail, commits, etc.]

4. Tests locaux
   [exécution des tests]

5. Mise à jour avec le tronc (si nécessaire)
   git checkout main
   git pull
   git checkout feature-xyz
   git rebase main

6. Fusion dans le tronc
   git checkout main
   git merge feature-xyz

7. Suppression de la branche
   git branch -d feature-xyz

Développement d'une fonctionnalité plus importante

Pour les fonctionnalités qui nécessitent plusieurs jours de développement, deux approches sont possibles :

1. Feature Flags (recommandée)

1. Développement directement sur le tronc avec un feature flag
   git checkout main
   
2. Ajout du code avec feature flag désactivé
   [développement du code]
   
3. Commits et push fréquents
   git commit -m "Ajout de la fonctionnalité XYZ (désactivée)"
   git push
   
4. Activation du feature flag lorsque la fonctionnalité est prête
   [modification du flag]
   git commit -m "Activation de la fonctionnalité XYZ"
   git push

2. Feature Branches (alternative)

1. Création d'une branche de fonctionnalité
   git checkout -b feature-xyz
   
2. Synchronisation fréquente avec le tronc
   git checkout main
   git pull
   git checkout feature-xyz
   git rebase main
   
3. Fusion dans le tronc dès que possible
   git checkout main
   git merge feature-xyz

Feature Flags : composant essentiel du Trunk-Based Development

Les feature flags (ou feature toggles) sont des interrupteurs dans le code qui permettent d'activer ou désactiver des fonctionnalités sans déployer de nouveau code. Ils sont essentiels au Trunk-Based Development pour plusieurs raisons :

Fonctionnalités incomplètes : Ils permettent d'intégrer du code incomplet dans le tronc sans affecter les utilisateurs.
Tests A/B : Possibilité d'activer une fonctionnalité pour un sous-ensemble d'utilisateurs.
Rollback facile : En cas de problème, la fonctionnalité peut être désactivée sans déploiement.

Exemple de Feature Flag en PHP

class FeatureFlags {
    private static $flags = [
        'new_ui' => false,
        'advanced_search' => true,
        'beta_feature' => false
    ];
    
    public static function isEnabled(string $featureName): bool {
        return isset(self::$flags[$featureName]) && self::$flags[$featureName];
    }
}

// Utilisation
if (FeatureFlags::isEnabled('advanced_search')) {
    // Afficher la recherche avancée
} else {
    // Afficher la recherche standard
}

Exemple de Feature Flag en Go

package featureflags

var flags = map[string]bool{
    "new_ui":          false,
    "advanced_search": true,
    "beta_feature":    false,
}

func IsEnabled(featureName string) bool {
    enabled, exists := flags[featureName]
    return exists && enabled
}

// Utilisation
if featureflags.IsEnabled("advanced_search") {
    // Afficher la recherche avancée
} else {
    // Afficher la recherche standard
}

Avantages du Trunk-Based Development

Simplicité : Modèle facile à comprendre et à mettre en œuvre.
Réduction des conflits de fusion : Les intégrations fréquentes réduisent les conflits complexes.
CI/CD optimisé : Parfaitement adapté à l'intégration continue et au déploiement continu.
Feedback rapide : Les bugs sont identifiés rapidement grâce à l'intégration fréquente.
Meilleure collaboration : Tous les développeurs travaillent sur la même base de code.
Visibilité : Les progrès sont visibles immédiatement dans le tronc principal.

Inconvénients du Trunk-Based Development

Discipline requise : Nécessite une grande discipline d'équipe pour maintenir la stabilité du tronc.
Infrastructure de tests : Exige une infrastructure de tests solide et fiable.
Feature flags : La gestion des feature flags peut devenir complexe avec le temps.
Moins adapté aux équipes distribuées : Peut être difficile à mettre en œuvre avec des équipes très distribuées.
Gestion de versions : Plus difficile de maintenir plusieurs versions en production.

Comparaison avec d'autres modèles

Trunk-Based Development vs GitFlow

GitFlow est plus structuré et complexe :

Multiples branches à longue durée de vie (develop, master, release, etc.)
Processus formalisé pour les fonctionnalités, releases et hotfixes
Adapté aux cycles de release planifiés

Trunk-Based Development est plus simple :

Une seule branche principale
Intégration continue et fréquente
Adapté au déploiement continu

Trunk-Based Development vs GitHub Flow

GitHub Flow est un modèle intermédiaire :

Une branche principale
Branches de fonctionnalités qui peuvent durer plus longtemps
Pull requests pour réviser le code avant fusion
Déploiement après chaque fusion dans la branche principale

Trunk-Based Development est plus strict :

Branches très courtes (généralement < 1 jour)
Intégration plusieurs fois par jour
Usage intensif des feature flags

Cas d'utilisation appropriés pour le Trunk-Based Development

Le Trunk-Based Development est particulièrement adapté pour :

Équipes DevOps : Organisations pratiquant l'intégration continue et le déploiement continu.
Applications SaaS : Services web avec déploiements fréquents.
Startups : Environnements nécessitant une itération rapide.
Équipes co-localisées : Équipes travaillant ensemble et communiquant facilement.
Produits avec une seule version active : Applications qui n'ont pas besoin de maintenir plusieurs versions.

À l'inverse, le TBD n'est généralement pas recommandé pour :

Logiciels avec versions multiples : Produits nécessitant le support de plusieurs versions en parallèle.
Équipes très distribuées : Sans bonne communication et coordination.
Projets sans tests automatisés : La qualité du tronc dépend fortement des tests.

Bonnes pratiques pour le Trunk-Based Development

Tester, tester, tester : Investir dans des tests automatisés complets (unitaires, intégration, UI).
Intégration continue : Configurer un pipeline CI qui s'exécute sur chaque commit.
Petits commits : Privilégier les petits changements fréquents plutôt que les grosses modifications.
Revue de code : Mettre en place un processus de revue de code efficace.
Gestion des feature flags : Créer un système robuste pour gérer les feature flags et nettoyer ceux qui ne sont plus nécessaires.
Monitoring : Surveiller étroitement les déploiements pour détecter rapidement les problèmes.
Pair programming : Encourager le développement en binôme pour améliorer la qualité du code.

Outils facilitant le Trunk-Based Development

Outils CI/CD : Jenkins, CircleCI, GitHub Actions, GitLab CI
Gestionnaires de feature flags : LaunchDarkly, Split.io, Flagsmith
Outils de revue de code : GitHub Pull Requests, GitLab Merge Requests
Tests automatisés : Jest, PHPUnit, Go testing package, Cypress
Monitoring : Datadog, New Relic, Prometheus

Exemple de configuration CI pour Trunk-Based Development (GitHub Actions)

name: CI Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      - name: Setup
        run: npm install
        
      - name: Run linter
        run: npm run lint
        
      - name: Run unit tests
        run: npm run test:unit
        
      - name: Run integration tests
        run: npm run test:integration
        
  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      - name: Setup
        run: npm install
        
      - name: Build
        run: npm run build
        
      - name: Deploy
        run: |
          # Script de déploiement automatique
          echo "Déploiement de la nouvelle version"

Transition vers le Trunk-Based Development

Pour passer d'un autre modèle (comme GitFlow) au Trunk-Based Development :

Améliorer les tests : Augmenter la couverture des tests automatisés.
Mettre en place un pipeline CI/CD : Automatiser les tests et le déploiement.
Implémenter les feature flags : Créer l'infrastructure nécessaire pour les feature flags.
Former l'équipe : S'assurer que toute l'équipe comprend les principes du TBD.
Commencer progressivement : Débuter avec de petites fonctionnalités avant de passer aux plus complexes.
Mesurer les progrès : Suivre des métriques comme la fréquence des déploiements et le temps de cycle.

Conclusion

Le Trunk-Based Development est un modèle de gestion de branches qui privilégie la simplicité et l'intégration continue. En encourageant des intégrations fréquentes dans le tronc principal et l'utilisation de feature flags, cette approche accélère le développement et facilite le déploiement continu.

Bien que ce modèle exige une grande discipline et une infrastructure de tests robuste, ses avantages en termes de rapidité, de collaboration et de stabilité en font un choix de plus en plus populaire pour les équipes modernes pratiquant l'Agile et le DevOps.

Le Trunk-Based Development n'est pas adapté à tous les projets, mais pour les équipes cherchant à optimiser leur pipeline de livraison et à réduire le temps entre l'écriture du code et son déploiement en production, il représente une alternative séduisante aux modèles plus complexes comme GitFlow.

Ressources

Trunk Based Development - Site de référence sur le sujet
Feature Toggles (aka Feature Flags) par Martin Fowler
Continuous Delivery par Jez Humble
Accelerate: Building and Scaling High Performing Technology Organizations par Nicole Forsgren, Jez Humble et Gene Kim
DevOps Handbook par Gene Kim, Jez Humble, Patrick Debois et John Willis

Darkaine @ Mémos

Je découvre, j'apprends, je prends des notes et je les partage.