# 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 `main` ou `trunk` comme 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** :
1. **Pull** les derniers changements du trunk
   ```bash
   git pull origin main
   ```

2. **Créer une branche courte** (optionnel, pour PR)
   ```bash
   git checkout -b feature/quick-fix
   ```

3. **Développer en petits incréments** (max 1-2 jours)

4. **Commit fréquent** avec feature flags si nécessaire

5. **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|Seenaps]] - 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** :

1. **Lundi matin** : Dev démarre nouvelle feature "Export PDF"
   - Pull du main
   - Crée branche `feature/pdf-export`

2. **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)

3. **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

4. **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.Y` au 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](https://trunkbaseddevelopment.com/) - Site de référence
- [Google SRE Book](https://sre.google/books/) - 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](https://launchdarkly.com) |
| **Unleash** | Feature flags open-source | [getunleash.io](https://getunleash.io) |
| **GitHub Actions** | CI/CD | [github.com/features/actions](https://github.com/features/actions) |
| **Trunk** | CLI pour vérifier conformité | [trunk.io](https://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*