Strategies de branches Git pour les equipes Salesforce : guide pratique

Reponse courte : la plupart des equipes Salesforce devraient commencer par un modele de feature branch, ou main reflete toujours la production et chaque changement vit sur sa propre branche de courte duree. N'ajoutez des branches d'environnement ou de release que si le packaging, des trains de release paralleles ou une grande equipe l'imposent. La partie propre a Salesforce n'est pas le graphe Git, c'est le mapping de chaque branche longue vers une sandbox et la gestion des conflits de fusion sur la metadata.

La strategie de branches est l'endroit ou la plupart des mises en place DevOps Salesforce se mettent en place ou s'effondrent sous leur propre poids. Copiez un modele complexe dont vous n'avez pas besoin et chaque developpeur paie un impot quotidien; choisissez-en un adapte a votre rythme de release et Git s'efface.

Qu'est-ce qu'une strategie de branches Git, et pourquoi Salesforce est-il different ?

Une strategie de branches est l'ensemble des regles selon lesquelles votre equipe cree, fusionne et promeut des branches. Sur Salesforce, elle pese plus lourd pour trois raisons : votre source de verite est de la metadata declarative (XML) autant que de l'Apex, vos environnements sont des orgs et des sandboxes plutot que des serveurs, et vous ne pouvez pas compiler tout le projet en local, donc la validation se fait contre une org. Cela rend inevitables deux questions que d'autres stacks peuvent reporter : quelle branche represente quelle sandbox, et comment resoudre les conflits dans des fichiers comme les profils et les flows que beaucoup de gens touchent. Salesforce DevOps Center, desormais disponible pour tous, s'appuie la-dessus en traitant GitHub ou Bitbucket comme la source unique de verite.

Quelles strategies de branches Git les equipes Salesforce utilisent-elles vraiment ?

Quatre modeles couvrent presque toutes les equipes :

• Feature branch (GitHub Flow). main est toujours livrable; chaque changement part de main et y revient via une pull request. Le plus simple a operer, et la meilleure valeur par defaut pour la plupart des equipes.
• Branche par environnement. Une branche longue par org (dev, uat, main), promue par fusion vers l'amont. Intuitif et facile a visualiser, mais sujet a la derive quand un hotfix saute une etape.
• Branche de release. Une release/x de courte duree tiree de main pour stabiliser une version pendant que le nouveau travail continue. Utile quand vous groupez les changements en releases planifiees.
• Gitflow. Branches feature, develop, release et hotfix ensemble. Puissant pour les versions paralleles et le packaging ISV, lourd pour une equipe a production unique.

Comment mapper les branches vers les sandboxes Salesforce ?

Associez chaque branche longue a une sandbox adaptee a son role, et laissez les limites de rafraichissement guider la forme. Salesforce rafraichit les sandboxes Developer et Developer Pro chaque jour, Partial Copy tous les 5 jours et Full tous les 29 jours, donc une sandbox Full servant a l'UAT finale ne peut pas etre votre cible d'integration rapide. Un mapping courant et peu couteux :

1. Les branches feature/* vers des sandboxes Developer ou Developer Pro pour construire.
2. Une branche d'integration vers une sandbox Partial Copy pour des tests combines.
3. main valide contre une sandbox Full avant d'atteindre la production.

La mecanique complete est dans comment mapper les branches Git vers les sandboxes Salesforce.

Comment gerer les conflits de fusion sur la metadata ?

C'est la que la strategie de branches Salesforce fait vraiment mal. Les profils, permission sets et flows sont de gros fichiers XML que beaucoup de changements touchent, donc des fusions naives les corrompent. Gardez des branches courtes pour qu'elles divergent moins, decoupez les profils en permission sets, et utilisez un merge driver conscient de Salesforce qui comprend le XML au lieu de le fusionner ligne par ligne. Nous detaillons cela dans comment mettre en place un merge driver Git conscient de Salesforce.

Quelle strategie de branches votre equipe doit-elle choisir ?

Alignez le modele sur votre cadence de release, pas sur un organigramme :

• Une org de production, releases frequentes : feature branch depuis main. N'ajoutez rien de plus.
• Releases planifiees avec un gel : feature branches plus une branche de release.
• ISV ou plusieurs versions supportees : Gitflow, ou un modele package-par-branche.

Quand deux options semblent aussi valables, choisissez la plus simple; vous pourrez toujours monter en gamme plus tard. Notre regle de decision pour les strategies de branches Git en fait une seule question a trancher en reunion. Et parce que tout modele finira par livrer un mauvais changement, associez-le a un plan de rollback des deploiements Salesforce echoues.

Ou se place l'outillage ?

La strategie, c'est Git; l'outil automatise la promotion le long de celle-ci. Des plateformes comme Copado, Gearset et AutoRABIT supposent chacune un modele de branches, donc choisir votre modele d'abord vous evite d'etre enferme dans celui d'un autre. Si vous deplacez une configuration de branches existante vers un nouveau pipeline, notre guide de migration explique comment emporter vos branches sans reecriture. Pour plus de how-tos DevOps Salesforce, parcourez nos SF Guides.

FAQ

Quelle est la meilleure strategie de branches Git pour Salesforce ?

Pour la plupart des equipes, un modele de feature branch avec une branche main toujours livrable. C'est le plus simple a operer et il tient jusqu'a ce que le packaging ou des releases paralleles imposent plus complexe.

Chaque sandbox Salesforce doit-elle avoir sa propre branche ?

Seules les branches longues devraient correspondre a des sandboxes. Les feature branches courtes partagent des sandboxes Developer; reservez Partial Copy et Full a l'integration et a la validation finale.

Gitflow convient-il a Salesforce ?

Gitflow convient aux ISV et aux equipes maintenant plusieurs versions a la fois. Pour une org de production unique, il ajoute souvent plus de branches que la cadence n'en a besoin.

Comment eviter les conflits de fusion sur les profils ?

Gardez des branches courtes, preferez les permission sets aux profils, et utilisez un merge driver conscient de Salesforce pour que le XML fusionne par structure plutot que par ligne.