Choisir entre Git Flow et le Trunk-Based Development (TBD) peut impacter considérablement votre workflow CI/CD. Voici un aperçu rapide :
- Git Flow: Idéal pour les environnements structurés avec contrôle de version. Il utilise plusieurs branches comme
main,develop,feature,release, ethotfix. Idéal pour les grandes équipes, les cycles de release lents et des process QA stricts. - Développement trunk-based: Repose sur une seule branche principale avec des branches de fonctionnalité éphémères. Adapté aux petites équipes, aux releases rapides et à des tests automatisés solides.
Comparaison rapide :
| Aspect | Git Flow | Développement trunk-based |
|---|---|---|
| Complexité des branches | Plusieurs branches de longue durée | Branche unique, branches éphémères |
| Fréquence des releases | Releases planifiées | Déploiement continu |
| Team Size | Grandes équipes | Petites et moyennes équipes |
| En test | Tests en fin de cycle | Le test automatisé |
| Risque de déploiement | Plus faible avec des releases progressives | Plus élevé avec des mises à jour fréquentes |
| Rollback | Plus lent | Plus rapide |
L'essentiel: Utilisez Git Flow pour des workflows structurés et lents, et TBD pour la vitesse et la flexibilité. Les deux nécessitent des pipelines CI/CD solides pour réussir.
29 - GitFlow vs. Trunk-Based Development : Gérer …
Git Flow Bases du workflow
Git Flow organise le développement à l'aide de cinq types de branches : main, develop, feature, release, et hotfix. Cette structure permet de gérer efficacement les releases et le développement parallèle.
Structure des branches Git Flow
| Type de branche | Objectif | Cible de merge |
|---|---|---|
| Principal | Contient les code prêts pour la production | N/A |
| Développer | Intègre les fonctionnalités ; sert de base aux branches de fonctionnalités | N/A |
| Fonctionnalité | Utilisée pour développer des fonctionnalités ; créée depuis develop | develop |
| Release | Prépare les tests finaux et le versioning ; créée depuis develop | main & develop |
| Hotfix | Corrige rapidement les problèmes de production ; créée depuis main | main & develop |
Avantages de Git Flow
- Permet de développer plusieurs fonctionnalités simultanément sans créer de conflits.
- Les branches de release offrent un espace dédié aux tests finaux et à la préparation de la version, tout en gardant le develop ouverte pour le travail en cours.
- Hotfix les branches permettent de résoudre rapidement les problèmes de production sans interrompre les autres tâches de développement.
Inconvénients de Git Flow
- Complexité de la gestion des branches : Gérer plusieurs branches actives peut rendre les merges plus complexes.
- Déploiement plus lent: le processus de release formel peut ralentir les déploiements par rapport à des workflows plus simples.
- Maintenance accrue: Chaque branche nécessite sa propre configuration de pipeline, ce qui alourdit la charge de maintenance.
Ce workflow est idéal pour les projets qui nécessitent un contrôle de version strict, plusieurs canaux de release ou le respect des réglementations. Ensuite, nous verrons comment cela se compare à l'approche simplifiée du trunk-based development.
Les bases du trunk-based development
Le trunk-based development (TBD) repose sur une branche principale unique, souvent appelée trunk ou main. Cette approche est très proche des pratiques DevOps et de l'intégration continue.
Structure des branches en TBD
Dans un workflow TBD classique, vous rencontrerez ces types de branches :
| Type de branche | Objectif | Durée de vie |
|---|---|---|
| Main/Trunk | Branche centrale avec code prêt pour la production | Permanente |
| Branches de fonctionnalité | Branches temporaires pour des modifications individuelles | De courte durée |
| Branches de release | Utilisées pour les derniers ajustements avant une release | Temporaire |
Les développeurs fusionnent régulièrement de petites modifications incrémentales dans la branche principale, souvent plusieurs fois par jour. Cela favorise les tests continus et permet de résoudre les conflits rapidement.
Avantages du trunk-based
TBD offre plusieurs avantages aux équipes qui travaillent avec CI/CD et DevOps :
- Moins de conflits de merge: Des merges réguliers gardent les conflits sous contrôle.
- Feedback plus rapide: Les builds automatisés s'exécutent à chaque merge et détectent les bugs tôt.
- Pipelines plus simples: Une branche unique réduit la complexité des configurations CI/CD.
- Meilleure collaboration d'équipe: Un trunk partagé garantit que tout le monde reste aligné.
Cette structure crée un workflow fluide, préparant le terrain pour une comparaison avec Git Flow dans la section suivante.
Limites du Trunk-Based
Bien que le TBD ait ses atouts, il s'accompagne aussi de défis que les équipes doivent relever :
| Défi | Impact | Comment y remédier |
|---|---|---|
| Stabilité de Code | Risque de breaking changes sur main | Utiliser des tests automatisés robustes |
| Coordination d’équipe | Le chevauchement des tâches peut causer des perturbations | S’appuyer sur des feature flags et des petits commits fréquents |
| Courbe d'apprentissage | Sortir des branches de longue durée | Proposer une formation et une transition progressive |
| Problèmes d’échelle | Les merges fréquents peuvent submerger les grandes équipes | Imposer des revues code rigoureuses |
Adopter le TBD avec succès exige de solides tests automatisés et une communication ouverte au sein de l’équipe.
Git Flow vs trunk-based : comparaison directe
Voici comment Git Flow et le Trunk-Based Development se comparent sur les points clés :
Tableau comparatif des fonctionnalités
| Aspect | Git Flow | Développement trunk-based |
|---|---|---|
| Complexité des branches | Plusieurs branches de longue durée | Une seule branche principale avec des branches de courte durée |
| Fréquence des releases | Releases planifiées | Déploiement continu |
| Team Size | Idéal pour les grandes équipes | Mieux adapté aux petites équipes |
| Processus de revue Code | Revues formelles lors des merges de branches | Revues continues de changements fréquents et mineurs |
| Exigences de test | Focus sur les tests en fin de cycle | Forte dépendance aux tests automatisés |
| Courbe d'apprentissage | Plus complexe à cause des multiples branches | Workflow plus simple, mais nécessite des tests robustes |
| Risque de déploiement | Risque réduit avec les déploiements progressifs | Risque accru avec des mises à jour fréquentes |
| Temps de récupération | Processus de rollback plus lents | Retour arrière plus rapide |
Quand utiliser chaque workflow
Git Flow est idéal pour les projets d'entreprise qui exigent des releases structurées et versionnées. Il convient parfaitement aux équipes qui gèrent plusieurs versions supportées et aux projets avec des exigences formelles de QA ou de conformité.
Développement trunk-based convient le mieux aux équipes et aux projets qui privilégient la vitesse et la flexibilité, comme :
- Plateformes SaaS nécessitant des mises à jour rapides
- Équipes disposant de pipelines CI/CD solides
- Projets s’appuyant sur des tests automatisés fiables
- Workflows de déploiement continu ou releases fréquentes
- Projets d’app mobile nécessitant des mises à jour régulières
Certaines équipes combinent même les deux méthodes : Trunk-Based Development pour les services principaux et Git Flow pour les projets avec des cycles de release formels.
À suivre : comment configurer des pipelines CI/CD pour l’une ou l’autre approche.
Configuration du pipeline CI/CD
Configuration CI/CD avec Git Flow
- Pipeline de la branche de développement: Exécute les tests unitaires, les tests d’intégration, les contrôles de qualité code, la vérification du build et le déploiement vers l’environnement de développement.
- Pipeline de branche de release: Exécute la suite de tests complète, les analyses de sécurité, compile une release candidate et déploie vers l’environnement de staging.
- Pipeline de la branche principale: Exécute les tests de validation, gère le versioning, crée le build de production, déploie en production et tague la release.
Configuration CI/CD trunk-based
- Pipeline de branche feature: Se concentre sur les tests unitaires rapides, les vérifications de style code, la vérification du build et le déploiement vers un environnement de preview.
- Pipeline de la branche principale: Couvre des tests automatisés complets, des analyses de sécurité, la création du build de production, le déploiement progressif et le rollback automatisé.
Capgo Intégration CI/CD
Pour ajouter des live update OTA à n'importe quelle configuration CI/CD, Capgo peut être intégré en toute transparence :
Capgo fonctionne avec GitHub Actions GitHub, GitLab CI, et Jenkins pour activer les live updates, les déploiements progressifs et les rollbacks instantanés dans les pipelines Git Flow et Trunk-Based. Il répond aux exigences d’Apple et de Google tout en prenant en charge les déploiements cloud et auto-hébergés [1].
Résumé et recommandations
Choisissez votre workflow en fonction de la taille de votre équipe et du niveau de maturité de votre CI/CD, grâce au tableau ci-dessous :
| Scénario | Git Flow | Trunk-based |
|---|---|---|
| Team size | 50+ développeurs | Moins de 50 développeurs |
| Fréquence des releases | Hebdomadaire ou mensuelle | Quotidienne ou plusieurs fois par jour |
| Tests & QA | Cycles de QA traditionnels | Priorité aux tests automatisés |
| Modèle de déploiement | Multi-version, traditionnel | Cloud-native, conteneurisé |
| Tolérance au risque | Configurations conservatrices ou réglementées | Feedback rapide et progressif |
- Commencez par le Trunk-Based Development dans les équipes plus petites, puis étendez-l’à des groupes plus grands. Assurez-vous que votre pipeline CI/CD est entièrement automatisé avant la transition.
- Maintenez des revues code cohérentes et utilisez des feature toggles dans les deux workflows. Alignez vos configurations de pipeline sur le workflow choisi.
Certaines équipes mélangent ces approches : Git Flow pour les releases majeures, Trunk-Based Development pour livrer les fonctionnalités. Quel que soit votre choix, le succès dépend d'une intégration CI/CD correcte, de l'automatisation des tests et de garder l'équipe alignée.
Continuer avec Git Flow vs Trunk-Based pour la CI/CD
Si vous utilisez Git Flow vs Trunk-Based pour la CI/CD pour planifier l'automatisation CI/CD, et le connecter avec CI/CD Capgo pour le workflow produit dans le CI/CD de Capgo, Capgo Native Build pour le workflow produit dans les Native Builds de Capgo, Intégrations Capgo pour le workflow produit dans les intégrations de Capgo, Intégration CI/CD pour le détail d'implémentation dans l'intégration CI/CD, et Intégration GitHub Actions pour les détails d'implémentation de l'intégration GitHub Actions.
