Source-Driven Development in Salesforce, Uitgelegd

Source-driven development in Salesforce betekent dat je Git-repository, niet de org, de enige bron van waarheid is. Elke wijziging leeft als een geversioneerd bestand, elke deployment is te herleiden tot een commit, en je pijplijn bouwt omgevingen opnieuw op vanuit die bron in plaats van metadata handmatig tussen orgs te klikken. Het is het model waar Salesforce DX omheen is gebouwd, en in 2026 is het de standaardaanname achter vrijwel elk serieus releaseproces.

Wat is source-driven development in Salesforce?

In de klassieke aanpak geldt de org als bron van waarheid. Je maakt wijzigingen in een sandbox, bundelt ze in een change set en duwt ze door, in de hoop dat er onderweg niets afwijkt. Source-driven development draait dat om. Je metadata leeft als bestanden in versiebeheer, en de org wordt een weergave van wat de repository zegt dat hij moet zijn. Zoals Salesforce's eigen DX-documentatie stelt, bewaakt source tracking wat je aanmaakt, wijzigt of verwijdert, zodat de repository en de org eerlijk blijven tegenover elkaar.

De opbrengst is traceerbaarheid. Elke productiewijziging koppelt terug aan een specifieke commit, code review gebeurt voor de merge, en je krijgt gratis een volledig audittrail. Die governance is geen luxe in een gereguleerde Salesforce-org; het is de reden dat source-driven development heeft gewonnen.

Waarin verschilt het van het org development model?

Salesforce levert twee ontwikkelmodellen, en het verschil gaat eigenlijk over source tracking:

• Org development model: je werkt tegen orgs die geen source tracken, zoals productie, Developer Edition-orgs of niet-getrackte sandboxes. Je geeft handmatig aan wat je ophaalt en deployt.
• Source-driven (package) model: je werkt tegen source-getrackte orgs, vooral scratch orgs en source-getrackte sandboxes. Salesforce DX volgt wijzigingen aan beide kanten automatisch, en sf project deploy start of sf project retrieve start verplaatsen alleen wat echt is veranderd.

De meeste teams zitten ergens tussen die twee in. Dat is prima. De richting is echter naar source tracking en weg van handmatige change sets, dezelfde verschuiving die we uitdiepen in waarom elke Salesforce DevOps-tool package development negeert.

Waarom veranderde source format alles?

Source-driven development werkt alleen dankzij source format. Het oude metadata-formaat propt een heel custom object, zijn velden, validatieregels en list views in een lang XML-bestand. Source format splitst dat op in kleine, modulaire bestanden, een per component, onder een hierarchische mappenstructuur. Het resultaat, zoals Gearset documenteert, is schonere diffs en veel minder merge-conflicten: twee ontwikkelaars die verschillende velden op hetzelfde object bewerken botsen niet meer, omdat hun wijzigingen in aparte bestanden leven. Source format is nu Salesforce's aanbevolen standaard voor nieuwe projecten.

Waar doet source-driven development nog pijn?

Dit is het deel dat de meeste uitleg overslaat. Source format splitst niet alles op. Profiles, permission sets, sharing rules, workflows en external services belanden nog steeds in grote, gedeelde bestanden, dus twee mensen die hetzelfde profiel bewerken vechten alsnog in versiebeheer. Source tracking dekt ook niet elk metadatatype; je moet het Metadata Coverage Report checken om te weten wat echt wordt getrackt, en juist die gaten branden teams.

Scratch orgs maken dit in theorie schoner, maar echte orgs dragen jaren aan configuratie die nooit in Git heeft gestaan. Naar source-driven gaan is een migratie, geen schakelaar die je omzet, en de kosten van die stap niet zetten duiken elke release op, precies de rekensom die we maken in de werkelijke kosten van handmatige Salesforce-deployments. Tooling die is gebouwd om die rommelige randen te verzoenen, in plaats van een greenfield-project aan te nemen, scheidt een werkende pijplijn van een demo.

Hoe voer je source-driven development echt in?

1. Zet je metadata in Git in source format. Haal op uit je bestaande org, converteer naar source format en commit. Dit is je nieuwe basislijn.
2. Kies een branching-model dat aansluit op je orgs, zodat elke omgeving vanuit een branch te bouwen is.
3. Zet source tracking aan waar het kan, met source-getrackte sandboxes en scratch orgs voor feature-werk.
4. Automatiseer deploys vanuit commits, zodat niets de productie bereikt behalve via een gereviewde, geversioneerde wijziging.
5. Plan vooraf voor de niet-opgesplitste types, door te beslissen wie profiles en permission sets bezit voordat ze conflicten veroorzaken.

Een pijplijn die Git als bron van waarheid behandelt, wijzigingen nauwkeurig volgt en de metadata aankan die Salesforce niet volledig opsplitst, is precies wat Serpent draait. De open-source stack kan je er ook brengen, en we geven die een eerlijke lezing in onze blik op sfdx-hardis.

FAQ

Is source-driven development hetzelfde als Salesforce DX?

Nee. Salesforce DX is de tooling en het formaat; source-driven development is de praktijk om je Git-repository, in plaats van de org, de bron van waarheid te maken.

Heb ik scratch orgs nodig voor source-driven development?

Nee. Scratch orgs helpen, maar source-getrackte sandboxes ondersteunen ook source tracking, dus je kunt het model invoeren zonder een volledige scratch-org-workflow.

Elimineert source format merge-conflicten?

Het vermindert ze sterk door elk component een eigen bestand te geven, maar profiles, permission sets en enkele andere types delen nog grote bestanden en kunnen botsen.

Kan ik source-driven development mixen met change sets?

Tijdens een overgang wel, maar het doel is handmatige change sets uit te faseren zodat elke wijziging geversioneerd, gereviewd en herleidbaar tot een commit is.