Stratégies de branches Git pour les équipes Salesforce : guide pratique

Réponse courte : la plupart des équipes Salesforce devraient commencer par un modèle de feature branch, où main reflète toujours la production et chaque changement vit sur sa propre branche de courte durée. N'ajoutez des branches d'environnement ou de release que si le packaging, des trains de release parallèles ou une grande équipe l'imposent. La partie propre à 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 stratégie de branches est l'endroit où la plupart des mises en place DevOps Salesforce se mettent en place ou s'effondrent sous leur propre poids. Copiez un modèle complexe dont vous n'avez pas besoin et chaque développeur paie un impôt quotidien; choisissez-en un adapté à votre rythme de release et Git s'efface.

Qu'est-ce qu'une stratégie de branches Git, et pourquoi Salesforce est-il différent ?

Une stratégie de branches est l'ensemble des règles selon lesquelles votre équipe crée, fusionne et promeut des branches. Sur Salesforce, elle pèse plus lourd pour trois raisons : votre source de vérité est de la metadata déclarative (XML) autant que de l'Apex, vos environnements sont des orgs et des sandboxes plutôt que des serveurs, et vous ne pouvez pas compiler tout le projet en local, donc la validation se fait contre une org. Cela rend inévitables deux questions que d'autres stacks peuvent reporter : quelle branche représente quelle sandbox, et comment résoudre les conflits dans des fichiers comme les profils et les flows que beaucoup de gens touchent. Salesforce DevOps Center, désormais disponible pour tous, s'appuie là-dessus en traitant GitHub ou Bitbucket comme la source unique de vérité.

Quelles stratégies de branches Git les équipes Salesforce utilisent-elles vraiment ?

Quatre modèles couvrent presque toutes les équipes :

• Feature branch (GitHub Flow). main est toujours livrable; chaque changement part de main et y revient via une pull request. Le plus simple à opérer, et la meilleure valeur par défaut pour la plupart des équipes.
• Branche par environnement. Une branche longue par org (dev, uat, main), promue par fusion vers l'amont. Intuitif et facile à visualiser, mais sujet à la dérive quand un hotfix saute une étape.
• Branche de release. Une release/x de courte durée tirée de main pour stabiliser une version pendant que le nouveau travail continue. Utile quand vous groupez les changements en releases planifiées.
• Gitflow. Branches feature, develop, release et hotfix ensemble. Puissant pour les versions parallèles et le packaging ISV, lourd pour une équipe à production unique.

Comment mapper les branches vers les sandboxes Salesforce ?

Associez chaque branche longue à une sandbox adaptée à son rôle, et laissez les limites de rafraîchissement guider la forme. Salesforce rafraîchit 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 à l'UAT finale ne peut pas être votre cible d'intégration rapide. Un mapping courant et peu coûteux :

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

La mécanique complète est dans comment mapper les branches Git vers les sandboxes Salesforce.

Comment gérer les conflits de fusion sur la metadata ?

C'est là que la stratégie 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 naïves les corrompent. Gardez des branches courtes pour qu'elles divergent moins, découpez 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 détaillons cela dans comment mettre en place un merge driver Git conscient de Salesforce.

Quelle stratégie de branches votre équipe doit-elle choisir ?

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

• Une org de production, releases fréquentes : feature branch depuis main. N'ajoutez rien de plus.
• Releases planifiées avec un gel : feature branches plus une branche de release.
• ISV ou plusieurs versions supportées : Gitflow, ou un modèle package-par-branche.

Quand deux options semblent aussi valables, choisissez la plus simple; vous pourrez toujours monter en gamme plus tard. Notre règle de décision pour les stratégies de branches Git en fait une seule question à trancher en réunion. Et parce que tout modèle finira par livrer un mauvais changement, associez-le à un plan de rollback des déploiements Salesforce échoués.

Où se place l'outillage ?

La stratégie, c'est Git; l'outil automatise la promotion le long de celle-ci. Des plateformes comme Copado, Gearset et AutoRABIT supposent chacune un modèle de branches, donc choisir votre modèle d'abord vous évite d'être enfermé dans celui d'un autre. Si vous déplacez une configuration de branches existante vers un nouveau pipeline, notre guide de migration explique comment emporter vos branches sans réécriture. Pour plus de how-tos DevOps Salesforce, parcourez nos SF Guides.

FAQ

Quelle est la meilleure stratégie de branches Git pour Salesforce ?

Pour la plupart des équipes, un modèle de feature branch avec une branche main toujours livrable. C'est le plus simple à opérer et il tient jusqu'à ce que le packaging ou des releases parallèles imposent plus complexe.

Chaque sandbox Salesforce doit-elle avoir sa propre branche ?

Seules les branches longues devraient correspondre à des sandboxes. Les feature branches courtes partagent des sandboxes Developer; réservez Partial Copy et Full à l'intégration et à la validation finale.

Gitflow convient-il à Salesforce ?

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

Comment éviter les conflits de fusion sur les profils ?

Gardez des branches courtes, préférez les permission sets aux profils, et utilisez un merge driver conscient de Salesforce pour que le XML fusionne par structure plutôt que par ligne.