8.9 KiB
Trunk-Based Development
Type : Méthode / Pratique de développement Domaine : Développement / DevOps / Continuous Delivery Difficulté : 🟡 Moyenne Date de capture : 26 décembre 2025
🎯 Objectif
Trunk-Based Development est une pratique de gestion de code source où les développeurs collaborent sur du code dans une seule branche appelée "trunk" (ou "main"), en évitant les branches de longue durée.
Problème résolu :
- Réduire la complexité des merges
- Accélérer les cycles de livraison
- Améliorer la collaboration d'équipe
- Réduire les risques d'intégration
📋 La méthode étape par étape
Étape 1 : Configuration du repository
Actions :
- Définir
mainoutrunkcomme branche principale unique - Protéger la branche principale (require PR, CI passing)
- Configurer le pipeline CI/CD pour déclencher sur chaque commit
Outils nécessaires :
- Git / GitHub / GitLab
- Pipeline CI (GitHub Actions, GitLab CI, Jenkins)
Durée estimée : 1-2h (setup initial)
Étape 2 : Workflow quotidien des développeurs
Actions :
-
Pull les derniers changements du trunk
git pull origin main -
Créer une branche courte (optionnel, pour PR)
git checkout -b feature/quick-fix -
Développer en petits incréments (max 1-2 jours)
-
Commit fréquent avec feature flags si nécessaire
-
Merge rapide vers trunk (< 24h de vie de la branche)
Outils nécessaires :
- Feature flags (LaunchDarkly, Unleash, flags maison)
- Tests automatisés
Durée estimée : Workflow continu
Étape 3 : Intégration et livraison
Actions :
- Le CI exécute les tests sur chaque commit
- Deploy automatique vers environnements de staging
- Feature flags pour activer/désactiver les features en production
- Monitoring continu post-déploiement
Outils nécessaires :
- CI/CD pipeline
- Feature flags
- Monitoring (Datadog, Sentry, etc.)
Durée estimée : Automatisé
✅ Checklist d'application
Pré-requis
- Suite de tests automatisés robuste (unitaires, intégration, E2E)
- Pipeline CI/CD fonctionnel
- Système de feature flags en place
- Équipe alignée sur la pratique
Pratiques quotidiennes
- Pull du trunk au moins 1x par jour
- Commit/Push au trunk au moins 1x par jour
- Branches de feature < 24h de vie
- Code review rapide (< 2h de délai)
- Tests verts avant merge
Validation finale
- Pas de branches de longue durée (> 2 jours)
- Deployment frequency augmentée
- Lead time for changes réduit
- Merge conflicts rares
💡 Exemple concret
Contexte
Équipe de développement Projets/Seenaps/README - 5 développeurs travaillant sur la même codebase.
Avant Trunk-Based Dev :
- Branches de feature de 1-2 semaines
- Merge complexes et conflictuels
- Intégration tardive, bugs découverts tard
Application Trunk-Based Dev :
-
Lundi matin : Dev démarre nouvelle feature "Export PDF"
- Pull du main
- Crée branche
feature/pdf-export
-
Lundi après-midi : Premier incrément
- Implémente structure de base avec feature flag désactivé
- Commit + Push
- PR créée → Review → Merge en 1h
- Feature déployée en prod mais invisible (flag off)
-
Mardi : Deuxième incrément
- Pull du main (récupère changements des collègues)
- Nouvelle branche courte
- Ajoute génération PDF basique
- Merge en fin de journée
-
Mercredi : Feature complète
- Derniers ajustements
- Active feature flag pour 10% des utilisateurs
- Monitoring + feedback
Résultat :
- Feature livrée en 3 jours vs 2 semaines
- Zéro merge conflict majeur
- Feedback utilisateur rapide
- Rollback facile si problème (désactiver flag)
🧩 Concepts sous-jacents
- Continuous Integration - Trunk-Based Dev est une pratique clé du CI
- Continuous Delivery - Permet des déploiements fréquents et fiables
- DevOps Culture - Favorise la collaboration Dev/Ops
- Shift-Left Testing - Tests précoces et fréquents
⚡ Variantes & Adaptations
Variante 1 : Scaled Trunk-Based Development
Quand l'utiliser ? Grandes équipes (> 10 devs)
Modifications :
- Utilisation de "release branches" courtes pour stabilisation
- Branches de feature ultra-courtes (quelques heures max)
- Code review asynchrone mais très rapide
Variante 2 : Direct-to-Trunk (sans branches)
Quand l'utiliser ? Petites équipes très matures (< 5 devs)
Modifications :
- Commit directement sur trunk (pas de branches)
- Pair programming pour review en temps réel
- Feature flags obligatoires pour tout
Variante 3 : Trunk-Based avec Release Branches
Quand l'utiliser ? Produits avec releases planifiées (mobile apps)
Modifications :
- Développement sur trunk
- Création de
release/X.Yau moment de la release - Hotfixes sur release branch + cherry-pick vers trunk
⚠️ Erreurs courantes
| Erreur | Conséquence | Solution |
|---|---|---|
| Branches trop longues | Merge hell, intégration tardive | Limiter durée branche à < 24h, découper en plus petits incréments |
| Pas de feature flags | Code incomplet merge sur trunk | Implémenter système de feature flags robuste |
| Tests insuffisants | Bugs en production | Investir dans suite de tests automatisés complète |
| Code review lent | Branches s'accumulent | SLA review < 2h, rotation des reviewers |
| Peur de casser le trunk | Retour aux branches longues | Culture blameless, rollback facile, monitoring |
📊 Métriques de succès
Comment savoir si la méthode fonctionne ?
Métriques DORA
- Deployment Frequency : Augmente (idéal : plusieurs fois par jour)
- Lead Time for Changes : Diminue (idéal : < 1 jour)
- Mean Time to Restore : Diminue (rollback via feature flags)
- Change Failure Rate : Stable ou diminue
Métriques d'équipe
- Nombre de merge conflicts : Diminue drastiquement
- Durée moyenne des branches : < 24h
- Temps de code review : < 2h
- Fréquence de commit par dev : Au moins 1/jour
Indicateurs qualitatifs
- Moins de stress lors des merges
- Meilleure visibilité sur le travail de l'équipe
- Feedback utilisateur plus rapide
🔗 Ressources
Documentation officielle
- trunkbaseddevelopment.com - Site de référence
- Google SRE Book - Pratiques Google
Articles recommandés
- "Trunk-Based Development vs Git Flow" - Comparaison des approches
- "Feature Flags: The Secret to Trunk-Based Development"
Outils
| Outil | Usage | Lien |
|---|---|---|
| LaunchDarkly | Feature flags SaaS | launchdarkly.com |
| Unleash | Feature flags open-source | getunleash.io |
| GitHub Actions | CI/CD | github.com/features/actions |
| Trunk | CLI pour vérifier conformité | trunk.io |
🎓 Adoption progressive
Phase 1 : Fondations (Semaine 1-2)
- Mettre en place CI robuste
- Former l'équipe aux concepts
- Implémenter système de feature flags basique
Phase 2 : Transition (Semaine 3-4)
- Réduire durée des branches progressivement
- Instaurer SLA review < 4h puis < 2h
- Augmenter fréquence de commit
Phase 3 : Maturité (Mois 2-3)
- Branches < 24h systématiquement
- Deploy daily ou plus
- Feature flags pour toute nouvelle feature
- Monitoring et rollback fluides
💬 Objections courantes
"Si j'ai un bug urgent, est-ce que j'attends la prochaine livraison ?"
Réponse : Non, c'est justement l'avantage du Trunk-Based Dev !
- Le trunk est toujours déployable
- Fix le bug sur une branche ultra-courte
- Merge + deploy en minutes (pas jours)
- Pourquoi n'utiliserais-tu pas le même processus pour les features ?
"On va casser la production tout le temps"
Réponse :
- Feature flags permettent de déployer sans activer
- Tests automatisés sont le filet de sécurité
- Rollback instantané si problème
- En pratique : moins de bugs que branches longues (intégration continue)
"Notre équipe n'est pas assez mature"
Réponse :
- Commencer petit : réduire durée branches de 2 semaines → 1 semaine
- Investir dans les tests d'abord
- Culture blameless : on apprend des erreurs
- Les bénéfices motivent l'amélioration continue
🏷️ Tags
#méthode #développement #devops #continuous-delivery
📝 Notes d'expérience personnelle
Contexte d'utilisation : Équipe Seenaps
Bénéfices observés :
- À compléter après adoption
Défis rencontrés :
- À documenter
Adaptations spécifiques :
- À noter
Dernière mise à jour : 26 décembre 2025 Note enrichie avec template par Claude Code Dernière utilisation : À venir