Comment associer les branches Git aux sandboxes Salesforce

Associer les branches Git aux sandboxes Salesforce, c'est décider quelle branche est la source de vérité pour chaque environnement, pour qu'un changement passe du dev à la production via des merges révisés plutôt que des déploiements d'org à org. Les branches durables sont associées aux sandboxes persistantes ; les branches de fonctionnalité de courte durée aux scratch orgs et sandboxes développeur. Si l'association est bonne, la promotion n'est qu'un merge. Si elle est mauvaise, vous héritez des fusions de fusions et d'une dérive silencieuse.

Ce guide porte sur la mécanique d'association, pas sur le choix du modèle. Si vous hésitez encore entre trunk-based, GitFlow et branche par environnement, commencez par Stratégies de branches Git pour équipes Salesforce : une règle, puis revenez ici pour le câbler à vos orgs.

Quel type de sandbox soutient quelle branche ?

Une branche n'est réelle que s'il existe une org où la déployer et la tester. Associez chaque branche au type de sandbox adapté à son rôle et à sa cadence de rafraîchissement :

• Branche de fonctionnalité vers une scratch org ou une sandbox développeur. Jetable, créée par ticket, supprimée au merge.
• Branche d'intégration vers une sandbox Developer Pro, où le travail de fonctionnalité arrive et se teste ensemble.
• Branche UAT vers une sandbox Partial Copy ou Full, pour que les utilisateurs métier testent contre des données représentatives.
• Branche main vers la production, toujours protégée et mise à jour uniquement via un merge révisé.

La cadence de rafraîchissement plafonne le nombre de branches durables que vous pouvez réellement 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 rafraîchir est une branche à laquelle vous ne pouvez pas vous fier.

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

La promotion est un merge, pas un redéploiement. Un changement démarre sur une branche de fonctionnalité, puis remonte la chaîne à mesure qu'il franchit chaque porte :

1. Créez une branche de fonctionnalité, développez contre sa scratch org ou sa sandbox développeur.
2. Ouvrez une pull request vers la branche d'intégration ; au merge, déployez vers la sandbox d'intégration.
3. Fusionnez l'intégration dans la branche UAT pour la validation métier dans la sandbox Partial Copy ou Full.
4. Fusionnez UAT dans main ; le déploiement en production est la même metadata qui a déjà passé l'UAT.

La règle qui épargne le plus de douleur : ne laissez jamais une branche associée à la production accepter un commit direct. Tout y arrive via un merge révisé, si bien que l'historique de la branche est aussi votre historique de déploiement.

Comment le source tracking garde-t-il une branche et son org synchronisés ?

Le source tracking enregistre quelle metadata a changé dans une sandbox, ce qui vous permet de tirer ces changements dans la branche au lieu de deviner un retrieve complet. Déployez depuis git vers l'org associée, et laissez le source tracking signaler tout ce qu'un administrateur a changé directement dans cette org. Cette boucle garde la branche comme source de vérité et empêche l'org et la branche de diverger en silence.

Les données, les paramètres à l'échelle de l'org et les licences vivent hors du dépôt : l'association ne couvre que la metadata. Traitez-les comme une configuration d'environnement que vous initialisez séparément, pas comme quelque chose qu'une branche peut promouvoir.

Quelles sont les erreurs d'association courantes ?

• Une branche durable par sandbox développeur. Chaque branche durable de plus est une cible de merge supplémentaire qui dérive. Gardez les branches de fonctionnalité courtes et jetables.
• Déployer d'org à org et appeler cela promotion. Si la branche n'est pas ce que vous déployez, son historique cesse de correspondre à ce qui est en production.
• Soutenir une branche UAT avec une sandbox développeur. Sans données représentatives, la validation teste la mauvaise chose et rate les bugs liés à la forme des données.
• Laisser les administrateurs modifier la production directement. Un clic en production qui n'entre jamais dans git transforme votre association en fiction au déploiement suivant.

Faites en sorte que l'association s'impose d'elle-même

Une association qui vit dans un document d'accueil saute dès la première semaine de livraison chargée. Serpent fonctionne par tickets avec Git en arrière-plan : la branche, sa sandbox 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

Faut-il une branche par sandbox ?

Non. Associez les branches durables uniquement aux environnements persistants comme intégration, UAT et production. Utilisez des branches de fonctionnalité de courte durée pour les scratch orgs et orgs développeur.

Quelle sandbox doit soutenir ma branche UAT ?

Une sandbox Partial Copy ou Full, pour que les utilisateurs métier testent contre des données représentatives plutôt qu'une org développeur vide.

Comment un changement est-il promu entre environnements ?

Via un merge révisé d'une branche à la suivante, suivi d'un déploiement depuis git vers l'org associée. La promotion est un merge, pas un redéploiement depuis une org.

Qu'est-ce qui empêche une branche et son org de diverger ?

Le source tracking plus le déploiement depuis git. La branche reste la source de vérité, et tout changement direct dans l'org apparaît comme un diff suivi à réconcilier.

Quel modèle de branches associer en premier ?

Choisissez le modèle avant l'association. Voir notre règle de décision pour choisir selon la taille d'équipe et la topologie de sandbox.