Glossaire Salesforce DevOps

Sandbox Seeding

Charger des données d'exemple réalistes ou masquées dans un sandbox ou un scratch org afin que les tests reflètent des conditions réelles.

Définition

Le sandbox seeding est le processus consistant à charger des données de production d'exemple réalistes ou masquées dans un sandbox ou un scratch org afin que le développement et les tests reflètent des conditions réelles, plutôt qu'une org vide ou peu peuplée. Les sandbox Salesforce peuvent copier les données de production selon leur type, les sandbox Developer n'en copient aucune, Partial Copy prend un échantillon, Full copie tout, mais les scratch orgs n'héritent jamais automatiquement de données et démarrent toujours vides.

Le seeding manuel signifie généralement des scripts de data loader, des imports CSV ou des data factories Apex exécutés à la main après chaque rafraîchissement d'org, ce qui est facile à négliger sous la pression des délais et entraîne des bugs qui n'apparaissent qu'une fois que de vrais volumes de données atteignent la production. Les équipes gérant plusieurs orgs via un Environment Hub intègrent souvent le seeding dans leur routine de rafraîchissement standard précisément pour cette raison.

Le seeding doit aussi respecter la confidentialité des données : les données de production utilisées dans des environnements inférieurs doivent généralement être masquées pour répondre au RGPD et exigences similaires, et devraient être intégrées à un plan de déploiement répétable plutôt qu'à un script ponctuel. Voir notre guide DevOps Salesforce pour savoir où la gestion des données s'inscrit dans le tableau DevOps plus large.

En pratique

Comment cela fonctionne dans Serpent

Serpent automatise le seeding de données dans le cadre de la configuration des environnements et des pipelines de release, de sorte que les scratch orgs et les sandbox rafraîchis reviennent peuplés avec les bonnes données d'exemple ou masquées sans exécution manuelle de script. Les étapes de seeding vivent au sein de la même automatisation qui provisionne les orgs et déploie les métadonnées, afin que les environnements restent cohérents à chaque fois, pas seulement quand quelqu'un pense à lancer le loader. Cela comble une lacune courante où les bugs ne surgissent qu'en production parce que les environnements inférieurs ont été testés vides. Voir les automatisations Serpent pour savoir comment le seeding de données s'intègre dans des pipelines no-code.

Serpent alimente un sandbox avec des données d'exemple réalistes pour les tests
Questions fréquentes

Sandbox Seeding, expliqué

Quels types de sandbox Salesforce disposent automatiquement de données de production ?
Les sandbox Full copient toutes les données de production, les sandbox Partial Copy prennent un échantillon, et les sandbox Developer ou Developer Pro n'en copient aucune. Les scratch orgs n'héritent jamais automatiquement de données, quel que soit le type.
Dois-je masquer les données de production avant de les charger dans un sandbox ?
Généralement oui. Les données de production utilisées dans des environnements inférieurs doivent généralement être masquées pour répondre au RGPD et exigences de confidentialité similaires, en particulier pour les champs personnels ou financiers.
Pourquoi des bugs apparaissent-ils en production alors qu'ils n'étaient jamais apparus en test ?
Souvent parce que les environnements inférieurs ont été testés avec peu ou pas de données. Les étapes de seeding manuel sont négligées sous la pression des délais, donc les problèmes liés à de vrais volumes de données n'apparaissent qu'après la mise en production.

Démarrez gratuitement. Sans carte bancaire, sans installation, sans engagement.

Configuration en moins de 15 minutes. Aucun recrutement DevOps nécessaire.

Curieux de livrer plus vite avant de vous lancer ? Parlons-en

Sans engagement.