Comment associer les branches Git aux sandboxes Salesforce

Associer les branches Git aux sandboxes Salesforce, c'est decider quelle branche est la source de verite pour chaque environnement, pour qu'un changement passe du dev a la production via des merges revises plutot que des deploiements d'org a org. Les branches durables sont associees aux sandboxes persistantes ; les branches de fonctionnalite de courte duree aux scratch orgs et sandboxes developpeur. Si l'association est bonne, la promotion n'est qu'un merge. Si elle est mauvaise, vous heritez des fusions de fusions et d'une derive silencieuse.

Ce guide porte sur la mecanique d'association, pas sur le choix du modele. Si vous hesitez encore entre trunk-based, GitFlow et branche par environnement, commencez par Strategies de branches Git pour equipes Salesforce : une regle, puis revenez ici pour le cabler a vos orgs.

Quel type de sandbox soutient quelle branche ?

Une branche n'est reelle que s'il existe une org ou la deployer et la tester. Associez chaque branche au type de sandbox adapte a son role et a sa cadence de rafraichissement :

• Branche de fonctionnalite vers une scratch org ou une sandbox developpeur. Jetable, creee par ticket, supprimee au merge.
• Branche d'integration vers une sandbox Developer Pro, ou le travail de fonctionnalite arrive et se teste ensemble.
• Branche UAT vers une sandbox Partial Copy ou Full, pour que les utilisateurs metier testent contre des donnees representatives.
• Branche main vers la production, toujours protegee et mise a jour uniquement via un merge revise.

La cadence de rafraichissement plafonne le nombre de branches durables que vous pouvez reellement soutenir. Salesforce impose des intervalles minimaux de un jour pour Developer et Developer Pro, cinq jours pour Partial Copy et 29 jours pour Full, donc une branche que vous ne pouvez pas rafraichir est une branche a laquelle vous ne pouvez pas vous fier.

Comment la promotion circule-t-elle entre les branches ?

La promotion est un merge, pas un redeploiement. Un changement demarre sur une branche de fonctionnalite, puis remonte la chaine a mesure qu'il franchit chaque porte :

1. Creez une branche de fonctionnalite, developpez contre sa scratch org ou sa sandbox developpeur.
2. Ouvrez une pull request vers la branche d'integration ; au merge, deployez vers la sandbox d'integration.
3. Fusionnez l'integration dans la branche UAT pour la validation metier dans la sandbox Partial Copy ou Full.
4. Fusionnez UAT dans main ; le deploiement en production est la meme metadata qui a deja passe l'UAT.

La regle qui epargne le plus de douleur : ne laissez jamais une branche associee a la production accepter un commit direct. Tout y arrive via un merge revise, si bien que l'historique de la branche est aussi votre historique de deploiement.

Comment le source tracking garde-t-il une branche et son org synchronises ?

Le source tracking enregistre quelle metadata a change dans une sandbox, ce qui vous permet de tirer ces changements dans la branche au lieu de deviner un retrieve complet. Deployez depuis git vers l'org associee, et laissez le source tracking signaler tout ce qu'un administrateur a change directement dans cette org. Cette boucle garde la branche comme source de verite et empeche l'org et la branche de diverger en silence.

Les donnees, les parametres a l'echelle de l'org et les licences vivent hors du depot : l'association ne couvre que la metadata. Traitez-les comme une configuration d'environnement que vous initialisez separement, pas comme quelque chose qu'une branche peut promouvoir.

Quelles sont les erreurs d'association courantes ?

• Une branche durable par sandbox developpeur. Chaque branche durable de plus est une cible de merge supplementaire qui derive. Gardez les branches de fonctionnalite courtes et jetables.
• Deployer d'org a org et appeler cela promotion. Si la branche n'est pas ce que vous deployez, son historique cesse de correspondre a ce qui est en production.
• Soutenir une branche UAT avec une sandbox developpeur. Sans donnees representatives, la validation teste la mauvaise chose et rate les bugs lies a la forme des donnees.
• Laisser les administrateurs modifier la production directement. Un clic en production qui n'entre jamais dans git transforme votre association en fiction au deploiement suivant.

Faites en sorte que l'association s'impose d'elle-meme

Une association qui vit dans un document d'accueil saute des la premiere semaine de livraison chargee. Serpent fonctionne par tickets avec Git en arriere-plan : la branche, sa sandbox et le chemin de promotion viennent du ticket, pas de la memoire. D'autres guides de pipeline vivent dans notre bibliotheque SF Guides.

FAQ

Faut-il une branche par sandbox ?

Non. Associez les branches durables uniquement aux environnements persistants comme integration, UAT et production. Utilisez des branches de fonctionnalite de courte duree pour les scratch orgs et orgs developpeur.

Quelle sandbox doit soutenir ma branche UAT ?

Une sandbox Partial Copy ou Full, pour que les utilisateurs metier testent contre des donnees representatives plutot qu'une org developpeur vide.

Comment un changement est-il promu entre environnements ?

Via un merge revise d'une branche a la suivante, suivi d'un deploiement depuis git vers l'org associee. La promotion est un merge, pas un redeploiement depuis une org.

Qu'est-ce qui empeche une branche et son org de diverger ?

Le source tracking plus le deploiement depuis git. La branche reste la source de verite, et tout changement direct dans l'org apparait comme un diff suivi a reconcilier.

Quel modele de branches associer en premier ?

Choisissez le modele avant l'association. Voir notre regle de decision pour choisir selon la taille d'equipe et la topologie de sandbox.