Stratégies de branches Git pour équipes Salesforce : une règle

En bref : choisissez votre modèle de branches à partir de deux entrées, la taille de l'équipe et la topologie des sandboxes, et rien d'autre. En dessous d'environ quatre contributeurs avec seulement des sandboxes développeur, une branche main et des branches de fonctionnalité de courte durée. Entre quatre et dix avec une Partial Copy pour l'UAT, ajoutez une branche de release par livraison et arrêtez-vous là. Au-delà, ou avec une Full sandbox et une fenêtre de changement fixe, GitFlow mérite sa cérémonie. La branche par environnement est un choix de conformité, pas d'ingénierie.

Que décide vraiment une stratégie de branches ?

Trois choses, et seulement trois : où vit le travail en cours, comment un changement est promu vers l'environnement suivant, et ce qui doit être vrai avant qu'il atteigne la production. Le reste relève de la décoration de schéma.

Les équipes Salesforce se trompent parce que les conseils d'ingénierie généralistes supposent une chose fausse sur la plateforme : qu'une branche vous donne un endroit pour l'exécuter.

Quels sont les trois modèles, dit simplement ?

Trunk-based avec branches de fonctionnalité courtes

Une seule branche durable, main, qui reflète toujours ce que la production devrait être. Les branches de fonctionnalité vivent des jours, pas des semaines, et reviennent par pull request. Le moins de pièces mobiles, le moins de conflits, la discipline la plus exigeante.

GitFlow

main pour le code livré, develop pour le travail intégré, plus des branches de release et de hotfix. Conçu pour des livraisons planifiées et pour maintenir une version en production pendant que la suivante se construit. Cela coûte une branche permanente de plus et beaucoup de fusions.

Branche par environnement

Une branche par org : dev, UAT, préproduction, production. C'est souvent la première chose que les équipes construisent, parce que cela ressemble au paysage d'orgs qu'elles ont déjà. La promotion devient une fusion entre branches d'environnement, ce qui paraît propre et se transforme en fusions de fusions et en cherry-pick de routine.

Quelles contraintes Salesforce cassent le conseil des manuels ?

C'est là que s'arrêtent la plupart des articles sur les branches, et c'est là que se joue la vraie décision.

• Une branche ne vous donne pas une org. Les environnements sont rares et lents. Salesforce impose des intervalles minimaux de rafraîchissement de un jour pour Developer et Developer Pro, cinq jours pour Partial Copy et 29 jours pour Full. Le nombre de branches durables réellement testables est plafonné par votre parc de sandboxes, pas par votre maîtrise de Git.
• Les métadonnées sont récupérées, pas écrites. Les administrateurs modifient l'org et quelqu'un récupère plus tard. Une branche durable ne se réconcilie pas avec du travail déclaratif qui n'est jamais entré dans Git.
• Certaines choses n'ont aucune branche. Paramètres à l'échelle de l'org, licences, certaines configurations et toutes les données vivent hors du dépôt. Un modèle qui suppose que chaque différence d'environnement est dans Git vous mentira discrètement.
• Il n'y a pas de feature flags pour les clics. Le trunk-based classique s'appuie sur des bascules pour fusionner du travail inachevé. La configuration déclarative n'en a souvent pas, donc l'équivalent Salesforce consiste à déployer les métadonnées et à retenir l'affectation du permission set jusqu'à la mise en service.
• Le coût de fusion est asymétrique. Profiles, permission sets et layouts entrent bien plus en conflit que l'Apex. Chaque semaine de vie supplémentaire d'une branche multiplie ce coût, ce qui pousse Salesforce vers des branches courtes plus fort que le logiciel classique.

Quelle est donc la règle de décision ?

1. Un à trois contributeurs, sandboxes développeur uniquement, pas de date de livraison fixe. Main plus branches courtes. Tout le reste est une cérémonie que vous abandonnerez au troisième mois.
2. Quatre à dix contributeurs, une Partial Copy pour l'UAT, une livraison par sprint. Main, branches courtes, et une branche de release par livraison. Résistez à un develop permanent : votre parc de sandboxes ne le justifie pas.
3. Plus de dix contributeurs, ou une Full sandbox, ou une fenêtre de changement fixe, ou vous devez corriger la version en production pendant que la suivante se construit. GitFlow. La cérémonie achète enfin quelque chose de réel.
4. Équipes packages et ISV. Branchez par version de package, pas par environnement. Votre unité de livraison est la version de package et votre banc d'essai est une scratch org : les branches d'environnement modélisent la mauvaise chose.
5. Branche par environnement. Justifiée quand une branche doit être le miroir auditable de l'état d'une org, ce qui est une exigence réglementaire et non une préférence de livraison. Entrez-y en connaissant le coût : le cherry-pick devient routinier et la dérive devient invisible.

Notez que la cadence de livraison apparaît à peine. La cadence est un résultat de votre topologie de sandboxes, pas une entrée indépendante, et les équipes qui choisissent selon la cadence souhaitée obtiennent un processus que leurs environnements ne peuvent pas soutenir.

Comment quitter la branche par environnement sans big bang ?

1. Cessez dès aujourd'hui de créer de nouvelles branches d'environnement. Le modèle arrête de grossir avant de commencer à maigrir.
2. Réconciliez main avec la production et traitez l'écart comme un vrai backlog, pas une curiosité. C'est en général là que sont les surprises.
3. Transformez les branches d'environnement en ciblés de déploiement dans le pipeline plutôt qu'en branches Git. L'environnement existe toujours, il cesse simplement d'être un lieu où vit du code.
4. Plafonnez l'âge des branches de fonctionnalité à un sprint. Au-delà, il faut une frontière de package ou une porte de permission, pas une branche plus longue.
5. Gardez exactement une branche de release, et seulement si vous soutenez réellement une version en production pendant que vous construisez la suivante.

Faire tenir le modèle

Le modèle qui survit au contact d'une vraie équipe est celui que le pipeline impose, pas celui du document d'accueil. Si un consultant doit se souvenir des règles de branches, elles sauteront dès la première semaine de livraison chargée. Serpent fonctionne par tickets avec Git en arrière-plan : la branche, la pull request et le chemin de promotion viennent du ticket, pas de la mémoire. D'autres guides de pipeline vivent dans notre bibliothèque SF Guides.

FAQ

Le trunk-based est-il réaliste pour une équipe d'administrateurs ?

Oui, et c'est généralement plus simple que GitFlow, car il n'y a qu'une branche à comprendre. La discipline qui compte, ce sont les branches courtes, pas la maîtrise de Git.

Faut-il une branche Git par sandbox ?

Non. Une sandbox est une cible de déploiement. Associer une branche à chaque org est la cause principale des fusions de fusions et du cherry-pick permanent. Pour l'association bien faite, voir Comment associer les branches Git aux sandboxes Salesforce.

Combien de temps doit vivre une branche de fonctionnalité ?

Des jours. Un sprint est la limite haute. Au-delà, la dérive des métadonnées et les conflits de profils coûtent plus que la branche ne rapporte.

Comment gérer les hotfixes en trunk-based ?

Branchez depuis le dernier commit livré, corrigez, validez, déployez, puis refusionnez immédiatement dans main pour ne pas perdre le correctif à la livraison suivante.

Le modèle change-t-il pour les équipes 2GP ?

Oui. Branchez par version de package et testez en scratch orgs. Les branches d'environnement modélisent un paysage d'orgs vers lequel une équipe package ne livre pas.