Git-branchingstrategieen voor Salesforce-teams: een praktische gids

Kort antwoord: de meeste Salesforce-teams kunnen het beste starten met een feature-branchmodel, waarbij main altijd de productie weerspiegelt en elke wijziging op een eigen kortlevende branch staat. Voeg omgevings- of release-branches pas toe als packaging, parallelle release-trajecten of een groot team dat afdwingen. Het Salesforce-specifieke deel is niet de Git-graaf, maar het koppelen van elke langlevende branch aan een sandbox en het oplossen van metadata-merge-conflicten.

Branchingstrategie is waar de meeste Salesforce-DevOps-opstellingen op hun plek vallen of onder hun eigen gewicht bezwijken. Kopieer een complex model dat je niet nodig hebt en elke developer betaalt dagelijks belasting; kies er een die bij je releaseritme past en Git gaat uit de weg.

Wat is een Git-branchingstrategie, en waarom is Salesforce anders?

Een branchingstrategie is het geheel van regels voor hoe je team branches maakt, samenvoegt en promoot. Op Salesforce weegt dat zwaarder om drie redenen: je bron van waarheid is declaratieve metadata (XML) naast Apex, je omgevingen zijn orgs en sandboxes in plaats van servers, en je kunt het hele project niet lokaal compileren, dus validatie gebeurt tegen een org. Daardoor worden twee vragen onvermijdelijk die andere stacks kunnen uitstellen: welke branch staat voor welke sandbox, en hoe los je conflicten op in bestanden zoals profielen en flows die veel mensen aanraken. Salesforce DevOps Center, nu algemeen beschikbaar, leunt hierop door GitHub of Bitbucket als de single source of truth te behandelen.

Welke Git-branchingstrategieen gebruiken Salesforce-teams echt?

Vier patronen dekken bijna elk team:

• Feature branch (GitHub Flow). main is altijd te releasen; elke wijziging vertakt van main en komt via een pull request terug. Het eenvoudigst om te draaien, en de beste standaard voor de meeste teams.
• Branch per omgeving. Een langlevende branch per org (dev, uat, main), gepromoot door stroomopwaarts te mergen. Intuitief en makkelijk te visualiseren, maar gevoelig voor drift als een hotfix een fase overslaat.
• Release branch. Een kortlevende release/x afgesplitst van main om een versie te stabiliseren terwijl nieuw werk doorgaat. Handig als je wijzigingen bundelt in geplande releases.
• Gitflow. Feature-, develop-, release- en hotfix-branches samen. Krachtig voor parallelle versies en ISV-packaging, zwaar voor een team met een enkele productie.

Hoe koppel je branches aan Salesforce-sandboxes?

Koppel elke langlevende branch aan een sandbox die bij zijn taak past, en laat refresh-limieten de vorm bepalen. Salesforce ververst Developer- en Developer Pro-sandboxes dagelijks, Partial Copy elke 5 dagen en Full elke 29 dagen, dus een Full sandbox voor de laatste UAT kan niet je snelle integratiedoel zijn. Een gangbare, wrijvingsarme koppeling:

1. feature/*-branches naar Developer- of Developer Pro-sandboxes om te bouwen.
2. Een integratiebranch naar een Partial Copy-sandbox voor gecombineerd testen.
3. main gevalideerd tegen een Full sandbox voordat het productie bereikt.

De volledige mechaniek staat in hoe je Git-branches koppelt aan Salesforce-sandboxes.

Hoe ga je om met metadata-merge-conflicten?

Hier doet Salesforce-branching echt pijn. Profielen, permission sets en flows zijn grote XML-bestanden die veel wijzigingen aanraken, dus naieve merges beschadigen ze. Houd branches kortlevend zodat ze minder divergeren, splits profielen op in permission sets, en gebruik een Salesforce-bewuste merge-driver die de XML begrijpt in plaats van die regel voor regel te mergen. We lopen dat door in hoe je een Salesforce-bewuste Git-merge-driver opzet.

Welke branchingstrategie moet je team kiezen?

Stem het model af op je releaseritme, niet op een organigram:

• Een productie-org, frequente releases: feature branch vanaf main. Voeg niets meer toe.
• Geplande releases met een freeze: feature branches plus een release branch.
• ISV of meerdere ondersteunde versies: Gitflow, of een package-per-branch-model.

Als twee opties even geldig lijken, kies de eenvoudigste; je kunt later altijd opschalen. Onze beslisregel voor Git-branchingstrategieen maakt hier een enkele vraag van die je in een vergadering kunt beantwoorden. En omdat elk model ooit een slechte wijziging uitlevert, koppel het aan een plan voor het terugdraaien van mislukte Salesforce-deployments.

Waar past tooling in?

De strategie is Git; de tool automatiseert de promotie erlangs. Platforms zoals Copado, Gearset en AutoRABIT gaan elk uit van een branchingmodel, dus eerst je model kiezen voorkomt dat je in dat van iemand anders wordt geduwd. Verplaats je een bestaande branching-opstelling naar een nieuwe pipeline, dan behandelt onze migratiegids hoe je je branches meeneemt zonder herschrijving. Voor meer Salesforce-DevOps-how-tos, blader door onze SF Guides.

FAQ

Wat is de beste Git-branchingstrategie voor Salesforce?

Voor de meeste teams een feature-branchmodel met een altijd-te-releasen main-branch. Het is het eenvoudigst om te draaien en schaalt tot packaging of parallelle releases iets complexers afdwingen.

Moet elke Salesforce-sandbox een eigen branch hebben?

Alleen langlevende branches horen aan sandboxes gekoppeld te zijn. Kortlevende feature branches delen Developer-sandboxes; reserveer Partial Copy en Full voor integratie en eindvalidatie.

Is Gitflow een goede keuze voor Salesforce?

Gitflow past bij ISVs en teams die meerdere versies tegelijk onderhouden. Voor een enkele productie-org voegt het meestal meer branches toe dan het releaseritme nodig heeft.

Hoe voorkom ik profiel-merge-conflicten?

Houd branches kortlevend, geef de voorkeur aan permission sets boven profielen, en gebruik een Salesforce-bewuste merge-driver zodat XML per structuur samenvoegt in plaats van per regel.