Rollbackstrategieen voor mislukte Salesforce-deployments

Kort antwoord: Salesforce heeft geen ongedaan-maken-knop. Een productiedeployment die mislukt draait zichzelf terug, omdat rollbackOnError in productie verplicht op true staat, maar een deployment die slaagt en achteraf fout blijkt, moet je zelf terugdraaien. Je reele opties zijn een omgekeerde deployment vanaf een snapshot van voor de release, een gerichte destructive change, of een fix vooruit. Welke optie je hebt, bepaal je voor de deployment, niet erna.

Waarom heeft Salesforce geen rollback-knop?

Salesforce schrijft metadata direct naar de org. Er is geen transactielog om terug te draaien en geen vorige versie van de org om naar terug te schakelen. De Metadata API biedt precies een vangnet, en dat dekt alleen echte mislukking: bij een productiedeployment moet rollbackOnError op true staan, dus als een component faalt wordt de hele deployment weggegooid en blijft de org zoals hij was (Salesforce Metadata API developer guide).

Dat vangnet doet niets voor het geval waar teams echt bang voor zijn. Een release die schoon deployt, alle tests haalt en om negen uur 's ochtends een bedrijfsproces breekt, is in Salesforce-termen geen mislukte deployment. Terugdraaien betekent een nieuwe deployment bouwen, en die kun je alleen bouwen uit iets dat je eerder hebt vastgelegd.

Wat kun je echt terugdraaien en wat niet?

Hier hoort elk rollbackplan te beginnen, en juist hier zwijgen de meeste plannen. Verdeel je release in drie categorieen voordat je een stap opschrijft.

• Terug te draaien door de oude versie opnieuw te deployen. Apex-classes en triggers, Lightning web components, flows, layouts, validatieregels, permission sets en de meeste declaratieve configuratie. Heb je de vorige broncode, dan zet je die terug.
• Herstelbaar binnen een venster. Een verwijderd custom field komt in Deleted Fields in Object Manager terecht en is 15 dagen lang met data terug te halen, daarna is het weg. Het veld terugzetten zet de page layouts niet terug (achtergrond over verwijderde velden herstellen).
• Feitelijk onomkeerbaar. Verwijderde picklistwaarden, veldtypeconversies die data afkappen, records die door een verkeerde flow of trigger zijn herschreven, en roll-up summary fields die via de Metadata API worden verwijderd en de prullenbak volledig overslaan (Salesforce-documentatie over componenten verwijderen).

In die derde categorie lopen rollbackplannen stuk. Metadata-rollback herstelt configuratie, nooit data. Draaide je release een automatisering over 400.000 records, dan verandert het terugzetten van de Apex van gisteren daar niets aan.

Wat zijn de reele rollbackstrategieen?

1. Omgekeerde deployment vanuit versiebeheer

De betrouwbaarste optie. Staat de branch die de release opleverde in Git, dan is de vorige commit je rollback-artefact. Je bouwt een pakket uit de laatste goede commit en deployt dat eroverheen. Dit dekt alleen componenten die de release wijzigde of toevoegde, dus combineer het met strategie drie.

2. Herstel vanuit een metadata-snapshot

Leg de staat van de doel-org vast vlak voor de deployment en gebruik die snapshot om het omgekeerde pakket te genereren. Dit dekt het geval waarin de org is afgedreven van Git, wat bij de meeste Salesforce-teams zo is. Tools in deze categorie automatiseren de vastlegging en de diff: Gearset, AutoRABIT en Blue Canvas documenteren allemaal rollback op basis van snapshots of restore, en Serpent levert one-click rollback op elk plan, ook het gratis plan.

3. Destructive changes voor alles wat je toevoegde

Een omgekeerde deployment werkt componenten bij die al bestonden. Ze verwijdert niet wat je release aanmaakte, dus een nieuw object of veld blijft staan tenzij je het expliciet verwijdert. Dat vraagt om een destructiveChanges.xml-manifest, een apart artefact dat je moet schrijven. Gebruik destructiveChangesPre.xml om te verwijderen voordat de toevoegingen landen en destructiveChangesPost.xml om erna te verwijderen, zo ontwar je afhankelijkheden zoals een Apex-class die nog verwijst naar het object dat weg moet.

4. Vooruit repareren in plaats van terugdraaien

Vaak de juiste keuze. Zit de fout in een validatieregel of een regel Apex, dan is een hotfix via de normale pipeline sneller en veiliger dan een pakket van 200 componenten terugdraaien. Draai terug als de impact onbekend is. Repareer vooruit als die klein en begrepen is.

Hoe draai je een mislukte Salesforce-deployment stap voor stap terug?

1. Zet de pipeline stil zodat er geen release bovenop de kapotte komt.
2. Benoem de impact: welke componenten, welke automatiseringen, welke records.
3. Kies rollback of fix vooruit en vertel stakeholders wat je koos.
4. Bouw het omgekeerde pakket uit de snapshot of de laatste goede commit.
5. Voeg een destructive manifest toe voor alles wat de release aanmaakte.
6. Valideer het omgekeerde pakket tegen productie voordat je het draait, zodat een incident er geen twee worden.
7. Deploy en controleer het bedrijfsproces, niet de deploymentstatus.
8. Herstel data apart, uit backup, en pas als de metadata stabiel is.

Wat beslis je voor de deployment?

Een rollback is een ontwerpbeslissing die je bij het bouwen neemt. Beantwoord deze vijf voordat de release uitgaat.

• Waar staat de snapshot van de doel-org van voor de release, en is die echt gedraaid?
• Welke componenten in deze release vallen in de onomkeerbare categorie?
• Heeft iets een destructive manifest nodig, en is dat geschreven en gereviewd?
• Is er een databackup die dicht genoeg bij de release ligt om bruikbaar te zijn?
• Wie besluit tot rollback, en welk signaal is de trigger?

Valideren voor je deployt is de goedkoopste preventie die er is. Een validatie met tests blijft 10 dagen bruikbaar en laat je hetzelfde pakket quick deployen zonder de Apex-tests opnieuw te draaien, dus compileerfouten horen niet in productie ontdekt te worden. Meer releaseplaybooks staan in onze SF Guides-bibliotheek.

FAQ

Draait Salesforce een mislukte deployment automatisch terug?

Ja, maar alleen deployments die falen. Productiedeployments vereisen rollbackOnError op true, dus een falend component gooit het hele pakket weg. Een geslaagde deployment wordt nooit voor je teruggedraaid.

Kun je change sets terugdraaien?

Niet standaard. Er is geen omkeerknop, dus teams bouwen een tweede change set die de vorige versie opnieuw deployt, en dat werkt alleen als iemand die versie eerst heeft vastgelegd.

Herstelt een metadata-rollback mijn data?

Nee. Metadata en data zijn losse problemen. Configuratie terugdraaien maakt records die een automatisering aanmaakte, wijzigde of verwijderde niet ongedaan, daarvoor heb je backup en een herstelplan nodig.

Hoelang kan ik een verwijderd custom field herstellen?

15 dagen. Het veld staat in Deleted Fields in Object Manager en is binnen dat venster met data terug te halen, al moet je het soms handmatig terugzetten op page layouts.