Git-branchingstrategieën voor Salesforce-teams: hoe kies je?

TL;DR: Een Git-branchingstrategie is het geheel aan regels dat bepaalt waar Salesforce-metadatawijzigingen leven voordat ze productie bereiken. De meeste teams beginnen het best met een eenvoudig feature-branchmodel op een enkele altijd-deploybare main-branch, en voegen pas complexiteit toe wanneer hun releaseritme of teamgrootte dat vraagt. Er is geen enkel juist antwoord, alleen de juiste match met je ritme, je team en hoe je branches op sandboxes aansluiten.

Wat is een Git-branchingstrategie, en waarom heeft Salesforce er een nodig?

Een branchingstrategie bepaalt hoe werk wordt geïsoleerd, beoordeeld en gemerged. In klassieke software is dit bekend terrein. Salesforce voegt twee complicaties toe: je bron van waarheid is declaratieve metadata die uit orgs wordt gehaald in plaats van code die je op één plek schrijft, en Salesforce raadt aan om het org-naar-org change-setmodel te ontgroeien richting Git-releases. Daardoor is de branch-naar-sandbox-koppeling, niet het branchingpatroon zelf, het onderdeel dat teams het vaakst verkeerd doen.

Spreek voordat je een patroon kiest drie dingen af: welke branch productie voorstelt, hoe een wijziging wordt gepromoveerd, en hoe je herstelt als een merge misgaat. Kun je die niet beantwoorden, dan is de patroonnaam decoratie.

Wat zijn de belangrijkste branchingstrategieën voor Salesforce?

Vier patronen dekken vrijwel elk Salesforce-team. Ze ruilen eenvoud in voor controle naarmate je de lijst afgaat.

Feature-branchmodel

Eén langlevende main-branch bevat de laatste deploybare metadata. Elke wijziging krijgt een kortlevende branch, opent een pull request en merged terug na review.

• Het best voor: Kleine tot middelgrote teams die vandaag willen starten.
• Sterkte: Eenvoudig, snel te adopteren, houdt main altijd releasebaar.
• Kost: Minder structuur voor het coördineren van meerdere parallelle releases.

Environment-branchmodel (branch per org)

Elke branch koppelt aan een Salesforce-omgeving: dev, uat, main voor productie. Wijzigingen worden gepromoveerd door de keten omhoog te mergen.

• Het best voor: Teams wiens denkmodel al org-gebaseerd is en die branches sandboxes willen laten spiegelen.
• Sterkte: De pipeline is duidelijk; elke merge is een promotie.
• Kost: Langlevende omgevingsbranches driften, en één wijziging uit een batch cherry-picken is pijnlijk.

GitFlow

Aparte develop-, release-, feature- en hotfix-branches met strikte regels, in 2010 gemaakt voor geplande softwarereleases.

• Het best voor: Grote teams met formele, kalendergebaseerde releasetreinen en zware governance.
• Sterkte: Maximale controle en heldere scheiding van lopend werk.
• Kost: Veel bewegende delen; overkill voor de meeste Salesforce-winkels en traag voor frequente releases.

Trunk-based development

Iedereen commit naar main achter zeer kortlevende branches, met automatisering als vangnet. Het is de richting waar hoogfrequente teams naartoe bewegen.

• Het best voor: Teams met volwassen CI, sterke geautomatiseerde tests en een echt rollback-pad.
• Sterkte: Snelste flow, kleinste batches, minste merge-drift.
• Kost: Onvergeeflijk zonder geautomatiseerde validatie en rollback eerst op orde.

Welke branchingstrategie moet je kiezen?

Match het patroon met je realiteit, niet met het ideaal van een blog:

• Nieuw in versiebeheer? Feature-branch op een enkele main-branch. Niets anders verdient zijn complexiteit nog.
• Denk je in sandboxes? Environment-branch, maar houd de branches zo kortlevend mogelijk en automatiseer de promoties.
• Gereguleerde, kalendergebaseerde releases? GitFlow geeft je de controle die de auditors willen.
• Dagelijks uitleveren met solide automatisering? Trunk-based, zodra je tests en rollback betrouwbaar zijn.

De doorslaggevende factor is zelden het diagram. Het is of je metadata schoon merged en of elke branch een thuis heeft in een echte sandbox. We gaan dieper op die koppeling in hoe je Git-branches op Salesforce-sandboxes koppelt, en zetten een simpele beslisregel uiteen in deze beslisregel-gids.

Welke Salesforce-specifieke valkuilen breken een branchingstrategie?

Hier houdt generiek Git-advies op te volstaan. Let op:

• Metadata die niet schoon merged. Profielen en sommige XML-metadata geven rommelige diffs; geef de voorkeur aan permission sets en kleine, gerichte wijzigingen.
• Langlevende omgevingsbranches die driften. Hoe langer een branch weg van main leeft, hoe zwaarder de uiteindelijke merge. Houd ze kort of verzoen ze vaak.
• Geen rollback-plan. Een branchingstrategie zonder een geteste manier om een slechte merge terug te draaien is een strategie voor trage, angstige releases. Koppel hem aan een echt herstelpad, zoals we behandelen in rollback-strategieën voor mislukte deployments.
• Branches zonder sandbox. Elke branch waar een promotie op mikt heeft een org nodig om tegen te valideren, anders is de pipeline theater.

Je kunt de rest van onze praktische playbooks doorbladeren in de SF Guides-bibliotheek. Als je klaar bent om een echte pipeline van change sets af te halen, is ons migratiepad gebouwd om stapsgewijs te zijn in plaats van een big-bang-herschrijving.

FAQ

Wat is de beste Git-branchingstrategie voor een klein Salesforce-team?

Begin met een feature-branchmodel op een enkele altijd-deploybare main-branch. Het is het eenvoudigste patroon dat je toch review, herleidbaarheid en schone releases geeft.

Is GitFlow goed voor Salesforce?

Alleen voor grote teams met formele, kalendergebaseerde releasetreinen. De vele branches voegen controle toe die de meeste Salesforce-teams niet nodig hebben en vertragen frequente releases.

Moeten Salesforce-branches één-op-één op sandboxes koppelen?

Environment-branchmodellen doen precies dat, wat intuïtief is, maar houd de branches kortlevend om drift te voorkomen. Elke branch waar je naar promoveert heeft een echte org nodig om tegen te valideren.

Hoe verhoudt een branchingstrategie zich tot rollback?

Direct. Branches bepalen hoe wijzigingen aankomen; rollback bepaalt hoe je een slechte ongedaan maakt. Een strategie zonder getest rollback-pad leidt tot trage, voorzichtige releases.