Strategies de branches Git pour equipes Salesforce : une regle

En bref : choisissez votre modele de branches a partir de deux entrees, la taille de l'equipe et la topologie des sandboxes, et rien d'autre. En dessous d'environ quatre contributeurs avec seulement des sandboxes developpeur, une branche main et des branches de fonctionnalite de courte duree. Entre quatre et dix avec une Partial Copy pour l'UAT, ajoutez une branche de release par livraison et arretez-vous la. Au-dela, ou avec une Full sandbox et une fenetre de changement fixe, GitFlow merite sa ceremonie. La branche par environnement est un choix de conformite, pas d'ingenierie.

Que decide vraiment une strategie de branches ?

Trois choses, et seulement trois : ou vit le travail en cours, comment un changement est promu vers l'environnement suivant, et ce qui doit etre vrai avant qu'il atteigne la production. Le reste releve de la decoration de schema.

Les equipes Salesforce se trompent parce que les conseils d'ingenierie generalistes supposent une chose fausse sur la plateforme : qu'une branche vous donne un endroit pour l'executer.

Quels sont les trois modeles, dit simplement ?

Trunk-based avec branches de fonctionnalite courtes

Une seule branche durable, main, qui reflete toujours ce que la production devrait etre. Les branches de fonctionnalite vivent des jours, pas des semaines, et reviennent par pull request. Le moins de pieces mobiles, le moins de conflits, la discipline la plus exigeante.

GitFlow

main pour le code livre, develop pour le travail integre, plus des branches de release et de hotfix. Concu pour des livraisons planifiees et pour maintenir une version en production pendant que la suivante se construit. Cela coute une branche permanente de plus et beaucoup de fusions.

Branche par environnement

Une branche par org : dev, UAT, preproduction, production. C'est souvent la premiere chose que les equipes construisent, parce que cela ressemble au paysage d'orgs qu'elles ont deja. La promotion devient une fusion entre branches d'environnement, ce qui parait propre et se transforme en fusions de fusions et en cherry-pick de routine.

Quelles contraintes Salesforce cassent le conseil des manuels ?

C'est la que s'arretent la plupart des articles sur les branches, et c'est la que se joue la vraie decision.

• Une branche ne vous donne pas une org. Les environnements sont rares et lents. Salesforce impose des intervalles minimaux de rafraichissement de un jour pour Developer et Developer Pro, cinq jours pour Partial Copy et 29 jours pour Full. Le nombre de branches durables reellement testables est plafonne par votre parc de sandboxes, pas par votre maitrise de Git.
• Les metadonnees sont recuperees, pas ecrites. Les administrateurs modifient l'org et quelqu'un recupere plus tard. Une branche durable ne se reconcilie pas avec du travail declaratif qui n'est jamais entre dans Git.
• Certaines choses n'ont aucune branche. Parametres a l'echelle de l'org, licences, certaines configurations et toutes les donnees vivent hors du depot. Un modele qui suppose que chaque difference d'environnement est dans Git vous mentira discretement.
• Il n'y a pas de feature flags pour les clics. Le trunk-based classique s'appuie sur des bascules pour fusionner du travail inacheve. La configuration declarative n'en a souvent pas, donc l'equivalent Salesforce consiste a deployer les metadonnees et a retenir l'affectation du permission set jusqu'a la mise en service.
• Le cout de fusion est asymetrique. Profiles, permission sets et layouts entrent bien plus en conflit que l'Apex. Chaque semaine de vie supplementaire d'une branche multiplie ce cout, ce qui pousse Salesforce vers des branches courtes plus fort que le logiciel classique.

Quelle est donc la regle de decision ?

1. Un a trois contributeurs, sandboxes developpeur uniquement, pas de date de livraison fixe. Main plus branches courtes. Tout le reste est une ceremonie que vous abandonnerez au troisieme mois.
2. Quatre a dix contributeurs, une Partial Copy pour l'UAT, une livraison par sprint. Main, branches courtes, et une branche de release par livraison. Resistez a un develop permanent : votre parc de sandboxes ne le justifie pas.
3. Plus de dix contributeurs, ou une Full sandbox, ou une fenetre de changement fixe, ou vous devez corriger la version en production pendant que la suivante se construit. GitFlow. La ceremonie achete enfin quelque chose de reel.
4. Equipes packages et ISV. Branchez par version de package, pas par environnement. Votre unite de livraison est la version de package et votre banc d'essai est une scratch org : les branches d'environnement modelisent la mauvaise chose.
5. Branche par environnement. Justifiee quand une branche doit etre le miroir auditable de l'etat d'une org, ce qui est une exigence reglementaire et non une preference de livraison. Entrez-y en connaissant le cout : le cherry-pick devient routinier et la derive devient invisible.

Notez que la cadence de livraison apparait a peine. La cadence est un resultat de votre topologie de sandboxes, pas une entree independante, et les equipes qui choisissent selon la cadence souhaitee obtiennent un processus que leurs environnements ne peuvent pas soutenir.

Comment quitter la branche par environnement sans big bang ?

1. Cessez des aujourd'hui de creer de nouvelles branches d'environnement. Le modele arrete de grossir avant de commencer a maigrir.
2. Reconciliez main avec la production et traitez l'ecart comme un vrai backlog, pas une curiosite. C'est en general la que sont les surprises.
3. Transformez les branches d'environnement en cibles de deploiement dans le pipeline plutot qu'en branches Git. L'environnement existe toujours, il cesse simplement d'etre un lieu ou vit du code.
4. Plafonnez l'age des branches de fonctionnalite a un sprint. Au-dela, il faut une frontiere de package ou une porte de permission, pas une branche plus longue.
5. Gardez exactement une branche de release, et seulement si vous soutenez reellement une version en production pendant que vous construisez la suivante.

Faire tenir le modele

Le modele qui survit au contact d'une vraie equipe est celui que le pipeline impose, pas celui du document d'accueil. Si un consultant doit se souvenir des regles de branches, elles sauteront des la premiere semaine de livraison chargee. Serpent fonctionne par tickets avec Git en arriere-plan : la branche, la pull request et le chemin de promotion viennent du ticket, pas de la memoire. D'autres guides de pipeline vivent dans notre bibliotheque SF Guides.

FAQ

Le trunk-based est-il realiste pour une equipe d'administrateurs ?

Oui, et c'est generalement plus simple que GitFlow, car il n'y a qu'une branche a comprendre. La discipline qui compte, ce sont les branches courtes, pas la maitrise de Git.

Faut-il une branche Git par sandbox ?

Non. Une sandbox est une cible de deploiement. Associer une branche a chaque org est la cause principale des fusions de fusions et du cherry-pick permanent.

Combien de temps doit vivre une branche de fonctionnalite ?

Des jours. Un sprint est la limite haute. Au-dela, la derive des metadonnees et les conflits de profils coutent plus que la branche ne rapporte.

Comment gerer les hotfixes en trunk-based ?

Branchez depuis le dernier commit livre, corrigez, validez, deployez, puis refusionnez immediatement dans main pour ne pas perdre le correctif a la livraison suivante.

Le modele change-t-il pour les equipes 2GP ?

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