Git Branching Strategy

Comment une équipe organise le travail en parallèle dans Git, et pour Salesforce, comment cela se rapporte à la structure de ses orgs.

Définition

Une stratégie de branches Git définit comment une équipe organise le travail en parallèle dans le contrôle de version : quelles branches existent (main, develop, feature, release), comment les changements fusionnent entre elles, et quand. Les modèles courants incluent GitFlow (branches develop et release longue durée aux côtés de branches feature), le trunk-based development (branches courtes fusionnées fréquemment dans une seule main), et l'environment branching, une branche par org Salesforce, courant spécifiquement chez Salesforce. Pour les équipes Salesforce, la stratégie de branches correspond généralement directement à la stratégie d'org, chaque branche longue durée correspondant souvent à une sandbox, ce qui signifie que le modèle doit tenir compte de la structure d'environnement propre à Salesforce, pas seulement de l'organisation du code. Se tromper là-dessus cause de vraies difficultés : conflits de fusion dans les fichiers de métadonnées, déploiements qui ne correspondent pas à ce qui se trouve réellement dans un org, et confusion sur quelle branche reflète la production. Notre guide Salesforce DevOps explique comment la stratégie de branches s'intègre dans un processus de release complet.

En pratique

Comment cela fonctionne dans Serpent

Serpent remplace la gestion des branches par un suivi basé sur les Work Items : administrateurs, développeurs et testeurs travaillent via des Work Items au lieu de créer et fusionner des branches manuellement, tandis que Serpent exécute les opérations Git en arrière-plan, sur le dépôt que vous avez déjà sur GitHub ou un autre hébergeur, pour garder un historique exact. Cela élimine les problèmes de conflits de fusion et de prolifération des branches que rencontrent les équipes Salesforce avec les modèles de branching traditionnels, sans perdre l'historique complet des commits ni la capacité de retracer tout changement jusqu'à son Work Item. Les équipes qui veulent un workflow Git natif en ont toujours un ; elles n'ont simplement pas à le gérer à la main. Voir le workflow basé sur les Work Items dans Serpent pour savoir comment il remplace le branching manuel.

Serpent applique une stratégie de branching Git à un pipeline d'orgs Salesforce

Questions fréquentes