Rédiger un runbook de refresh de sandbox que votre équipe suivra

Un runbook de refresh de sandbox que votre équipe suivra est court, vit à côté de votre code et attribue à chaque étape un responsable, une estimation de durée et un contrôle qui prouve qu'elle est terminée. La plupart des documents de refresh échouent parce que ce sont de longues pages wiki dont personne n'est responsable. Rédigez le vôtre comme une checklist en quatre phases, automatisez les étapes que l'on saute et répétez-le une fois avant de vous y fier.

Qu'est-ce qu'un runbook de refresh de sandbox ?

Un runbook de refresh de sandbox est la procédure pas à pas que votre équipe exécute chaque fois qu'une sandbox Salesforce est rafraîchie depuis la production : ce qu'il faut sauvegarder avant, ce qu'il faut restaurer après, qui fait chaque étape et comment savoir que cela a fonctionné. Ce n'est pas votre stratégie de sandbox, qui décide quelles sandboxes existent et pourquoi. Le runbook est la partie que l'on exécute le matin du refresh.

Pourquoi les équipes ignorent-elles les runbooks de refresh ?

• Pas de responsable par étape. Quand c'est l'équipe qui restaure les intégrations, personne ne le fait.
• Pas de définition de terminé. Reconfigurer les intégrations ne se vérifie pas. Un callout de test via le named credential renvoie 200, si.
• Il est au mauvais endroit. Une page wiki s'éloigne de l'org. Un fichier Markdown dans le dépôt est relu quand l'org change.
• Trop d'étapes manuelles. Chaque étape manuelle est une étape que quelqu'un sautera sous la pression.

À quelle fréquence peut-on rafraîchir chaque type de sandbox ?

Salesforce plafonne votre rythme, alors placez ces limites en tête du runbook. Selon le guide des sandboxes de Salesforce Ben :

• Developer et Developer Pro : une fois par jour, métadonnées uniquement.
• Partial Copy : tous les cinq jours, métadonnées et une partie de vos données.
• Full : tous les 29 jours, toutes les métadonnées et données de production.

Un refresh Full raté peut vous coûter un mois, c'est donc ce runbook qui mérite le plus de rigueur.

Que mettre dans chaque phase du runbook ?

Rédigez chaque étape au même format : étape | responsable | automatisée ? | minutes | terminée quand. Puis regroupez les étapes en quatre phases.

1. Avant le refresh

• Annoncez le créneau aux développeurs, à la QA et aux testeurs métier, et obtenez un accusé de réception.
• Committez ou déployez chaque changement en cours dans le contrôle de version. Un refresh écrase la sandbox, et tout ce qui n'est pas dans Git est perdu.
• Exportez la configuration stockée sous forme de données, comme les enregistrements de paramètres que certains packages AppExchange conservent hors métadonnées.
• Listez les endpoints d'intégration, named credentials et connected apps qu'il faudra rediriger.

2. Pendant le refresh

• Vérifiez que la production est stable et pas en pleine release.
• Indiquez votre classe Apex post-copie au lancement du refresh, pour que l'automatisation s'exécute sans que personne n'ait à y penser.
• Notez l'heure de début et qui a lancé le refresh.

3. Après le refresh

• Laissez la délivrabilité des e-mails sur System email only, le réglage par défaut des sandboxes nouvelles et rafraîchies selon Apex Hours, jusqu'à ce que les données soient masquées.
• Retirez le suffixe .invalid uniquement pour les utilisateurs qui ont besoin d'e-mails en sandbox. Salesforce l'ajoute aux adresses e-mail des utilisateurs à chaque refresh ou clonage, comme l'explique son article d'aide.
• Masquez ou supprimez les données personnelles avant d'élargir les accès.
• Redirigez les intégrations vers leurs endpoints de sandbox et réauthentifiez-les.
• Redéployez depuis le contrôle de version le travail en avance sur la production, puis rechargez les données de test.

4. Valider et transmettre

• Faites un smoke test : connectez-vous en tant que testeur, exécutez un flow clé, faites un callout de test.
• Lancez vos tests Apex, ou au moins le sous-ensemble qui couvre vos intégrations.
• Annoncez que la sandbox est prête, avec les problèmes connus, et corrigez dans le runbook lui-même ce qui a cassé.

Quelles étapes de refresh automatiser en premier ?

Automatisez les étapes fréquentes, sujettes aux erreurs et rébarbatives. L'interface SandboxPostCopy de Salesforce permet d'écrire une classe Apex qui s'exécute automatiquement à la création de la sandbox, et les bonnes pratiques de refresh de Salto citent le masquage des adresses e-mail et la mise à jour des custom settings et des custom metadata comme usages typiques. De bons premiers candidats :

1. Masquer les données personnelles des contacts et des leads.
2. Remettre les custom settings et la configuration des endpoints aux valeurs de sandbox.
3. Rétablir l'e-mail pour le petit groupe d'utilisateurs qui en a besoin.
4. Recharger les données de test de base. Notre guide pour alimenter une sandbox Salesforce avec des données réalistes présente les options.

Rendez la classe idempotente et journalisez ce qu'elle modifie, pour qu'une exécution ratée puisse être relancée sans risque.

Comment le runbook s'intègre-t-il à votre pipeline de release ?

Un refresh remet une sandbox à l'état de la production, donc tout ce qui se trouve entre cette sandbox et la production disparaît si votre pipeline ne le remet pas en place. Deux habitudes évitent cette perte. D'abord, faites de Git la source de vérité, pour que le travail en cours soit redéployé et non reconstruit. Ensuite, mettez en place la back-promotion dans votre pipeline DevOps Salesforce, pour que les correctifs de production redescendent vers les environnements inférieurs entre deux refresh. Après le refresh, lancez les mêmes contrôles qu'à chaque pull request. Notre guide sur l'automatisation des tests Salesforce en CI distingue ce qu'il faut lancer à chaque pull request de ce qu'il faut lancer la nuit.

Si redéployer après chaque refresh vous prend encore un après-midi à la main, une plateforme DevOps s'en charge en grande partie. L'offre gratuite Essentials de Serpent inclut les déploiements delta et le rollback en un clic ; comparez les offres sur la page tarifs de Serpent.

Comment faire pour que l'équipe le suive vraiment ?

• Limitez chaque phase à un écran et renvoyez vers le détail.
• Stockez le runbook dans le dépôt et relisez ses modifications comme du code.
• Répétez-le sur une sandbox Developer, rafraîchissable chaque jour, avant le prochain refresh Full.
• Mettez-le à jour le jour même où quelque chose casse. Un runbook faux une fois est ignoré pour toujours.
• Désignez un responsable suppléant pour chaque étape.

Pour d'autres guides pratiques comme celui-ci, parcourez la bibliothèque SF Guides.

FAQ

Quelle longueur pour un runbook de refresh de sandbox ?

Assez court pour tenir sur un écran par phase. Gardez le runbook comme checklist et placez le détail dans des documents liés.

À quoi sert SandboxPostCopy ?

C'est une interface Apex pour une classe qui s'exécute automatiquement à la création d'une sandbox, généralement pour masquer des données et réinitialiser des paramètres.

Pourquoi les e-mails des utilisateurs se terminent-ils par .invalid après un refresh ?

Salesforce ajoute .invalid pour que les utilisateurs de production ne reçoivent pas d'e-mails de la sandbox. Retirez-le seulement pour ceux qui en ont besoin.

À quelle fréquence peut-on rafraîchir une sandbox Full ?

Une fois tous les 29 jours. Les sandboxes Partial Copy se rafraîchissent tous les cinq jours et les sandboxes Developer chaque jour.