Van change sets naar broncontrole overstappen (stap voor stap)

Kort samengevat: Om van change sets naar broncontrole over te stappen, haal je de metadata van je org op in een Salesforce DX-project, commit je die naar een Git-repository als je enige bron van waarheid, kies je een branch-per-omgeving-model en rol je uit via een geautomatiseerde pipeline in plaats van change sets van org naar org te klikken. Doe het stapsgewijs: begin met één project, bewijs de workflow en breng dan de rest over.

Waarom überhaupt van change sets naar broncontrole?

Change sets zijn een handmatig org-naar-org-hulpmiddel met drie harde grenzen: geen versiegeschiedenis, geen rollback en geen audittrail. Elke uitrol is een verse herschrijving van metadata zonder registratie van wat er veranderde of waarom, en ze bewegen alleen tussen orgs met dezelfde productie. Salesforce zelf raadt teams nu aan DevOps-praktijken over te nemen en het org-naar-org-releasemodel te ontgroeien.

Broncontrole lost alle drie op. Git geeft je één bron van waarheid, een volledige geschiedenis van elke wijziging, branching en merging voor parallel werk, en de mogelijkheid om binnen enkele minuten terug te draaien naar een bekende goede staat. Het is het fundament waarop elke andere DevOps-praktijk rust.

Wanneer is het tijd om over te stappen?

Overweeg de overstap zodra een van deze punten geldt:

• Meer dan één persoon maakt parallel wijzigingen.
• Je draait drie of meer omgevingen.
• Je levert frequente of spoedreleases.
• Je hebt compliance-eisen - goedkeuringen, functiescheiding, audittrails.

Als er twee of meer gelden, kosten change sets je al meer dan ze opleveren.

Hoe stap je stap voor stap van change sets naar broncontrole over?

1. Zet je metadata om naar bronformaat. Gebruik de Salesforce CLI om metadata op te halen in een Salesforce DX-project (SFDX), zodat je org als bestanden wordt beschreven in plaats van als change-set-momentopname.
2. Maak een Git-repository. Commit dat project als je basis - de eerste enige bron van waarheid voor de org.
3. Kies een branch-model. Het eenvoudigst is één langlevende branch per omgeving (bijvoorbeeld dev, uat, main), met feature-branches die via pull requests worden samengevoegd.
4. Automatiseer de uitrol. Richt een pipeline in die bij een merge vanuit elke branch naar zijn omgeving uitrolt en automatisch validatie en tests draait, in plaats van handmatige change-set-uploads.
5. Voeg tests en controles toe. Eis dat Apex-tests, code review en validatie slagen voordat een merge productie bereikt.
6. Zet change sets uit. Houd ze alleen als noodterugval zodra de pipeline vertrouwd is.

Je hoeft dit niet big-bang te doen. Begin met één project of team, bewijs de workflow en breng dan de rest van de org over.

Welke tools heb je nodig voor de overstap?

Minimaal: een Git-host (GitHub, GitLab of Bitbucket), de Salesforce CLI en een Salesforce DX-project. Salesforce' gratis DevOps Center voegt broncontrole, work items en wijzigingsregistratie toe via een point-and-click-interface, een solide eerste stap voor low-code-teams. Groeiende teams stappen meestal over naar een specifiek platform dat broncontrole, geautomatiseerde tests en rollback bundelt, zodat admins niet in de CLI hoeven te leven. Zie hoe de stukken samenkomen in onze SF Guides-bibliotheek.

Voor de denkverandering achter de overstap lees je de verschuiving die je niet meer kunt negeren, en als je klaar bent om een herhaalbare releaseflow te bouwen, gaat onze playbook van change sets naar continue levering een stap verder.

Hoe vermijd je de veelgemaakte migratiefouten?

• Haal niet alles in één keer op. Begin met de metadata die je team actief wijzigt en breid daarna uit.
• Let op profielen en permissiesets. Dat is de lastigste metadata om netjes te versioneren, plan die bewust.
• Draai change sets en Git niet langdurig parallel. Twee bronnen van waarheid doen het doel teniet.
• Neem admins mee. De overstap struikelt vaker over cultuur dan over tooling.

Als je klaar bent om over te stappen zonder de handmatige overhead, loopt onze migratiegids het hele pad met je door.

FAQ

Kan ik van change sets naar Git overstappen zonder code te schrijven?

Grotendeels wel. DevOps Center en externe platforms bieden point-and-click-broncontrole, al voert iemand nog steeds de eerste CLI-ophaling uit om de repository te vullen.

Wat is een Salesforce DX-project?

Het is de bronformaat-weergave van de metadata van je org als bestanden en mappen, opgehaald met de Salesforce CLI, die Git vervolgens bijhoudt en versioneert.

Is DevOps Center een volledige vervanging voor change sets?

Voor veel teams wel. Het voegt versiebeheer en wijzigingsregistratie toe boven op Git, maar grotere teams hebben vaak de geautomatiseerde tests en rollback nodig die specifieke platforms bieden.

Hoe lang duurt de migratie?

Eén project kan in dagen overgaan. Een volledige org met meerdere teams is meestal een gefaseerde uitrol over weken, omgeving voor omgeving.