Destructive Changes
Des déploiements Salesforce qui suppriment des métadonnées, suivis séparément des changements additifs afin que les suppressions restent délibérées.
Définition
Les destructive changes sont des déploiements Salesforce qui suppriment des métadonnées, champs, objets, classes Apex et autres, à l'aide d'un manifest destructiveChanges.xml déployé aux côtés d'un package.xml classique, ou à sa place. Les suppressions ne peuvent pas se produire via un déploiement de métadonnées normal ; Salesforce exige ce manifest séparé précisément pour que les suppressions soient explicites et vérifiables plutôt qu'un effet de bord accidentel d'un déploiement ordinaire. Les déploiements destructifs s'exécutent selon deux modes, pré- (suppression avant le déploiement des nouvelles métadonnées) ou post- (suppression après), et se tromper dans l'ordre peut casser des composants dépendants en plein déploiement. Comme les suppressions ne sont pas facilement réversibles, la plupart des équipes considèrent les destructive changes comme plus risqués que les changements additifs, et certains champs ou enregistrements auxquels des données sont encore rattachées bloqueront la suppression tant que ces données n'ont pas été traitées. La même chose s'applique à un flow deployment : Salesforce empêche de désactiver une version qui a encore des interviews en pause. Notre guide Salesforce DevOps couvre les pratiques de release sûres, y compris la gestion des suppressions.
Comment cela fonctionne dans Serpent
Serpent suit les suppressions de la même manière que tout autre changement, donc une tâche qui supprime un champ ou une classe produit automatiquement un manifest de destructive changes en bonne et due forme, avec l'ordre pré- ou post-déploiement résolu pour vous. Les vérifications de preflight signalent quand une suppression a des composants ou des données dépendants susceptibles de la bloquer, avant que le déploiement ne s'exécute en production, pas après. Et comme chaque release dispose d'un rollback en un clic, un destructive change qui s'avère erroné peut être annulé sans effort de récupération manuel. Voir la gestion des releases dans Serpent pour savoir comment le rollback et les destructive changes fonctionnent ensemble.
Démarrez gratuitement. Sans carte bancaire, sans installation, sans engagement.
Configuration en moins de 15 minutes. Aucune embauche DevOps nécessaire.