Pooling de scratch orgs préchauffées : le plafond invisible des ISV

Réponse courte : un pool de scratch orgs préchauffées est un ensemble d'orgs créées et entièrement provisionnées à l'avance, pour qu'un build ou un développeur récupère un environnement prêt plutôt que d'attendre. Pour les équipes ISV, cela compte plus que pour les équipes org-à-org, car chaque validation de package doit créer une org et installer toute une chaîne de dépendances avant le moindre test. Le pooling sort ce coût du chemin critique.

Personne ne met "temps de création d'une scratch org" sur une slide de roadmap. C'est pourtant ce qui plafonne la fréquence à laquelle un ISV peut valider un package, et la plupart des équipes ne le voient pas parce que l'attente est diluée dans chaque pull request au lieu d'apparaître comme une ligne de coût.

Qu'est-ce que le pooling de scratch orgs préchauffées ?

Un pool est un processus d'arrière-plan qui maintient N scratch orgs vivantes et prêtes, chacune portant déjà ce dont votre build a besoin : la bonne édition et les bonnes fonctionnalités, les packages de dépendance installés, les données de test chargées, les permission sets attribués. Quand un pipeline ou un développeur demande un environnement, le pool en cède un et commence discrètement à en fabriquer un autre.

La définition est ennuyeuse. La conséquence ne l'est pas : le délai jusqu'à une org utilisable tombe au temps d'un checkout, et il cesse de varier avec la complexité prise par votre arbre de packages.

Pourquoi le temps de création plafonne-t-il la vélocité des ISV ?

Regardez ce que fait réellement une seule validation de package :

1. Créer la scratch org et attendre que Salesforce la provisionne.
2. Installer la chaîne de dépendances, un package géré à la fois, dans l'ordre.
3. Installer ou déployer le package à tester.
4. Charger les données, attribuer les permission sets, exécuter l'Apex de configuration.
5. Lancer les tests. Seule cette étape produit de l'information.

Les étapes 1 à 4 sont du temps d'attente. Elles rendent le même résultat à chaque exécution et, chez un ISV avec un vrai graphe de dépendances, elles dominent généralement le total. Voilà le plafond silencieux : quand l'arbre de packages grossit, le retour ralentit alors que la suite de tests n'a pas bougé, alors les équipes valident moins souvent, regroupent plus de changements par validation et découvrent les conflits plus tard. Personne ne décide de ralentir. Cela arrive, c'est tout.

Le coût tombe exactement là où les ISV le sentent : les contrôles de pull request, la régression nocturne sur plusieurs éditions, et la campagne d'avant-livraison contre chaque version encore supportée chez les abonnés.

Que change concrètement un pool chaud ?

• Le temps de retour cesse de suivre la profondeur des dépendances. Une cinquième dépendance n'ajoute plus des minutes à chaque PR.
• Le parallélisme devient abordable. Tester trois éditions en même temps, c'est trois checkouts, pas trois builds à froid.
• Les échecs redeviennent honnêtes. Quand le provisioning sort du chemin critique, un build rouge vient bien plus souvent de votre code que d'une installation instable.
• Les relecteurs reçoivent une org, pas un diff. Donner un environnement vivant à un relecteur n'est plus une faveur mais la norme.

Combien d'orgs un ISV peut-il réellement mettre en pool ?

C'est ici que le plan rencontre l'allocation. Salesforce documente les limites partenaires : une Partner Business Org active dispose de 150 scratch orgs actives et 300 par jour, et une PBO d'essai de 20 actives et 40 par jour (voir la documentation d'allocation partenaires). Deux conséquences.

D'abord, l'enveloppe quotidienne vaut environ le double de l'active : Salesforce vous dit que la rotation est attendue et la thésaurisation non. Ensuite, un pool n'est pas gratuit : chaque org maintenue au chaud est une org active indisponible ailleurs. Dimensionnez sur votre pic de demande simultanée plus une petite marge, pas sur vos effectifs.

Un snapshot est-il la même chose qu'un pool ?

Non, et la nuance mérite d'être précise car les deux résolvent des problèmes voisins. Un snapshot est une copie ponctuelle d'une scratch org incluant packages installés, fonctionnalités, licences, métadonnées et données, à partir de laquelle vous créez de nouvelles orgs. Cela supprime le travail de configuration. Cela ne supprime pas l'attente du provisioning.

Les snapshots ont aussi leurs contraintes : ils expirent au bout de 90 jours, l'allocation va de 3 en Developer Edition à 100 en Unlimited et Performance, et les connected apps, external credentials et named credentials ne sont pas copiés. Pour un ISV, cela signifie qu'un snapshot vieillit dès qu'une version de dépendance bouge.

Les deux se combinent très bien. Construisez le pool à partir d'un snapshot et vous supprimez à la fois la configuration et l'attente.

Comment exploiter un pool sans brûler son allocation ?

1. Séparez les pools par usage. Un pool CI à durée courte et un pool développeur à durée longue n'ont ni la même expiration ni le même contenu.
2. Figez les versions de dépendances dans la définition du pool. Un pool bâti sur "latest" dérive silencieusement de ce que vous livrez.
3. Réalimentez en continu, pas une fois par nuit. Reconstituez au fil des retraits pour que le pool ne se vide pas en milieu de matinée.
4. Faites expirer sans état d'âme. Une org chaude ancienne est une org périmée qui retient de l'allocation active.
5. Surveillez la profondeur, pas seulement le succès. Le chiffre qui annonce une mauvaise semaine, c'est le nombre de fois où le pool est tombé à zéro.

Où trouver du pooling ?

Vous pouvez le construire vous-même avec l'outillage open source sfp documenté par le projet flxbl, comme l'ont fait les premiers adoptants. Dans Serpent, les scratch orgs sont disponibles sur tous les plans et le pooling préchauffé est inclus sur Scale et Enterprise, aux côtés des workflows 1GP et 2GP, de la résolution des dépendances entre packages et des contrôles de publication AppExchange dont les équipes package ont besoin sur la même plateforme. Quelle que soit la voie choisie, exigez que le pool comprenne votre graphe de dépendances. Un pool d'orgs vides ne résout que la plus petite moitié du problème.

Si vos contrôles de PR sont passés discrètement de quatre à vingt minutes, regardez à quoi servent ces vingt minutes avant d'optimiser le moindre test. Serpent est construit pour cette équipe-là.

FAQ

Quelle taille donner à un pool de scratch orgs ?

Partez de votre pic de demande simultanée plus deux. Mesurez la fréquence à laquelle le pool tombe à zéro et n'ajoutez de la capacité que dans ce cas, car chaque org chaude consomme votre allocation active.

Les orgs en pool comptent-elles dans les limites Salesforce ?

Oui. Une scratch org est active de sa création jusqu'à son expiration ou sa suppression, donc un pool chaud consomme de l'allocation même au repos.

Snapshots ou pooling ?

Les deux si possible. Le snapshot supprime la configuration à l'intérieur d'une org ; le pooling supprime l'attente de l'org elle-même. Bâtir le pool depuis un snapshot vous donne les deux.

Le pooling aide-t-il aussi les équipes org-à-org ?

Moins. Sans chaîne de dépendances à installer, une création à froid coûte bien moins cher, donc le retour est plus faible que pour les équipes package.