Strategies de rollback pour les deploiements Salesforce rates

Reponse courte : Salesforce n'a pas de bouton annuler. Un deploiement de production qui echoue se defait tout seul, car rollbackOnError doit etre a true en production, mais un deploiement qui reussit et se revele mauvais, c'est a vous de le defaire. Vos options realistes sont un deploiement inverse depuis un instantane pris avant la release, une suppression ciblee, ou un correctif en avant. Celle dont vous disposerez se decide avant le deploiement, pas apres.

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

Salesforce ecrit les metadonnees directement dans l'org. Il n'y a pas de journal de transactions a rembobiner ni de version precedente de l'org vers laquelle basculer. L'API Metadata offre un seul filet de securite, et il ne couvre que l'echec franc : pour un deploiement en production, rollbackOnError doit etre a true, donc si un composant echoue, tout le paquet est abandonne et l'org reste intacte (guide developpeur de l'API Metadata Salesforce).

Ce filet ne sert a rien dans le cas que les equipes redoutent vraiment. Une release qui se deploie proprement, passe tous les tests, puis casse un processus metier a neuf heures du matin n'est pas un echec de deploiement au sens de Salesforce. La defaire suppose de construire un nouveau deploiement, et vous ne pouvez le construire qu'a partir de ce que vous avez capture avant.

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

C'est par la que tout plan de rollback devrait commencer, et c'est precisement la que la plupart se taisent. Classez votre release en trois categories avant d'ecrire la moindre etape.

• Reversible en redeployant l'ancienne version. Classes et declencheurs Apex, composants Lightning, flows, mises en page, regles de validation, ensembles d'autorisations et la plupart de la configuration declarative. Si vous avez la source precedente, vous la remettez.
• Recuperable dans une fenetre. Un champ personnalise supprime arrive dans Deleted Fields du Gestionnaire d'objets et peut etre restaure avec ses donnees pendant 15 jours, ensuite il disparait. Restaurer le champ ne restaure pas les mises en page dont il a ete retire (reperes sur la restauration des champs supprimes).
• Pratiquement irreversible. Valeurs de liste de selection supprimees, conversions de type de champ qui tronquent les donnees, enregistrements reecrits par un flow ou un trigger fautif, et champs de recapitulatif supprimes via l'API Metadata, qui contournent totalement la corbeille (documentation Salesforce sur la suppression de composants).

C'est dans cette troisieme categorie que les plans de rollback cassent. Un rollback de metadonnees restaure la configuration, jamais les donnees. Si votre release a fait tourner une automatisation sur 400 000 enregistrements, redeployer l'Apex de la veille n'y change rien.

Quelles sont les strategies de rollback realistes ?

1. Deploiement inverse depuis le controle de source

L'option la plus fiable. Si la branche qui a produit la release est dans Git, le commit precedent est votre artefact de rollback. Vous construisez un paquet a partir du dernier commit sain et vous le deployez par-dessus. Cela ne couvre que les composants modifies ou ajoutes, donc associez-le a la strategie trois.

2. Restauration depuis un instantane de metadonnees

Capturez l'etat de l'org cible juste avant le deploiement, puis servez-vous de cet instantane pour generer le paquet inverse si besoin. Cela couvre le cas ou l'org a derive par rapport a Git, ce qui est la norme dans la plupart des equipes Salesforce. Les outils de cette categorie automatisent la capture et le diff : Gearset, AutoRABIT et Blue Canvas documentent tous un rollback base sur instantane ou restauration, et Serpent propose un rollback en un clic sur toutes les offres, y compris l'offre gratuite.

3. Suppressions explicites pour tout ce que vous avez ajoute

Un deploiement inverse met a jour des composants qui existaient deja. Il ne retire pas ceux que votre release a crees, 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 separe que vous devez ecrire. Utilisez destructiveChangesPre.xml pour supprimer avant les ajouts et destructiveChangesPost.xml pour supprimer apres, ce qui denoue les dependances comme une classe Apex qui reference encore l'objet a supprimer.

4. Corriger en avant plutot que revenir en arriere

Souvent le bon choix. Si le defaut tient a une regle de validation ou a une ligne d'Apex, un correctif via le pipeline habituel est plus rapide et plus sur que d'inverser un paquet de 200 composants. Revenez en arriere quand le perimetre d'impact est inconnu. Corrigez en avant quand il est petit et compris.

Comment annuler un deploiement Salesforce rate, etape par etape ?

1. Arretez le pipeline pour qu'aucune release ne s'empile sur celle qui est cassee.
2. Nommez le perimetre 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'instantane ou le dernier commit sain.
5. Ajoutez un manifeste de suppression pour tout ce que la release a cree.
6. Validez le paquet inverse contre la production avant de l'executer, pour ne pas transformer un incident en deux.
7. Deployez, puis verifiez le processus metier plutot que le statut du deploiement.
8. Reparez les donnees separement, depuis une sauvegarde, et seulement une fois les metadonnees stables.

Que faut-il decider avant de deployer ?

Un rollback est une decision de conception prise au moment de la construction. Repondez a ces cinq points avant la mise en production.

• Ou est l'instantane de l'org cible pris avant la release, et a-t-il vraiment tourne ?
• Quels composants de cette release tombent dans la categorie irreversible ?
• Quelque chose necessite-t-il un manifeste de suppression, et est-il ecrit et relu ?
• Existe-t-il une sauvegarde de donnees assez proche de la release pour etre utile ?
• Qui decide du rollback, et quel signal le declenche ?

Valider avant de deployer reste la prevention la moins chere. Une validation avec tests reste utilisable 10 jours et permet un quick deploy du meme paquet sans rejouer les tests Apex, donc decouvrir une erreur de compilation en production n'a plus d'excuse. D'autres guides de release sont dans notre bibliotheque SF Guides.

FAQ

Salesforce annule-t-il automatiquement un deploiement rate ?

Oui, mais seulement ceux qui echouent. Les deploiements en production exigent rollbackOnError a true, donc un composant en echec annule tout le paquet. Un deploiement reussi n'est jamais defait pour vous.

Peut-on annuler un change set ?

Pas nativement. Il n'y a pas de bouton d'inversion, donc les equipes construisent un second change set qui redeploie la version precedente, ce qui suppose que quelqu'un l'ait capturee avant.

Un rollback de metadonnees restaure-t-il mes donnees ?

Non. Metadonnees et donnees sont deux problemes distincts. Revenir sur la configuration n'annule pas les enregistrements crees, modifies ou supprimes par une automatisation, il faut une sauvegarde et un plan de restauration.

Combien de temps pour recuperer un champ personnalise supprime ?

15 jours. Le champ reste dans Deleted Fields du Gestionnaire d'objets et peut etre restaure avec ses donnees dans cette fenetre, meme s'il faut parfois le remettre a la main sur les mises en page.