Développement trunk-based vs GitFlow pour des livraisons hebdomadaires

Pourquoi la livraison hebdomadaire devient chaotique avec le mauvais modèle de branches

La livraison hebdomadaire semble simple jusqu’à la semaine où vous la manquez. La build est « presque prête » jeudi, la QA trouve des problèmes tard le vendredi, et le lundi se transforme en journée de nettoyage au lieu d’un bon départ.

Un facteur majeur est votre modèle de branches. Il décide quand les changements se rencontrent, où l’intégration a lieu, et à quelle vitesse vous pouvez récupérer quand quelque chose casse. Si l’intégration est repoussée à la fin de la semaine, vous en payez le prix : conflits de merge, bugs surprises et environnements de test instables.

Quand le workflow travaille contre vous, ça ressemble souvent à ça :

• Les merges prennent plus de temps que le travail de fonctionnalité qui les a causés.
• La QA teste un mauvais mélange de changements parce que les branches divergent.
• Les releases deviennent une négociation plutôt qu’une routine.
• Les hotfixes déclenchent la panique parce que personne n’est sûr de ce qui partira en plus.
• Les gens cessent de faire confiance à la QA et demandent des exceptions.

Le mode de branche influence aussi la stabilité de la QA. Si la QA passe son temps à rebondir entre des chemins de code à moitié intégrés, elle devient une cible mouvante. Même les meilleurs testeurs ne peuvent pas donner des réponses claires quand le système testé change toutes les quelques heures, ou qu’un merge tardif remplace discrètement ce qu’ils ont testé la veille.

C’est pourquoi les équipes comparent souvent trunk-based development et GitFlow lorsqu’elles passent à un rythme de release hebdomadaire. La vraie question utile n’est pas lequel est populaire, mais lequel réduit la douleur des merges, garde les releases prévisibles, rend les hotfixes sûrs et rapides, et donne du sens à la QA.

Supposons une petite ou moyenne équipe, un dépôt partagé, une CI qui tourne à chaque push. Vous livrez peut‑être une application web et une API. Ou bien une partie de l’équipe travaille visuellement dans une plate‑forme comme AppMaster tout en gérant du code généré et des déploiements comme toute autre équipe produit.

Si votre processus actuel crée de gros merges en fin de semaine, votre cadence hebdomadaire va continuer à glisser. S’il encourage une intégration petite et fréquente, les releases hebdomadaires deviennent ennuyeuses (au meilleur sens du terme).

Trunk-based development et GitFlow en clair

Les deux approches ne sont que des règles sur la manière d’utiliser les branches pour que le travail passe de « en cours » à « livré » sans chaos. La vraie différence est le nombre de branches longues que vous conservez et la durée pendant laquelle le travail reste séparé avant de rencontrer le code des autres.

• Trunk-based garde presque tout proche de main.
• GitFlow garde des voies séparées pour le travail en cours et la stabilisation de la release.

Trunk-based development (en termes simples)

Le développement trunk-based considère main (le tronc) comme le centre. On travaille dans des branches de courte durée (quelques heures à un jour ou deux), on merge fréquemment, et on garde main dans un état déployable.

Si quelque chose n’est pas prêt, soit vous le gardez suffisamment petit pour le finir vite, soit vous le cachez derrière un feature flag afin qu’il puisse être livré sans être visible.

GitFlow (en termes simples)

GitFlow utilise généralement une branche longue develop où les fonctionnalités atterrissent d’abord, plus des branches feature issues de develop. Près de la release, on découpe une branche release/* pour stabiliser et tester. Si la production casse, on crée une branche hotfix/* (souvent depuis main) et on la merge ensuite.

Ce modèle optimise la séparation : le travail en cours peut continuer dans develop pendant que la branche de release est testée et patchée.

Beaucoup de douleur vient de malentendus courants :

• Prendre le trunk-based pour du « pas de branches » (il utilise des branches, mais de courte durée).
• Utiliser GitFlow sans jamais créer une vraie branche de release, de sorte que develop devient une zone de staging instable.
• Laisser des branches feature vivre des semaines, ce qui transforme n’importe quel modèle en enfer de merge.
• Confondre « releasable » avec « tout est terminé » au lieu de « sûr à déployer ».

Friction de merge : qu’est‑ce qui la cause réellement

Les conflits de merge viennent généralement de deux sources : des branches qui vivent trop longtemps, et plusieurs personnes modifiant les mêmes zones sans coordination.

La différence pratique la plus importante entre trunk-based et GitFlow est la durée pendant laquelle le travail reste séparé avant de rencontrer le reste.

Avec trunk-based, les changements atteignent la ligne principale souvent. Les pull requests sont plus petites, les diffs réduits, et les conflits apparaissent plus tôt quand le contexte est encore frais. Les conflits existent toujours, mais ils sont généralement plus faciles à résoudre parce que vous réconciliez quelques lignes, pas deux semaines de dérive. Le compromis est la discipline : garder les builds vertes, garder les changements incrémentaux, et traiter main comme le produit.

Avec GitFlow, le travail de fonctionnalité peut rester plus longtemps sans affecter les autres développeurs au quotidien. Le coût apparaît plus tard sous la forme d’événements de merge plus importants : feature → develop, develop → release/*, et release/* → main. Chaque merge est une plus grande réunion de changements, donc les conflits sont plus probables et plus difficiles à démêler. Pour une livraison hebdomadaire, ces gros merges tombent souvent au moment où l’équipe veut être en test.

La charge de la revue de code change aussi. Trunk-based implique généralement plus de revues, mais chacune est plus rapide à comprendre. GitFlow signifie souvent moins de revues, mais plus lourdes, plus du temps supplémentaire lors des merges de release quand tout le monde est fatigué.

Pour réduire la friction de merge dans les deux modèles :

• Gardez les PRs petites et ciblées (un seul objectif à la fois).
• Accordez la propriété des zones risquées (migrations, config partagée, UI centrale).
• Intégrez les changements upstream quotidiennement pour ne pas dériver.
• Si un fichier est constamment « chaud », travaillez en binôme plutôt que de vous heurter en parallèle.

Si les conflits sont constants, c’est généralement le signe que vous intégrez trop tard, pas que Git est le problème.

Prévisibilité des releases pour une cadence hebdomadaire

La prévisibilité signifie trois choses : vous savez quand la release part, vous savez ce qu’elle contient, et vous savez quelles vérifications doivent passer avant le déploiement. Les équipes ratent généralement les releases hebdomadaires parce qu’elles mêlent décisions de périmètre et corrections de dernière minute.

En trunk-based, les releases hebdomadaires restent prévisibles quand main reste vert. Vous mergez des petits changements souvent et contrôlez le périmètre avec des feature flags plutôt qu’avec des branches longues. Cela permet au train hebdomadaire d’avancer même si une fonctionnalité n’est pas terminée. Le code peut être débarqué, mais le comportement utilisateur reste désactivé tant qu’il n’est pas prêt.

Les gates qualité sont souvent plus simples car il n’y a qu’un endroit à valider :

• Les tests automatisés doivent passer sur main.
• La QA teste un candidat stable, pas ce qui est arrivé il y a une heure.
• Les étapes de rollout et de rollback sont documentées.
• Il y a une heure limite claire pour la release (même si des commits continuent d’arriver).

Avec GitFlow, la prévisibilité vient de la branche de release qui agit comme une zone gelée. Vous choisissez un cutoff, créez release/*, et n’autorisez que les changements nécessaires pour livrer. Cette frontière aide, mais ajoute de la coordination car les corrections doivent souvent être appliquées à plusieurs endroits (release et develop).

Le travail inachevé est géré différemment :

• Trunk-based : mergez les parties sûres et gardez le reste derrière des flags.
• GitFlow : laissez le travail inachevé dans develop et excluez‑le de la branche de release.

Exemple : si les améliorations du checkout sont à moitié faites mercredi, le trunk-based peut merger les refactors sûrs et garder la nouvelle UI cachée. GitFlow les laisse généralement dans develop, on livre sans elles et on finit pour la prochaine release hebdomadaire.

Flux de hotfix : le chemin le plus rapide et sûr vers la production

Un hotfix n’est pas du travail normal. Il nécessite rapidité, faible risque, et un chemin ramenant le changement là où l’équipe travaille pour éviter de corriger deux fois le même bug.

Commencez par une question : quel code tourne exactement en production maintenant ? Si vous ne pouvez pas répondre en quelques secondes, les hotfixes deviennent des conjectures.

Hotfixes avec trunk-based

Les hotfixes en trunk-based peuvent paraître plus simples parce que main est traité comme la source de vérité.

Flux courant :

• Créez une branche courte à partir du commit de production (souvent main).
• Faites la plus petite correction possible (ajoutez un test si vous pouvez).
• Mergez rapidement dans main.
• Déployez depuis main et tagguez la release.

Parce que l’équipe intègre fréquemment dans main, le hotfix devient naturellement partie de la prochaine release hebdomadaire. Le risque principal est de violer la règle « main est releasable » en laissant du travail à moitié fait dans main. Les feature flags aident, mais gardez‑les désactivés par défaut et vérifiez le hotfix sans activer des fonctionnalités non liées.

Hotfixes avec GitFlow

Dans GitFlow, les hotfixes commencent généralement depuis main (production), puis doivent être mergés dans develop pour ne pas être perdus.

Flux sûr :

• Créez hotfix/* depuis main au tag de production.
• Corrigez et releasez (soit depuis la branche hotfix, soit après merge dans main).
• Mergez le hotfix dans main et aussi dans develop.
• Si une branche release/* existe, mergez-y aussi.

L’échec le plus courant est d’oublier l’un de ces merges. Une semaine plus tard, le bug « revient » parce que develop n’a jamais reçu le patch.

Une règle simple prévient la plupart des cas : un hotfix n’est pas terminé tant qu’il n’a pas été mergé dans toutes les branches longues qui vont de nouveau être livrées.

Comment garder les environnements QA stables (sans bloquer l’équipe)

La livraison hebdomadaire tombe à l’eau quand « QA » signifie « ce qui est déployé maintenant ». Nommez vos environnements et donnez‑leur une mission : dev pour le feedback rapide, QA pour les tests d’équipe, staging pour les vérifications de release, prod pour les clients. Si vous ne pouvez pas expliquer la finalité d’un environnement en une phrase, les gens l’utiliseront mal.

Règles pour éviter les cibles mouvantes

La stabilité de la QA dépend moins du modèle de branches que de ce que vous déployez.

En trunk-based, ne déployez pas des commits aléatoires en QA. Déployez un candidat épinglé (build taggé, numéro de build, ou une branche release‑candidate de courte durée) qui passe les mêmes vérifications à chaque fois. La QA obtient quelque chose de fixe à tester, même si le développement continue sur main.

En GitFlow, la QA suit généralement la branche de release. Le piège est de laisser la branche de release changer après le début des tests. Une fois la QA lancée, traitez la branche de release comme un contrat : n’acceptez que des corrections approuvées et uniquement via un processus clair.

Un petit ensemble de règles rend les deux approches prévisibles :

• Déployez en QA uniquement depuis des builds passants.
• Épinglez la version déployée (tag, numéro de build, ou tête de branche de release) et annoncez‑la.
• Limitez les changements en QA aux corrections de bugs, pas aux nouvelles fonctionnalités.
• Réinitialisez les données de test selon un planning et documentez ce qui est effacé.
• Gardez la configuration sous forme de code (variables et templates) pour réduire la dérive des environnements.

Si votre équipe utilise AppMaster pour une partie du build, gardez le même principe : régénérez et déployez un build spécifique pour la QA, pas un ensemble d’éditions en perpétuel changement.

Quand plusieurs équipes partagent la QA

Un seul environnement QA partagé devient un goulot d’étranglement quand deux équipes ont besoin de versions différentes. Si vous ne pouvez pas vous permettre des environnements QA séparés, ajoutez une règle légère de réservation : une équipe occupe la QA sur une fenêtre horaire, les autres utilisent dev ou staging. Les feature flags aident aussi car le travail inachevé peut être déployé sans être visible aux testeurs.

Exemple : l’équipe A valide le candidat hebdomadaire, donc la QA reste épinglée au build 1842 jusqu’à la validation. L’équipe B peut continuer à merger des corrections, mais ces changements attendent le prochain candidat au lieu de modifier ce que la QA teste en cours de cycle.

Étape par étape : choisissez un workflow que votre équipe peut suivre chaque semaine

Écrivez ce que « livraison hebdomadaire » signifie pour vous. Choisissez un jour et une heure de release, décidez du niveau de risque acceptable (par exemple, « pas de bugs P1 connus »), et notez la taille de l’équipe et les fuseaux horaires. Cela empêche les débats sur les branches de se transformer en disputes de priorités.

Choisissez un modèle de base et engagez‑vous à le suivre pendant un mois. Ne mélangez pas les modèles dès le premier jour. Le mélange ajoute des règles sans réduire les surprises.

Un workflow hebdomadaire simple à adapter :

• Gardez les branches courtes (quelques heures à 1‑2 jours) et mergez au moins quotidiennement.
• Ajoutez des garde‑fous : CI rapide, revue courte obligatoire, et un petit ensemble de tests automatisés qui détectent les vraies régressions.
• Décidez comment contrôler le périmètre : feature flags, une branche de release courte en fin de semaine, ou des tags pour le commit exact de la release.
• Définissez les étapes de hotfix : qui peut déclencher, quelles vérifications sont requises, et comment la correction revient dans la ligne principale.
• Gardez la QA stable : décidez ce que la QA suit (branche de release ou candidat épinglé) et ne le changez pas en cours de test sauf si vous redémarrez le cycle.

Rédigez le workflow minimal sur une page. Il doit être assez court pour qu’un nouveau membre puisse le suivre sans réunion. Cela compte encore plus si une partie de l’équipe travaille visuellement (par exemple dans AppMaster) et une autre en code, car les transferts échouent quand les règles ne vivent que dans la tête de quelqu’un.

Exemple : une release hebdomadaire réaliste dans les deux modèles

Imaginez une équipe produit de 6 personnes qui livre chaque vendredi. Deux testeurs QA partagent un environnement staging, donc si staging est instable, les tests s’arrêtent pour tout le monde.

Une semaine chargée avec GitFlow

Lundi : trois développeurs terminent des fonctionnalités et ouvrent des PRs vers develop. La QA commence à tester le staging construit depuis develop.

Mercredi : l’équipe découpe release/1.8 pour protéger la livraison de vendredi. Le nouveau travail continue d’atterrir dans develop, mais la QA se concentre maintenant sur la build de release.

Jeudi après‑midi : un bug tardif apparaît. La correction atterrit d’abord dans release/1.8 pour que la QA puisse retester rapidement. Puis quelqu’un merge ce correctif dans develop, c’est là que les erreurs arrivent souvent.

Rythme typique :

• Lun‑Mar : features merge dans develop, staging change souvent.
• Mer : création de release/1.8, staging passe aux builds de release.
• Jeu : correction dans release/1.8, puis merge dans develop.
• Ven : merge de release/1.8 dans main, tag et déploiement.

La même semaine en trunk‑based

La semaine est structurée autour de petits merges fréquents dans main. Les fonctionnalités sont livrées derrière des flags afin que le travail inachevé puisse être mergé sans impacter les utilisateurs.

Lun‑Jeu : les développeurs mergent de petits changements quotidiennement. La QA teste un build candidat épinglé.

Mardi : un incident de production apparaît. Le hotfix est une branche courte issue de main, merge immédiatement après revue, puis promu en production. Comme main est la source de vérité, il n’y a pas d’étape de back‑merge supplémentaire.

Dans les deux cas, l’équipe a besoin de règles claires de promotion :

• Staging exécute le dernier build candidat épinglé, pas chaque nouveau commit.
• La QA demande un nouveau candidat quand elle est prête, pas automatiquement.
• Seules les corrections pour la release du vendredi peuvent changer le candidat.
• Tout le reste reste derrière des flags ou hors du candidat.

Erreurs courantes qui créent du churn et une QA instable

La plupart des équipes échouent non pas parce qu’elles ont choisi le « mauvais » modèle, mais parce que les habitudes quotidiennes ne correspondent pas au modèle, si bien que la QA devient bruyante et les releases semblent aléatoires.

Un problème courant est de laisser des branches en suspens pendant des jours parce que « ce n’est pas prêt ». Le code diverge de main, les conflits s’accumulent, et la QA finit par tester un mélange de travail ancien et nouveau que personne ne peut reproduire.

Autre erreur : utiliser GitFlow sans gel réel. Une branche de release est censée stabiliser, mais les équipes y glissent encore « juste une modification ». Cela transforme la branche de release en une deuxième ligne principale, et personne ne sait ce que la QA approuve.

La QA devient instable aussi lorsqu’on la traite comme une décharge pour des builds à moitié finis. Si chaque commit arrive en QA sans règles, les testeurs passent leur temps à courir après des cibles mouvantes au lieu de valider une release.

Les erreurs qui créent le plus de churn :

• Branches feature longues qui mergent tard et cassent du travail non lié.
• Branches de release qui acceptent encore des nouvelles fonctionnalités.
• Pas de chemin de promotion clair, si bien que le build testé par la QA n’est pas celui qui part en production.
• Hotfixes faits à la va‑vite puis jamais mergés partout.
• Environnements sans propriétaire, sans but et sans plan de reset.

Gardez un ensemble de règles que tout le monde peut répéter :

• La QA teste uniquement un candidat épinglé.
• Vous promouvez le même artefact de la QA vers la production.
• Chaque environnement a un propriétaire et un cycle de reset.
• Les hotfixes reviennent dans la ligne principale le jour même.

Checklist rapide pour livrer chaque semaine sans surprises

La livraison hebdomadaire fonctionne quand votre équipe peut répondre à quelques questions ennuyeuses avec confiance. Si vous répondez « non » à deux ou plus, attendez‑vous à des corrections de dernière minute et à des cahots QA.

• Y a‑t‑il une branche que vous pouvez déployer en toute sécurité aujourd’hui ? Elle doit builder, passer les tests smoke et éviter les changements à moitié câblés.
• Les pull requests restent‑elles petites et atterrissent‑elles en un jour ou deux ? Les PRs longues signent souvent un feedback obsolète et des conflits plus gros.
• La QA teste‑t‑elle un build fixe, pas une cible mouvante ? La QA doit valider un numéro de build ou un candidat de release précis.
• Pouvez‑vous tenir le travail inachevé hors de la release sans drame ? Feature flags, toggles de configuration ou règle claire de découpage du périmètre.
• Quelqu’un peut‑il appliquer un hotfix et rollback sans deviner ? Un petit runbook vaut mieux que du savoir tribal.

Si vous voulez un objectif mesurable : épinglez la QA à un candidat de release et gardez ce candidat inchangé sauf pour des corrections intentionnelles.

Prochaines étapes : choisissez un changement à essayer la semaine prochaine

Si votre équipe est bloquée à débattre trunk-based vs GitFlow, ne réinventez pas tout d’un coup. Choisissez le problème qui vous coûte le plus de temps et lancez une petite expérience pour la prochaine release.

Si les conflits de merge sont le principal problème, raccourcissez immédiatement la durée des branches. Visez l’atterrissage du travail quotidiennement (ou tous les deux jours), en utilisant des feature flags si nécessaire.

Si l’instabilité de la QA est le plus gros souci, commencez par épingler ce que la QA teste et définir une simple étape de promotion.

Un pilote léger :

• Choisissez un dépôt et une équipe.
• Fixez une limite d’âge des branches (par exemple, pas de branche de plus de 2 jours).
• Épinglez la QA sur un build et ne le changez que par promotion explicite.
• Suivez trois métriques : temps de résolution de merge, heures de retouche QA, et temps de mise en production d’un hotfix.
• Révisez après 2–4 semaines et ajustez.

Si vous voulez réduire la pression sur les releases pour des outils internes ou des portails clients, une plate‑forme no‑code comme AppMaster (appmaster.io) peut aussi aider en générant des backends, web et apps mobiles prêts pour la production à partir d’un design visuel. Elle bénéficie néanmoins des mêmes bonnes pratiques : petits changements, QA épinglée et chemin de promotion clair.