Gerer les suppressions sans risque dans un deploiement Salesforce

On supprime des metadonnees Salesforce avec un manifeste destructiveChanges.xml deploye aux cotes d'un package.xml, en choisissant si les suppressions s'executent avant ou apres la partie additive du deploiement. Le danger n'est pas la syntaxe. C'est qu'une suppression reussie n'est pas annulable par un rollback de deploiement, et que les composants les plus susceptibles de casser sont ceux que personne n'a dans le controle de source.

Qu'est-ce qu'un manifeste destructiveChanges?

Un manifeste destructiveChanges utilise le meme format que package.xml, avec une difference majeure: les jokers ne sont pas pris en charge. Chaque composant a supprimer doit etre nomme.

Une entree minimale ressemble a <types><members>Account.Legacy_Score__c</members><name>CustomField</name></types>.

Deux regles qui piegent a la premiere tentative:

• Un package.xml doit toujours etre present, dans le meme repertoire. Pour un deploiement de suppression seule, il porte la version d'API et ne liste aucun composant.
• Les tentatives de suppression se poursuivent meme si certains composants listes n'existent pas sur la cible. C'est pratique, et cela signifie aussi qu'une faute de frappe echoue en silence.

Les suppressions doivent-elles s'executer avant ou apres le deploiement?

La CLI Salesforce offre les deux, via deux manifestes distincts: --pre-destructive-changes supprime avant le deploiement, --post-destructive-changes apres.

Par defaut, choisissez post-destructive. Le paquet additif arrive d'abord, donc tout ce qui reference encore le composant condamne peut etre reoriente dans le meme deploiement avant sa disparition.

Choisissez pre-destructive quand l'ancien et le nouveau entrent en collision. Les cas les plus nets:

• Vous reutilisez un nom d'API pour un autre composant.
• Vous changez le type d'un champ en le supprimant puis en le recreant.
• Une regle de validation ou un champ obligatoire bloquerait le changement de donnees ou de configuration que vous deployez.

Inverser l'ordre produit les deux echecs classiques: une suppression qui echoue parce qu'un element reference encore le composant, ou un ajout qui echoue parce que le nom est pris.

Que emporte reellement une suppression?

Autant etre direct. Supprimer un champ supprime ses donnees. Les composants supprimes vont a la corbeille sauf si le deploiement active purgeOnDelete, qui les rend immediatement eligibles a la suppression. Les champs de recapitulation contournent la corbeille quel que soit ce reglage.

Et rollbackOnError, obligatoire pour les deploiements en production, annule les changements d'un deploiement echoue. Ce n'est pas un bouton d'annulation pour une suppression reussie. S'il faut recuperer les donnees apres une purge reussie, vous etes dans une conversation de restauration, pas de deploiement.

Il existe aussi une categorie de casse qui n'apparait jamais dans votre depot: rapports, vues de liste et tableaux de bord referencant le champ. C'est de la configuration construite par un utilisateur metier, rarement dans Git, et le deploiement ne vous en avertira pas.

Quels controles prealables evitent une suppression de champ ratee?

1. Lancez le controle de dependances dans Setup. Salesforce signalera champs de formule, regles de validation, mises en page et autres references declaratives. Necessaire, pas suffisant.
2. Cherchez les metadonnees par nom d'API. Passez le depot au grep. Flows, Apex, modeles d'e-mail et ensembles d'autorisations referencent les champs sous forme de chaines, et ces references n'apparaissent pas dans toutes les vues de dependances.
3. Verifiez rapports et vues de liste separement. Rien dans votre pipeline ne les connait. Quelqu'un doit regarder.
4. Exportez d'abord les donnees. Un CSV de la colonne avec les identifiants d'enregistrement. Dix minutes, et c'est le seul vrai filet.
5. Lancez les tests locaux. Pour les classes et declencheurs Apex, la recommandation de Salesforce est d'executer tous les tests locaux: c'est ainsi qu'on trouve le code referencant encore l'element supprime.
6. Verifiez l'absence de page Lightning active. Un composant associe a une page Lightning active ne peut pas etre supprime. Desactivez d'abord la substitution d'action dans Lightning App Builder.
7. Validez contre la production. Un deploiement checkOnly, ou --dry-run depuis la CLI, valide et execute les tests sans rien enregistrer.

Comment etaler une suppression sur deux versions?

Le motif sur n'est pas un meilleur manifeste. C'est de scinder la suppression en deux versions.

1. Version N, deprecation. Retirez toutes les references: mises en page, formules, flows, Apex, ensembles d'autorisations, rapports. Marquez le champ comme deprecie dans sa description pour la personne suivante. Cessez d'y ecrire. Ne deployez rien de destructif.
2. Laissez reposer. Laissez passer un cycle de reporting. C'est la que remonte le rapport dont personne n'avait parle, et il remonte comme une question, pas comme un incident.
3. Version N+1, suppression. Exportez les donnees, puis deployez le manifeste destructiveChanges seul, sans rien d'autre.

Livrer une suppression seule compte. Melangee a vingt autres changements, en cas de probleme vous n'isolez pas vite la cause, et le rollback emporte les bons changements.

La meme discipline vaut pour les renommages, que Git enregistre comme une suppression plus un ajout. Traitez chaque renommage comme une deprecation sur deux versions, sauf si vous pouvez prouver que rien ne reference l'ancien nom. D'autres playbooks de livraison sont dans notre bibliotheque SF Guides.

FAQ

Puis-je utiliser un joker dans destructiveChanges.xml?

Non. Les jokers ne sont pas pris en charge. Chaque composant a supprimer doit etre nomme explicitement.

Ai-je encore besoin d'un package.xml si je ne fais que supprimer?

Oui. Il doit se trouver dans le meme repertoire, porter la version d'API et ne lister aucun composant.

Puis-je recuperer un champ supprime par un deploiement?

Il va a la corbeille sauf si purgeOnDelete etait actif, et les champs de recapitulation contournent la corbeille dans tous les cas. Considerez l'export de donnees comme le vrai plan de reprise.

Pourquoi mon deploiement destructif a-t-il reussi sans rien supprimer?

Les tentatives de suppression se poursuivent quand un composant liste est absent de la cible: un mauvais nom d'API donne donc un deploiement vert et aucun changement. Comparez la cible avant et apres.

Quand supprimer avant le deploiement plutot qu'apres?

Quand ancien et nouveau composants entrent en conflit: reutilisation d'un nom d'API, recreation d'un champ avec un autre type, ou retrait d'une regle qui bloquerait le reste du deploiement.