Van change sets naar source control in Salesforce: zo doe je het

Samengevat: Om van change sets naar source control over te stappen, zet je de metadata van je org in een Git-repository, gebruik je een source-getrackte ontwikkelomgeving, en deploy je via een pipeline in plaats van componenten handmatig te kiezen. Doe het stapsgewijs: zet source tracking aan, laat een team piloteren op Git en een validate-only pipeline, en ruim change sets scope voor scope op.

Salesforce zelf raadt nu aan om het org-naar-org releasemodel te ontgroeien, en de meeste gidsen vertellen je waarom change sets tekortschieten. Weinige geven je het echte migratiepad. Deze gids is dat pad: een herhaalbaar draaiboek dat je kunt uitvoeren zonder levering te bevriezen.

Wat betekent overstappen van change sets naar source control?

Het betekent de bron van waarheid voor je metadata uit de org halen en in een version-controlsysteem zetten, meestal Git. Change sets kopieren componenten org naar org en laten geen historie na. Source control bewaart elke layout, flow, permission set en Apex-klasse als geversioneerde bestanden, zodat je kunt branchen, reviewen, deployen en terugrollen. De org wordt een deploy-doel in plaats van het masterrecord.

Waarom weg van change sets?

Change sets zijn een prima startpunt en blijven nuttig voor kleine teams. Ze lopen tegen een muur naarmate je groeit:

• Geen version control en geen historie van wie wat wijzigde.
• Geen automatische rollback als een deployment misgaat.
• Geen code review voordat wijzigingen landen.
• Handmatige selectie van elk component, wat traag en foutgevoelig is.
• Niet-ondersteunde metadatatypes en onveranderbare, niet-bewerkbare uploads.

Hoe migreer je van change sets naar source control?

Voer deze stappen op volgorde uit. Het doel is een werkende pipeline voor een scope voordat je uitbreidt.

1. Maak de repository. Zet een Git-repo op en spreek een branching-model af dat je team begrijpt.
2. Zet source tracking aan in productie. Nieuwe Developer- en Developer Pro-sandboxen erven het dan, wat automatische wijzigingsvastlegging mogelijk maakt.
3. Leg een baseline vast. Haal je bestaande org-metadata op met de Salesforce CLI en commit die als eerste snapshot van de waarheid.
4. Converteer naar source format. Gebruik de CLI om grote metadatabestanden op te splitsen in kleinere, mergebare bronbestanden die conflicten verminderen.
5. Piloteer een team. Verplaats een enkel team of project naar feature branches en een validate-only deployment terwijl de rest change sets blijft gebruiken.
6. Voeg continuous integration toe. Bouw een pipeline die elke pull request valideert en gemergede source naar de volgende omgeving deployt.
7. Ruim change sets per scope op. Zodra de eerste pipeline vertrouwd is, zet je die scope van change sets af en herhaal je voor het volgende team.

Change sets versus source control: wat verandert er echt?

• Bron van waarheid: de org wordt een deployment-doel; de repository houdt de waarheid.
• Wijzigingen vastleggen: handmatig aanvinken wordt automatische source tracking.
• Review: geen review wordt pull requests.
• Deploy: handmatige klikken worden een herhaalbare pipeline.
• Herstel: geen rollback wordt terugdraaien-en-herdeployen vanuit historie.

Welke tools moet je gebruiken?

De gratis basis is die van Salesforce zelf: de Salesforce CLI, Salesforce DX en DevOps Center, dat change sets vervangt door een Git-gebaseerde UI en integreert met GitHub en Bitbucket. Als je beheerde pipelines, back-ups, metadata-bewuste diffs en quality gates nodig hebt, bouwen platforms zoals Serpent, Copado, Gearset, AutoRABIT, Flosum, Salto en Blue Canvas voort op dezelfde Git-basis. Begin gratis en neem een platform wanneer proces, niet tooling, je knelpunt is. We lopen dit specifieke upgradepad door op change sets versus Serpent. Voor meer Salesforce DevOps how-tos, zie de Serpent-gidsen.

Hoe vermijd je veelgemaakte migratiefouten?

Probeer geen big-bang overstap. Migreer een scope tegelijk en houd change sets parallel draaien tot elke pipeline bewezen is. Zet source tracking aan voordat je bouwt, niet erna, anders leggen je eerste sandboxen geen wijzigingen vast. En baseline de hele org voordat iemand een feature branch begint, zodat je repository vanaf dag een productie weerspiegelt in plaats van ervan af te drijven.

FAQ

Moet ik direct stoppen met change sets?

Nee. Migreer scope voor scope en houd change sets voor teams die nog niet over zijn, zodat levering nooit bevriest.

Welke omgevingen ondersteunen source tracking?

Scratch orgs en Developer- en Developer Pro-sandboxen ondersteunen source tracking; Partial Copy- en Full-sandboxen niet.

Is DevOps Center genoeg, of heb ik een betaalde tool nodig?

DevOps Center is een gratis, Git-gebaseerd startpunt. Voeg een commercieel platform toe wanneer je beheerde pipelines, back-ups of geavanceerde quality gates nodig hebt.

Hoe baseline ik een bestaande org?

Haal de metadata van de org op met de Salesforce CLI, converteer naar source format en commit die als eerste versie in je repository.