Stratégies de branches Git pour les équipes Salesforce : comment choisir

En bref : Une stratégie de branches Git est l'ensemble des règles qui décident où vivent les changements de métadonnées Salesforce avant d'atteindre la production. La plupart des équipes devraient commencer par un simple modèle feature-branch sur une seule branche main toujours déployable, et n'ajouter de la complexité que lorsque leur cadence ou la taille de l'équipe l'exige. Il n'y a pas de bonne réponse unique, seulement celle qui convient à votre cadence, votre équipe et la façon dont vos branches correspondent aux sandboxes.

Qu'est-ce qu'une stratégie de branches Git, et pourquoi Salesforce en a-t-il besoin ?

Une stratégie de branches définit comment le travail est isolé, révisé et fusionné. En logiciel classique, c'est un terrain balisé. Salesforce ajoute deux subtilités : votre source de vérité est une métadonnée déclarative extraite des orgs plutôt que du code écrit à un seul endroit, et Salesforce recommande de sortir du modèle change-set org-à-org vers des releases sur Git. Cela fait de la correspondance branche-vers-sandbox, et non du motif de branches lui-même, la partie que les équipes ratent le plus souvent.

Avant de choisir un motif, mettez-vous d'accord sur trois choses : quelle branche représente la production, comment un changement est promu, et comment vous récupérez quand une fusion tourne mal. Si vous ne pouvez pas répondre, le nom du motif n'est que décoration.

Quelles sont les principales stratégies de branches pour Salesforce ?

Quatre motifs couvrent presque toutes les équipes Salesforce. Ils échangent la simplicité contre le contrôle à mesure que l'on descend la liste.

Modèle feature-branch

Une seule branche main de longue durée contient la dernière métadonnée déployable. Chaque changement obtient une branche éphémère, ouvre une pull request et fusionne après revue.

• Idéal pour : Les petites et moyennes équipes qui veulent démarrer aujourd'hui.
• Force : Simple, rapide à adopter, garde main toujours livrable.
• Coût : Moins de structure pour coordonner plusieurs releases parallèles.

Modèle environment-branch (une branche par org)

Chaque branche correspond à un environnement Salesforce : dev, uat, main pour la production. Les changements sont promus en fusionnant vers le haut de la chaîne.

• Idéal pour : Les équipes dont le modèle mental est déjà basé sur les orgs et qui veulent que les branches reflètent les sandboxes.
• Force : Le pipeline est évident ; chaque fusion est une promotion.
• Coût : Les branches d'environnement de longue durée dérivent, et extraire un seul changement d'un lot est pénible.

GitFlow

Des branches dédiées develop, release, feature et hotfix avec des règles strictes, créées pour des releases logicielles planifiées en 2010.

• Idéal pour : Les grandes équipes avec des trains de release formels, calés sur le calendrier, et une gouvernance lourde.
• Force : Contrôle maximal et séparation claire du travail en cours.
• Coût : Beaucoup de pièces mobiles ; excessif pour la plupart des boutiques Salesforce et lent pour des releases fréquentes.

Trunk-based development

Tout le monde commite sur main derrière des branches très éphémères, avec l'automatisation comme filet de sécurité. C'est la direction vers laquelle tendent les équipes à haute fréquence.

• Idéal pour : Les équipes avec une CI mature, des tests automatisés solides et un vrai chemin de rollback.
• Force : Flux le plus rapide, plus petits lots, moins de dérive de fusion.
• Coût : Impitoyable sans validation automatisée et rollback en place d'abord.

Quelle stratégie de branches choisir ?

Adaptez le motif à votre réalité, pas à l'idéal d'un blog :

• Nouveau au contrôle de version ? Feature-branch sur une seule branche main. Rien d'autre ne mérite encore sa complexité.
• Vous pensez en sandboxes ? Environment-branch, mais gardez les branches éphémères autant que possible et automatisez les promotions.
• Releases réglementées, calées sur le calendrier ? GitFlow vous donne le contrôle que veulent les auditeurs.
• Livraison quotidienne avec une automatisation solide ? Trunk-based, une fois vos tests et votre rollback dignes de confiance.

Le facteur décisif est rarement le diagramme. C'est de savoir si vos métadonnées fusionnent proprement et si chaque branche a un foyer dans une vraie sandbox. Nous approfondissons cette correspondance dans comment mapper les branches Git aux sandboxes Salesforce, et posons une règle de décision simple dans ce guide de règle de décision.

Quels pièges propres à Salesforce cassent une stratégie de branches ?

C'est là que le conseil Git générique cesse de suffire. Surveillez :

• Des métadonnées qui ne fusionnent pas proprement. Les profils et certaines métadonnées XML produisent des diffs bruyants ; préférez les permission sets et de petits changements ciblés.
• Des branches d'environnement de longue durée qui dérivent. Plus une branche vit loin de main, plus la fusion finale est dure. Gardez-les courtes ou réconciliez souvent.
• Aucun plan de rollback. Une stratégie de branches sans moyen testé d'annuler une mauvaise fusion est une stratégie de releases lentes et craintives. Associez-la à un vrai chemin de récupération, comme nous le couvrons dans les stratégies de rollback pour les déploiements échoués.
• Des branches sans sandbox. Chaque branche ciblée par une promotion a besoin d'un org pour la valider, sinon le pipeline est du théâtre.

Vous pouvez parcourir le reste de nos guides pratiques dans la bibliothèque SF Guides. Quand vous êtes prêt à sortir un vrai pipeline des change sets, notre parcours de migration est conçu pour être incrémental plutôt qu'une réécriture d'un seul coup.

FAQ

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

Commencez par un modèle feature-branch sur une seule branche main toujours déployable. C'est le motif le plus simple qui vous donne quand même revue, traçabilité et releases propres.

GitFlow est-il bon pour Salesforce ?

Seulement pour les grandes équipes avec des trains de release formels calés sur le calendrier. Ses nombreuses branches ajoutent un contrôle dont la plupart des équipes Salesforce n'ont pas besoin et ralentissent les releases fréquentes.

Les branches Salesforce doivent-elles correspondre une à une aux sandboxes ?

Les modèles environment-branch font exactement cela, ce qui est intuitif, mais gardez les branches éphémères pour éviter la dérive. Chaque branche vers laquelle vous promouvez a besoin d'un vrai org pour la valider.

Quel lien entre une stratégie de branches et le rollback ?

Direct. Les branches décident comment les changements arrivent ; le rollback décide comment vous en annulez un mauvais. Une stratégie sans chemin de rollback testé mène à des releases lentes et prudentes.