Développement basé sur le trunk

Présentation

Le développement basé sur le trunk est un workflow dans lequel chaque développeur intègre ses modifications dans une seule branche partagée — le trunk (généralement main) — au moins une fois par jour. Les branches, si elles sont utilisées, sont minuscules et ne vivent que quelques heures, jamais plusieurs semaines. C'est le workflow qui sous-tend la véritable intégration continue et il est privilégié par les équipes qui déploient fréquemment.

L'idée principale

Plus votre code s'éloigne de celui des autres, plus l'intégration devient difficile. Le coût d'un merge croît avec la taille de la divergence : une branche qui a vécu deux semaines accumule davantage de conflits, et ces conflits sont plus difficiles à comprendre car les deux côtés ont beaucoup changé.

Le développement basé sur le trunk s'attaque directement à ce problème en maintenant un écart minimal. Vous intégrez dans le trunk en permanence — au moins une fois par jour — de sorte que tout conflit est petit et détecté pendant que le changement est encore frais dans votre mémoire. Il n'y a pas de branche develop à longue durée de vie ni de merges massifs. Le trunk est toujours dans un état publiable.

Il existe deux styles courants :

• Committer directement sur le trunk. Les petites équipes commitent directement sur main, en s'appuyant sur des vérifications pré-push et des revues en binôme. C'est la forme la plus pure.
• Branches éphémères. Les équipes plus grandes créent une branche pour chaque changement, ouvrent une pull request et la mergent en un jour ou deux. La branche n'existe que le temps d'exécuter la CI et d'obtenir une revue rapide.

Un cycle typique avec branche éphémère ressemble à ceci :

git switch main          # start from the trunk
git pull                 # get everyone else's latest work
git switch -c quick-fix  # tiny, focused branch
# ...a few hours of work...
git switch main
git pull                 # pull again — others have merged since you branched
git merge quick-fix      # fast, because divergence is small
git push                 # back on the trunk within the same day

Le git pull répété est délibéré : puller avant de merger maintient votre branche proche du trunk, ce qui rend le merge trivial. Si vous préférez un historique linéaire, certaines équipes font un rebase de la branche éphémère sur main plutôt que de la merger. Consultez le workflow feature branch pour les mécaniques de branche et pull request en détail.

Feature flags : livrer du travail inachevé en toute sécurité

Si tout le monde merge vers le trunk quotidiennement, comment gérer une fonctionnalité qui prend deux semaines ? On ne peut pas garder une branche vivante aussi longtemps sans annuler tout l'intérêt de la démarche. La réponse est un feature flag — un commutateur à l'exécution qui décide si le nouveau code s'exécute réellement. Vous mergez le code incomplet, mais vous le laissez désactivé :

const featureFlags = { newCheckout: false };

function checkout() {
  if (featureFlags.newCheckout) {
    return "new checkout";
  }
  return "old checkout";
}

console.log(checkout()); // old checkout — flag is off in production

Le nouveau code arrive en production dissimulé derrière le flag. Lorsqu'il est prêt, vous basculez newCheckout à true — sans redéploiement nécessaire. Cela dissocie le déploiement du code de la mise en production d'une fonctionnalité, ce qui permet au travail inachevé de vivre en toute sécurité sur le trunk.

Quelques règles pratiques évitent que les flags ne deviennent ingérables :

• Désactivé par défaut. Le nouveau code est invisible jusqu'à ce que vous l'activiez délibérément, souvent pour les utilisateurs internes en premier.
• Traiter les flags comme temporaires. Une fois qu'une fonctionnalité est entièrement lancée, supprimez le flag et la branche else morte — les flags périmés s'accumulent vite et rendent le code difficile à lire.
• Tester les deux chemins. La CI doit exercer le code avec le flag activé et désactivé, puisque les deux arrivent en production.

Ce qu'il exige

Le développement basé sur le trunk est rapide, mais il n'est pas laxiste — il ne fonctionne qu'avec de bonnes pratiques de soutien :

• CI robuste : chaque push exécute une suite de tests automatisés, car un trunk cassé bloque toute l'équipe.
• Commits petits et fréquents : les grands changements sont décomposés en étapes incrémentales et sûres.
• Feature flags pour tout ce qui ne peut pas être terminé dans une seule branche éphémère.
• Revue de code rapide, souvent via de petites pull requests qui sont mergées en quelques heures.

Si la revue prend des jours, les branches vivent des jours, et vous ne faites plus de développement basé sur le trunk. Les pratiques de soutien ne sont pas des extras optionnels — elles sont ce qui rend la vitesse sûre.

Publier depuis le trunk

Comme le trunk est toujours publiable, les releases sont simples. Deux modèles dominent :

• Release depuis le sommet. Déployez main directement, aussi souvent que vous le souhaitez. Marquez chaque release avec un tag pour pouvoir identifier exactement ce qui a été livré :

  git switch main
  git pull
  git tag -a v1.4.0 -m "Release 1.4.0"
  git push origin v1.4.0

  Copier

• Créer une branche de release. Pour les produits qui publient des releases versionnées, créez une branche de release éphémère depuis le trunk, stabilisez-la et taguez depuis là. Les corrections sont d'abord faites sur le trunk puis cherry-pickées sur la branche de release — jamais l'inverse, pour que le trunk reste la source de vérité.

Les deux maintiennent le trunk en bonne santé : c'est toujours le dernier bon code, et les releases sont des instantanés pris depuis celui-ci.

Trunk-based vs Gitflow

Gitflow optimise pour des releases contrôlées et versionnées avec de nombreux types de branches. Le développement basé sur le trunk optimise pour la vitesse et la livraison continue avec essentiellement une seule branche. Si vous déployez plusieurs fois par jour, le trunk-based convient ; si vous livrez des releases versionnées selon un calendrier, la structure de Gitflow vous servira peut-être mieux.

Quand l'utiliser

Optez pour le développement basé sur le trunk lorsque vous déployez fréquemment, que vous disposez de tests automatisés fiables et que vous pouvez maintenir une revue de code rapide. Il récompense les équipes qui privilégient les boucles de feedback courtes plutôt que les processus lourds. Si vos tests sont instables, que la revue est lente ou que vous devez regrouper le travail en releases planifiées, le workflow feature branch ou Gitflow sera moins douloureux. Pour un tour d'horizon de tous les modèles courants, consultez l'aperçu des workflows Git.

Pratique