Stratégies de rollback pour les déploiements Salesforce ratés

Réponse courte : Salesforce n'a pas de bouton annuler. Un déploiement de production qui échoue se défait tout seul, car rollbackOnError doit être à true en production, mais un déploiement qui réussit et se révèle mauvais, c'est à vous de le défaire. Vos options réalistes sont un déploiement inverse depuis un instantané pris avant la release, une suppression ciblée, ou un correctif en avant. Celle dont vous disposerez se décide avant le déploiement, pas après.

Pourquoi Salesforce n'a-t-il pas de bouton de rollback ?

Salesforce écrit les métadonnées directement dans l'org. Il n'y a pas de journal de transactions à rembobiner ni de version précédente de l'org vers laquelle basculer. L'API Metadata offre un seul filet de sécurité, et il ne couvre que l'échec franc : pour un déploiement en production, rollbackOnError doit être à true, donc si un composant échoue, tout le paquet est abandonné et l'org reste intacte (guide développeur de l'API Metadata Salesforce).

Ce filet ne sert à rien dans le cas que les équipes redoutent vraiment. Une release qui se déploie proprement, passe tous les tests, puis casse un processus métier à neuf heures du matin n'est pas un échec de déploiement au sens de Salesforce. La défaire suppose de construire un nouveau déploiement, et vous ne pouvez le construire qu'à partir de ce que vous avez capturé avant.

Que peut-on vraiment annuler, et que ne peut-on pas ?

C'est par là que tout plan de rollback devrait commencer, et c'est précisément là que la plupart se taisent. Classez votre release en trois catégories avant d'écrire la moindre étape.

• Réversible en redéployant l'ancienne version. Classes et déclencheurs Apex, composants Lightning, flows, mises en page, règles de validation, ensembles d'autorisations et la plupart de la configuration déclarative. Si vous avez la source précédente, vous la remettez.
• Récupérable dans une fenêtre. Un champ personnalisé supprimé arrive dans Deleted Fields du Gestionnaire d'objets et peut être restauré avec ses données pendant 15 jours, ensuite il disparaît. Restaurer le champ ne restaure pas les mises en page dont il a été retiré (repères sur la restauration des champs supprimés).
• Pratiquement irréversible. Valeurs de liste de sélection supprimées, conversions de type de champ qui tronquent les données, enregistrements réécrits par un flow ou un trigger fautif, et champs de récapitulatif supprimés via l'API Metadata, qui contournent totalement la corbeille (documentation Salesforce sur la suppression de composants).

C'est dans cette troisième catégorie que les plans de rollback cassent. Un rollback de métadonnées restaure la configuration, jamais les données. Si votre release a fait tourner une automatisation sur 400 000 enregistrements, redéployer l'Apex de la veille n'y change rien.

Quelles sont les stratégies de rollback réalistes ?

1. Déploiement inverse depuis le contrôle de source

L'option la plus fiable. Si la branche qui a produit la release est dans Git, le commit précédent est votre artefact de rollback. Vous construisez un paquet à partir du dernier commit sain et vous le déployez par-dessus. Cela ne couvre que les composants modifiés ou ajoutés, donc associez-le à la stratégie trois.

2. Restauration depuis un instantané de métadonnées

Capturez l'état de l'org cible juste avant le déploiement, puis servez-vous de cet instantané pour générer le paquet inverse si besoin. Cela couvre le cas où l'org a dérivé par rapport à Git, ce qui est la norme dans la plupart des équipes Salesforce. Les outils de cette catégorie automatisent la capture et le diff : Gearset, AutoRABIT et Blue Canvas documentent tous un rollback basé sur instantané ou restauration, et Serpent propose un rollback en un clic sur toutes les offres, y compris l'offre gratuite. À partir de Scale, Backup & Restore couvre les données.

3. Suppressions explicites pour tout ce que vous avez ajouté

Un déploiement inverse met à jour des composants qui existaient déjà. Il ne retire pas ceux que votre release a créés, donc un nouvel objet ou champ reste en place tant que vous ne le supprimez pas explicitement. Cela passe par un manifeste destructiveChanges.xml, un artefact séparé que vous devez écrire. Utilisez destructiveChangesPre.xml pour supprimer avant les ajouts et destructiveChangesPost.xml pour supprimer après, ce qui dénoue les dépendances comme une classe Apex qui référence encore l'objet à supprimer.

4. Corriger en avant plutôt que revenir en arrière

Souvent le bon choix. Si le défaut tient à une règle de validation ou à une ligne d'Apex, un correctif via le pipeline habituel est plus rapide et plus sûr que d'inverser un paquet de 200 composants. Revenez en arrière quand le périmètre d'impact est inconnu. Corrigez en avant quand il est petit et compris.

Comment annuler un déploiement Salesforce raté, étape par étape ?

1. Arrêtez le pipeline pour qu'aucune release ne s'empile sur celle qui est cassée.
2. Nommez le périmètre d'impact : quels composants, quelles automatisations, quels enregistrements.
3. Choisissez rollback ou correctif en avant, et dites aux parties prenantes ce que vous avez choisi.
4. Construisez le paquet inverse depuis l'instantané ou le dernier commit sain.
5. Ajoutez un manifeste de suppression pour tout ce que la release a créé.
6. Validez le paquet inverse contre la production avant de l'exécuter, pour ne pas transformer un incident en deux.
7. Déployez, puis vérifiez le processus métier plutôt que le statut du déploiement.
8. Réparez les données séparément, depuis une sauvegarde, et seulement une fois les métadonnées stables.

Que faut-il décider avant de déployer ?

Un rollback est une décision de conception prise au moment de la construction. Répondez à ces cinq points avant la mise en production.

• Où est l'instantané de l'org cible pris avant la release, et a-t-il vraiment tourné ?
• Quels composants de cette release tombent dans la catégorie irréversible ?
• Quelque chose nécessite-t-il un manifeste de suppression, et est-il écrit et relu ?
• Existe-t-il une sauvegarde de données assez proche de la release pour être utile ?
• Qui décide du rollback, et quel signal le déclenche ?

Valider avant de déployer reste la prévention la moins chère. Une validation avec tests reste utilisable 10 jours et permet un quick deploy du même paquet sans rejouer les tests Apex, donc découvrir une erreur de compilation en production n'a plus d'excuse. D'autres guides de release sont dans notre bibliothèque SF Guides.

FAQ

Salesforce annule-t-il automatiquement un déploiement raté ?

Oui, mais seulement ceux qui échouent. Les déploiements en production exigent rollbackOnError à true, donc un composant en échec annule tout le paquet. Un déploiement réussi n'est jamais défait pour vous.

Peut-on annuler un change set ?

Pas nativement. Il n'y a pas de bouton d'inversion, donc les équipes construisent un second change set qui redéploie la version précédente, ce qui suppose que quelqu'un l'ait capturée avant.

Un rollback de métadonnées restaure-t-il mes données ?

Non. Métadonnées et données sont deux problèmes distincts. Revenir sur la configuration n'annule pas les enregistrements créés, modifiés ou supprimés par une automatisation, il faut une sauvegarde et un plan de restauration.

Combien de temps pour récupérer un champ personnalisé supprimé ?

15 jours. Le champ reste dans Deleted Fields du Gestionnaire d'objets et peut être restauré avec ses données dans cette fenêtre, même s'il faut parfois le remettre à la main sur les mises en page.