Automatiser les déploiements Salesforce avec des scratch orgs

Réponse courte : automatiser les déploiements Salesforce avec des scratch orgs, c'est faire créer par votre job de CI une org jetable à partir d'un fichier de définition, y installer vos dépendances, déployer vos sources, lancer les tests, puis supprimer l'org. Les briques sont un Dev Hub, un fichier de définition de scratch org, sfdx-project.json et quatre ou cinq commandes CLI. Ce qui décide de la survie du dispositif en équipe réelle n'est pas le script, ce sont les limites des scratch orgs.

Quand utiliser une scratch org plutôt qu'une sandbox ?

Une scratch org est une org jetable, pilotée par la source et créée depuis un fichier de configuration : sa forme vit dans votre dépôt et non dans la mémoire de quelqu'un. Utilisez-la quand l'environnement doit être défini par du code et jeté ensuite : développement par fonctionnalité, validation par pull request, construction et test d'installation de packages.

Restez sur une sandbox s'il vous faut un volume de données proche de la production ou un endpoint d'intégration durable. Les scratch orgs plafonnent autour de 200 Mo d'enregistrements et 50 Mo de fichiers, et elles expirent (Salesforce Ben).

Que met-on dans le fichier de définition ?

Le fichier de définition est le plan. Seul edition est obligatoire, avec des valeurs comme Developer, Enterprise, Group, Professional et leurs équivalents Partner. Les clés à connaître (Salesforce DX Developer Guide) :

• features : un tableau de fonctionnalités additionnelles à activer.
• settings : préférences d'org et de fonctionnalités au format Metadata API. Certaines capacités, dont Experience Cloud, exigent une feature et un setting correspondant.
• objectSettings : modèles de partage et types d'enregistrement par défaut, objet par objet.
• release : fixe l'org sur une version Salesforce au lieu de suivre le Dev Hub.
• sourceOrg et snapshot : partir d'une org shape ou d'une copie datée plutôt que d'une édition vierge.
• hasSampleData, orgName, adminEmail, country, language : les détails qui rendent une panne reproductible.

Gardez un fichier de définition par usage. Une définition de CI doit être minimale et rapide ; une définition de démo peut embarquer des données d'exemple. Mélanger les deux, c'est transformer un contrôle de pull request en trois minutes d'attente.

Comment vos sources arrivent-elles dans l'org ?

Les scratch orgs utilisent le source tracking : vous déployez votre projet vers l'org et récupérez les changements en sens inverse. Avec la CLI actuelle, c'est sf project deploy start pour pousser et sf project retrieve start pour récupérer ; les anciennes commandes force:source:push et force:source:deploy y ont été regroupées (Salesforce DX Developer Guide).

Les dépendances viennent de sfdx-project.json. Le job de CI y lit le namespace et les dépendances de packages, puis les installe avant vos propres sources. C'est pourquoi un build qui passe en local et échoue en CI est presque toujours un problème d'ordre des dépendances, pas de métadonnées.

Que fait concrètement le job de CI ?

1. S'authentifier au Dev Hub avec une clé JWT stockée en secret de CI. Jamais de connexion interactive.
2. Créer l'org : sf org create scratch --definition-file config/project-scratch-def.json --alias ci, avec la durée utile la plus courte.
3. Installer les dépendances de packages déclarées dans sfdx-project.json.
4. Déployer vos sources avec sf project deploy start.
5. Injecter le minimum de données nécessaire aux tests, depuis un fichier versionné du dépôt.
6. Lancer les tests Apex et publier les résultats, en faisant échouer le job sur la couverture ou les assertions.
7. Supprimer l'org dans une étape qui s'exécute toujours, y compris quand les étapes précédentes ont échoué.

L'étape sept est celle que les équipes oublient, et celle qui casse silencieusement le pipeline une semaine plus tard.

Pourquoi ces pipelines cassent-ils dès que l'équipe s'active ?

C'est là que la plupart des guides s'arrêtent, et là que les pipelines réels cèdent. Quatre points à anticiper :

• Limites d'allocation. Les Dev Hubs en édition Developer, Enterprise, Performance et Unlimited autorisent chacun 6 scratch orgs par jour et 3 actives simultanément (Salesforce Ben). Dix pull requests par jour avec une org par PR n'entrent pas là-dedans. Vérifiez vos limites avec sf org list limits avant de concevoir le workflow, pas après.
• Expiration. La durée par défaut est de 7 jours, le maximum de 30. Tout environnement soumis à une relecture humaine doit être créé avec une durée explicite, sinon il disparaît en pleine revue.
• Latence de création. Une scratch org froide plus l'installation des dépendances, c'est du temps mort à chaque exécution. Les pools préchauffés et les snapshots existent précisément pour sortir ce coût du chemin critique.
• Données. Une scratch org démarre vide. Alimentez-la depuis un fichier versionné plutôt qu'un export manuel, sinon vos tests passent pour des raisons que personne ne sait reproduire.

Si vous touchez le plafond, les options honnêtes sont : réserver l'org par PR aux changements qui touchent les métadonnées packagées, utiliser une org partagée durable pour le reste, ou exploiter un pool. Serpent fournit des scratch orgs sur tous les plans et ajoute le pooling préchauffé sur Scale et Enterprise, pour que l'org attende déjà quand le pipeline la demande.

FAQ

Faut-il un Dev Hub pour utiliser les scratch orgs ?

Oui. Les scratch orgs sont créées contre un Dev Hub activé, qui compte aussi vos allocations quotidiennes et actives.

Un ISV peut-il construire ses packages ainsi ?

Oui, et c'est la voie standard. Construisez et installez la version de package dans une scratch org neuve à chaque exécution, pour que les échecs d'installation apparaissent en CI et non chez un abonné.

Quelle différence entre une org shape et un snapshot ?

Une shape copie la configuration d'une org existante dans une nouvelle org vide. Un snapshot copie une scratch org à un instant donné, avec ce qui y était déjà déployé.

Chaque pull request doit-elle avoir sa scratch org ?

Seulement si votre allocation le permet. Avec 3 orgs actives, un dépôt chargé a besoin d'un pool ou d'une org de validation partagée.

D'autres guides pas à pas sur le DevOps Salesforce se trouvent dans notre bibliothèque SF Guides.