Delta-deployments in Salesforce: alleen deployen wat is gewijzigd

Een delta-deployment verstuurt alleen de metadata die tussen twee Git-referenties is gewijzigd, in plaats van het hele project. Je berekent hem door commits te diffen, uit die diff een package.xml te genereren en dat manifest te deployen. Dat is op een specifiek punt sneller en minder riskant dan een volledige deployment, en op een ander punt kwetsbaarder: een gedeeltelijk pakket kan struikelen over afhankelijkheden die een volledig pakket per ongeluk al meenam.

Wat is een delta-deployment in Salesforce?

Een delta-deployment is een metadata-deployment waarvan het manifest uit een Git-diff komt in plaats van uit je hele broncode. Drie bewegende delen:

• De diff. Twee Git-refs, meestal je feature branch en de branch waarin je merget.
• Het manifest. Een package.xml met alleen toegevoegde en gewijzigde componenten, plus een destructiveChanges.xml met verwijderingen en hernoemingen.
• De deployment. Een gewone metadata-deploy tegen dat manifest.

Er is niets aan dat exclusief is voor DevOps-leveranciers. Elke tool die delta-deploys aanbiedt, Serpent inbegrepen, doet een variant van dezelfde drie stappen.

Hoe bereken je een delta-pakket?

De gangbare open-source route is sfdx-git-delta, de plugin die de Salesforce Developers-blog doorliep voor unpackaged sources. Let op: het is een onofficiele, door de community onderhouden plugin, dus behandel hem als een afhankelijkheid die van jou is.

1. Zorg dat je CI-checkout genoeg Git-historie heeft. Een shallow clone met diepte een kan niet tegen een basisbranch diffen, en dat is verreweg de meest voorkomende reden dat een delta-job een leeg of verkeerd pakket oplevert.
2. Genereer het manifest: sf sgd source delta --from origin/main --to HEAD --output-dir .
3. Voeg --generate-delta toe als je de gewijzigde bronbestanden naast het manifest wilt uitkopieren. Gebruik dat alleen als --to HEAD is.
4. Bewaak een leeg manifest. Een deployment met een lege package.xml faalt, dus je pipeline moet de deploy-stap overslaan in plaats van te breken.
5. Deploy en pas verwijderingen na de toevoegingen toe: sf project deploy start -x package/package.xml --post-destructive-changes destructiveChanges/destructiveChanges.xml
6. Valideer eerst. Draai hetzelfde manifest als check-only deploy tegen de target voor je echt deployt.

Welke afhankelijkheidsvallen laten delta-deployments falen?

Dit is het deel dat tutorials overslaan. Een volledige deployment neemt elk component mee, dus impliciete afhankelijkheden lossen stilletjes op. Een delta neemt een deelverzameling mee, en elke afhankelijkheid die eerder onzichtbaar was, wordt nu een fout.

Profielen en permission sets

Voeg een veld toe in de delta, en de toegang ertoe staat in het profiel, dat een apart bestand is. Als dat profielbestand niet is gewijzigd, zit het niet in de delta, en landt het veld in de target zonder dat iemand het ziet. De retrieve-kant maakt het erger: Salesforce geeft alleen beveiligingsinstellingen terug voor metadatatypes die in de retrieve-request staan, waarbij gebruikersrechten, IP-ranges en inlogtijden altijd meekomen. Behandel profielen als iets wat je bewust deployt, niet als iets wat de diff voor je bepaalt.

Picklists, record types en vertalingen

Een picklistwaarde verwijderen raakt record types en vertalingen die ernaar verwijzen. sfdx-hardis bouwde delta met dependencies precies hiervoor, want de fout duikt vaak helemaal niet op in de delta-deployment. Hij duikt op in de volgende volledige deployment, weken later, in een andere pipeline.

Apex-tests

Deploy je een gewijzigde class onder RunSpecifiedTests, dan moet de bijbehorende testclass in de target staan en in de testlijst genoemd zijn. Een delta met de class maar zonder de test is een dekkingsfout die op productie wacht.

Flows

Een flow verwijderen via destructiveChanges.xml is een gedocumenteerd platformgat. De workaround is eerst deactiveren door een FlowDefinition te deployen met activeVersionNumber op nul.

Metadata die in een bestand woont

Custom labels, workflows en matching rules proppen veel members in een enkel bestand. Een wijziging van een regel markeert het hele bestand als gewijzigd, en die geforceerd meenemen vraagt om volledige Git-historie, niet om een shallow clone.

Hernoemingen

Git ziet een hernoeming als een delete plus een add. Deploy je die in de verkeerde volgorde, dan verwijder je een component waarnaar nog wordt verwezen, of maak je een duplicaat. Daarvoor bestaat post-destructieve volgorde.

Wanneer deploy je volledig in plaats van delta?

Een bruikbare default, en degene waarmee sfdx-hardis komt, is delta voor feature branches die in een gedeelde branch mergen, en volledige deployments tussen gedeelde omgevingen. De redenering: hoe verder je in de pipeline komt, hoe waarschijnlijker het is dat de target is afgedreven van source control, en een delta gaat ervan uit dat source control de waarheid is.

Ga volledig als een van deze waar is:

• De target-org heeft sinds de laatste deploy handmatige wijzigingen gehad.
• De wijziging raakt profielen, permission sets of sharing settings breed.
• Je promoveert tussen twee langlevende omgevingen in plaats van een feature te mergen.
• Je herstelt van een gefaalde of half toegepaste deployment.

Houd een handmatige override. sfdx-hardis gebruikt een NO_DELTA-markering in de committitel, een goed patroon om over te nemen met welke tooling dan ook: wie weet dat een wijziging riskant is, moet een volledige deploy kunnen forceren zonder pipelineconfig aan te passen.

Hoe ziet een veilige delta-pipeline eruit?

1. Volledige clone, of in elk geval genoeg diepte om de merge base te bereiken.
2. Genereer het manifest en print het in het buildlog, zodat een mens kan lezen wat er gaat vertrekken.
3. Sla netjes over als het manifest leeg is.
4. Check-only deploy, dan de echte deploy, met destructieve wijzigingen als laatste.
5. Volledige deployment op schema, wekelijks of per release, om de drift te vangen die de delta's nooit raakten.

Die laatste stap is degene die teams laten vallen, en juist die vangt het picklist-en-vertalingen-type fout voordat een release op het spel staat. Meer playbooks voor Salesforce-levering staan in onze SF Guides.

FAQ

Zijn delta-deployments veiliger dan volledige deployments?

Ze zijn sneller en raken minder aan, wat de blast radius verkleint. Ze zijn niet intrinsiek veiliger, want een gedeeltelijk pakket kan een afhankelijkheid missen die een volledig pakket wel had meegenomen.

Heb ik sfdx-git-delta nodig voor delta-deployments?

Nee. Het is de meest gebruikte open-source route, en hij is onofficieel en door de community onderhouden. De meeste commerciele Salesforce DevOps-platforms berekenen de delta voor je.

Waarom is mijn delta-pakket leeg in CI maar niet lokaal?

Bijna altijd een shallow clone. Je CI-checkout heeft genoeg Git-historie nodig om de commit te bereiken waarvandaan je difft.

Hoe verwijder ik metadata in een delta-deployment?

Via destructiveChanges.xml, toegepast na het additieve pakket. Flows zijn de uitzondering: deactiveer ze eerst met een FlowDefinition-wijziging.

Moeten profielen deel zijn van de delta?

Deploy ze bewust in plaats van de diff te laten beslissen. Profielbestanden dragen alleen instellingen voor de metadatatypes die in de retrieve zaten, dus een diff-gedreven profiel is zelden het profiel dat je bedoelde.