Destructieve wijzigingen veilig afhandelen in een Salesforce-deployment

Je verwijdert metadata in Salesforce met een destructiveChanges.xml-manifest dat je naast een package.xml deployt, waarbij je kiest of de verwijderingen voor of na het additieve deel draaien. Het gevaarlijke zit niet in de syntaxis. Het zit erin dat een geslaagde verwijdering niet ongedaan te maken is met een deployment-rollback, en dat juist de componenten die het snelst breken degene zijn die niemand in source control heeft.

Wat is een destructiveChanges-manifest?

Een destructiveChanges-manifest gebruikt hetzelfde formaat als package.xml, met een belangrijk verschil: wildcards worden niet ondersteund. Elk component dat je wilt verwijderen moet met naam genoemd worden.

Een minimale regel ziet eruit als <types><members>Account.Legacy_Score__c</members><name>CustomField</name></types>.

Twee regels waar mensen bij de eerste poging over struikelen:

• Er moet nog steeds een package.xml aanwezig zijn, in dezelfde map. Bij een verwijder-only deployment bevat die de API-versie en geen componenten.
• Verwijderpogingen gaan door ook als sommige genoemde componenten niet in de target bestaan. Dat is handig, en het betekent ook dat een typefout stil faalt in plaats van luid.

Moeten verwijderingen voor of na de deploy draaien?

De Salesforce CLI geeft je allebei, via twee aparte manifests: --pre-destructive-changes verwijdert voor de deploy, --post-destructive-changes erna.

Gebruik standaard post-destructive. Het additieve pakket landt eerst, zodat alles wat nog naar het gedoemde component verwijst in dezelfde deployment omgezet kan worden voordat het verdwijnt.

Gebruik pre-destructive wanneer oud en nieuw botsen. De duidelijkste gevallen:

• Je hergebruikt een API-naam voor een ander component.
• Je wijzigt het type van een veld door het te verwijderen en opnieuw aan te maken.
• Een validatieregel of verplicht veld zou de data- of configuratiewijziging blokkeren die je deployt.

Dit omdraaien levert de twee klassieke fouten op: een verwijdering die faalt omdat er nog naar het component verwezen wordt, of een toevoeging die faalt omdat de naam bezet is.

Wat neemt een verwijdering werkelijk mee?

Hier is botheid op zijn plaats. Een veld verwijderen verwijdert de data. Verwijderde componenten gaan naar de prullenbak tenzij de deployment purgeOnDelete zet, waarmee ze direct verwijderbaar worden. Roll-up summary-velden slaan de prullenbak sowieso over, ongeacht die instelling.

En rollbackOnError, verplicht bij productie-deployments, draait de wijzigingen van een gefaalde deployment terug. Het is geen undo-knop voor een verwijdering die is gelukt. Wil je de data terug na een geslaagde purge, dan zit je in een herstelgesprek, niet in een deploymentgesprek.

Er is ook een categorie schade die nooit in je repository opduikt: rapporten, lijstweergaven en dashboards die naar het veld verwijzen. Dat is configuratie die een businessgebruiker bouwde, meestal niet in Git, en de deployment waarschuwt je er niet voor.

Welke pre-flight checks voorkomen dat een veldverwijdering misgaat?

1. Draai de afhankelijkheidscontrole in Setup. Salesforce meldt formulevelden, validatieregels, layouts en andere declaratieve verwijzingen. Noodzakelijk, maar niet voldoende.
2. Zoek de metadata op API-naam. Grep de repository. Flows, Apex, e-mailtemplates en permission sets verwijzen naar velden als strings, en stringverwijzingen komen niet in elke afhankelijkheidsweergave voor.
3. Controleer rapporten en lijstweergaven apart. Niets in je pipeline weet ervan. Iemand moet kijken.
4. Exporteer eerst de data. Een CSV met de kolom plus record-ID's. Kost tien minuten en is het enige echte vangnet.
5. Draai de lokale tests. Voor Apex-classes en -triggers is het advies van Salesforce zelf om alle lokale tests te draaien, want zo vind je code die nog verwijst naar wat je verwijdert.
6. Check op een actieve Lightning-pagina. Je kunt geen component verwijderen dat aan een actieve Lightning-pagina hangt. Deactiveer eerst de action override in Lightning App Builder.
7. Valideer tegen productie. Een checkOnly-deployment, of --dry-run vanaf de CLI, valideert en draait tests zonder iets op te slaan.

Hoe verdeel je een verwijdering over twee releases?

Het veilige patroon is geen beter manifest. Het is de verwijdering over twee releases splitsen.

1. Release N, deprecatie. Verwijder elke verwijzing: layouts, formules, flows, Apex, permission sets, rapporten. Markeer het veld als deprecated in de omschrijving zodat de volgende persoon het weet. Stop met ernaar schrijven. Deploy niets destructiefs.
2. Laten weken. Laat een rapportagecyclus voorbijgaan. Dan komt het rapport boven dat niemand noemde, en het komt als vraag boven in plaats van als incident.
3. Release N+1, verwijderen. Exporteer de data en deploy dan het destructiveChanges-manifest apart, met verder niets erin.

Een verwijdering alleen uitleveren doet ertoe. Zit hij bij twintig andere wijzigingen en gaat er iets mis, dan isoleer je de oorzaak niet snel, en de rollback neemt de goede wijzigingen mee.

Dezelfde discipline geldt voor hernoemingen, die Git registreert als een delete plus een add. Behandel elke hernoeming als een deprecatie over twee releases, tenzij je kunt aantonen dat niets naar de oude naam verwijst. Meer leveringsplaybooks staan in onze SF Guides.

FAQ

Kan ik een wildcard gebruiken in destructiveChanges.xml?

Nee. Wildcards worden niet ondersteund. Elk te verwijderen component moet expliciet worden genoemd.

Heb ik nog een package.xml nodig als ik alleen verwijder?

Ja. Hij moet in dezelfde map staan, de API-versie bevatten en geen componenten opsommen.

Kan ik een via deployment verwijderd veld herstellen?

Het gaat naar de prullenbak tenzij purgeOnDelete aan stond, en roll-up summary-velden slaan de prullenbak altijd over. Beschouw een data-export als het echte herstelplan.

Waarom slaagde mijn destructieve deployment maar verwijderde hij niets?

Verwijderpogingen gaan door als een genoemd component ontbreekt in de target, dus een verkeerde API-naam levert een groene deployment en geen wijziging op. Vergelijk de target voor en na.

Wanneer moeten verwijderingen voor de deploy draaien in plaats van erna?

Wanneer oude en nieuwe componenten botsen: een API-naam hergebruiken, een veld met een ander type opnieuw aanmaken, of een regel weghalen die de rest van de deployment zou blokkeren.