Source-driven development in Salesforce, uitgelegd

Eerst de definitie: source-driven development is het model waarin je Git-repository, en geen enkele org, de bron van waarheid is voor je Salesforce-configuratie en -code. Orgs worden vervangbare omgevingen waar je vanuit de repo naartoe deployt, in plaats van plekken waartussen je wijzigingen kopieert. Al het andere in deze gids volgt uit die ene zin.

Wat is source-driven development in Salesforce?

Bij source-driven development landt elke wijziging eerst in versiebeheer en pas daarna in een org. De repository bevat de bedoelde staat van de org. Een deployment is de handeling waarmee je een org aan die bedoeling gelijk maakt.

Er horen drie praktische eigenschappen bij:

• Historie. Elke wijziging heeft een auteur, een tijdstip en een reden.
• Omkeerbaarheid. Terugrollen is het deployen van een eerdere werkende staat, niet die staat uit je hoofd reconstrueren.
• Parallel werken. Twee mensen kunnen aan hetzelfde object werken zonder dat de een de ander stilletjes overschrijft, omdat de merge expliciet is.

Waarin verschilt dit van org-naar-org deployen?

Org-naar-org deployen, via change sets of via directe vergelijking van twee orgs, gebruikt een levende org als referentie. Dat is het echte verschil, en het heeft gevolgen.

• Waar de waarheid woont. Org-naar-org: de bron-org. Source-driven: de branch.
• Wat een release is. Org-naar-org: een lijst componenten samengesteld door een mens. Source-driven: een diff tussen twee commits.
• Welke historie je krijgt. Org-naar-org: wat de deploylog toevallig bewaarde. Source-driven: de volledige wijzigingshistorie, voorgoed.
• Hoe je terugrolt. Org-naar-org: de vorige staat handmatig herbouwen. Source-driven: de vorige commit deployen.
• Wie het kan auditen. Org-naar-org: wie adminrechten heeft. Source-driven: iedereen die de repo mag lezen, inclusief auditors die nooit in productie horen te komen.

Let op wat er niet in die lijst staat: snelheid. Source-driven development is niet automatisch sneller. Het is herhaalbaar, en dat is een andere en duurzamere eigenschap.

Wat is source tracking en waar werkt het?

Source tracking is de platformfunctie die bijhoudt welke componenten sinds de laatste synchronisatie zijn gewijzigd in een org of in je lokale project, zodat je alleen ophaalt wat echt bewogen is in plaats van alles te retrieven en een diff te lezen.

Waar mensen tegenaan lopen is dekking. Source tracking is beschikbaar in scratch orgs en in Developer- en Developer Pro-sandboxen. Het is niet overal beschikbaar, dus een source-driven model moet antwoord geven op de omgevingen die geen wijzigingen voor je kunnen bijhouden: full sandboxen, partial copies en productie. Precies de orgs waar ongedocumenteerde wijzigingen ontstaan.

Source format of metadata format: wat commit je?

Commit source format. De twee formaten beschrijven dezelfde metadata anders:

• Metadata format is de vorm van de Metadata API: brede bestanden per object plus een package.xml-manifest. Een veldwijziging herschrijft een groot bestand, dus de diff bevat het hele object en reviews worden rumoerig.
• Source format breekt die structuur op: elk veld, elke validatieregel en elke listview krijgt een eigen bestand in een mappenboom, met packagedirectories vastgelegd in sfdx-project.json.

Het effect zit in review en merge, niet in functie. Kleine bestanden geven leesbare diffs en veel minder conflicten wanneer twee mensen hetzelfde object raken, en juist die situatie moet source-driven development overleven.

Wat als de org en de repo van elkaar afwijken?

Dit is de vraag die de meeste uitleg overslaat, en precies de vraag die bepaalt of het model een echt Salesforce-team overleeft. Er zal altijd iemand iets in productie wijzigen. Een hotfix om middernacht, een admin die een picklistwaarde toevoegt, een package-upgrade die metadata herschrijft die jij had gecommit.

Beslis deze drie dingen voor de migratie, niet erna:

1. Wie wint. De repo wint, als beleid. Dat betekent dat een wijziging buiten de lijn niet "verloren" is maar wordt verzoend: opgehaald, met uitleg gecommit en daarna vanuit de branch opnieuw gedeployd.
2. Hoe je het merkt. Draai driftdetectie tegen productie volgens een schema. Divergentie ontdekken op releasemoment is het te laat ontdekken.
3. Wat bewust buiten scope valt. Sommige metadata is echt omgevingsspecifiek of eigendom van een geinstalleerd package. Schrijf die uitsluitingslijst op. Een eerlijke uitsluitingslijst is beter dan een repo die iedereen stiekem wantrouwt.

Hoe voer je dit in zonder Git-vaardig team?

De meeste Salesforce-teams bestaan uit admins en consultants, geen CLI-gebruikers, en daar loopt een source-driven migratie meestal vast. Zet de volgorde zo dat niemand Git hoeft te leren om te kunnen doorwerken:

1. Begin bij een packagegrens. Een team, een set metadata. Probeer niet in week een de hele org te committen.
2. Haal op in source format en krijg een schone deploy van die scope naar een sandbox voordat iemand zijn gewoontes verandert.
3. Zet een poort voor productie. Zelfs een handmatige goedkeuring op een branch telt. Waarheid zonder poort zakt binnen een maand terug.
4. Houd de dagelijkse interface vertrouwd. Admins blijven in een ticket of work item werken; commit, branch en merge horen daaronder te gebeuren.
5. Voeg driftdetectie als laatste toe. Zodra de pipeline vertrouwd wordt, vertelt zij je waar het model lekt.

FAQ

Moet elke admin Git leren voor source-driven development?

Nee. Het vereist dat de repository gezaghebbend is. Welke mensen direct met Git werken is een toolingkeuze, geen eigenschap van het model.

Moet ik mijn org in een keer omzetten naar source format?

Nee. Zet om per packagegrens of per team. Een gedeeltelijke repository die echt gezaghebbend is voor zijn scope is beter dan een complete die niemand vertrouwt.

Is source-driven development hetzelfde als CI/CD?

Nee. Source-driven development bepaalt waar de waarheid woont. CI/CD automatiseert het verplaatsen van die waarheid naar orgs. Het eerste kan zonder het tweede, andersom nauwelijks zinvol.

En metadata die niet in versiebeheer past?

Sommige instellingen en package-eigen componenten komen niet schoon terug. Documenteer ze als uitgesloten en beheers ze per procedure, in plaats van te doen alsof de repo ze dekt.

Serpent is gebouwd voor precies het team dat deze gids beschrijft: de repository blijft de bron van waarheid terwijl admins en consultants in tickets werken, met deltadeployments, driftdetectie en rollback met een klik erbovenop. Meer naslaggidsen vind je in SF Guides.