Pooling de scratch orgs prechauffees : le plafond invisible des ISV

Reponse courte : un pool de scratch orgs prechauffees est un ensemble d'orgs creees et entierement provisionnees a l'avance, pour qu'un build ou un developpeur recupere un environnement pret plutot que d'attendre. Pour les equipes ISV, cela compte plus que pour les equipes org-a-org, car chaque validation de package doit creer une org et installer toute une chaine de dependances avant le moindre test. Le pooling sort ce cout du chemin critique.

Personne ne met "temps de creation d'une scratch org" sur une slide de roadmap. C'est pourtant ce qui plafonne la frequence a laquelle un ISV peut valider un package, et la plupart des equipes ne le voient pas parce que l'attente est diluee dans chaque pull request au lieu d'apparaitre comme une ligne de cout.

Qu'est-ce que le pooling de scratch orgs prechauffees ?

Un pool est un processus d'arriere-plan qui maintient N scratch orgs vivantes et pretes, chacune portant deja ce dont votre build a besoin : la bonne edition et les bonnes fonctionnalites, les packages de dependance installes, les donnees de test chargees, les permission sets attribues. Quand un pipeline ou un developpeur demande un environnement, le pool en cede un et commence discretement a en fabriquer un autre.

La definition est ennuyeuse. La consequence ne l'est pas : le delai jusqu'a une org utilisable tombe au temps d'un checkout, et il cesse de varier avec la complexite prise par votre arbre de packages.

Pourquoi le temps de creation plafonne-t-il la velocite des ISV ?

Regardez ce que fait reellement une seule validation de package :

1. Creer la scratch org et attendre que Salesforce la provisionne.
2. Installer la chaine de dependances, un package gere a la fois, dans l'ordre.
3. Installer ou deployer le package a tester.
4. Charger les donnees, attribuer les permission sets, executer l'Apex de configuration.
5. Lancer les tests. Seule cette etape produit de l'information.

Les etapes 1 a 4 sont du temps d'attente. Elles rendent le meme resultat a chaque execution et, chez un ISV avec un vrai graphe de dependances, elles dominent generalement le total. Voila le plafond silencieux : quand l'arbre de packages grossit, le retour ralentit alors que la suite de tests n'a pas bouge, alors les equipes valident moins souvent, regroupent plus de changements par validation et decouvrent les conflits plus tard. Personne ne decide de ralentir. Cela arrive, c'est tout.

Le cout tombe exactement la ou les ISV le sentent : les controles de pull request, la regression nocturne sur plusieurs editions, et la campagne d'avant-livraison contre chaque version encore supportee chez les abonnes.

Que change concretement un pool chaud ?

• Le temps de retour cesse de suivre la profondeur des dependances. Une cinquieme dependance n'ajoute plus des minutes a chaque PR.
• Le parallelisme devient abordable. Tester trois editions en meme temps, c'est trois checkouts, pas trois builds a froid.
• Les echecs redeviennent honnetes. Quand le provisioning sort du chemin critique, un build rouge vient bien plus souvent de votre code que d'une installation instable.
• Les relecteurs recoivent une org, pas un diff. Donner un environnement vivant a un relecteur n'est plus une faveur mais la norme.

Combien d'orgs un ISV peut-il reellement 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 consequences.

D'abord, l'enveloppe quotidienne vaut environ le double de l'active : Salesforce vous dit que la rotation est attendue et la thesaurisation 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 simultanee plus une petite marge, pas sur vos effectifs.

Un snapshot est-il la meme chose qu'un pool ?

Non, et la nuance merite d'etre precise car les deux resolvent des problemes voisins. Un snapshot est une copie ponctuelle d'une scratch org incluant packages installes, fonctionnalites, licences, metadonnees et donnees, a partir de laquelle vous creez 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 a 100 en Unlimited et Performance, et les connected apps, external credentials et named credentials ne sont pas copies. Pour un ISV, cela signifie qu'un snapshot vieillit des qu'une version de dependance bouge.

Les deux se combinent tres bien. Construisez le pool a partir d'un snapshot et vous supprimez a la fois la configuration et l'attente.

Comment exploiter un pool sans bruler son allocation ?

1. Separez les pools par usage. Un pool CI a duree courte et un pool developpeur a duree longue n'ont ni la meme expiration ni le meme contenu.
2. Figez les versions de dependances dans la definition du pool. Un pool bati sur "latest" derive silencieusement de ce que vous livrez.
3. Realimentez en continu, pas une fois par nuit. Reconstituez au fil des retraits pour que le pool ne se vide pas en milieu de matinee.
4. Faites expirer sans etat d'ame. Une org chaude ancienne est une org perimee qui retient de l'allocation active.
5. Surveillez la profondeur, pas seulement le succes. Le chiffre qui annonce une mauvaise semaine, c'est le nombre de fois ou le pool est tombe a zero.

Ou trouver du pooling ?

Vous pouvez le construire vous-meme avec l'outillage open source sfp documente 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 prechauffe est inclus sur Scale et Enterprise, aux cotes des workflows 1GP et 2GP, de la resolution des dependances entre packages et des controles de publication AppExchange dont les equipes package ont besoin sur la meme plateforme. Quelle que soit la voie choisie, exigez que le pool comprenne votre graphe de dependances. Un pool d'orgs vides ne resout que la plus petite moitie du probleme.

Si vos controles de PR sont passes discretement de quatre a vingt minutes, regardez a quoi servent ces vingt minutes avant d'optimiser le moindre test. Serpent est construit pour cette equipe-la.

FAQ

Quelle taille donner a un pool de scratch orgs ?

Partez de votre pic de demande simultanee plus deux. Mesurez la frequence a laquelle le pool tombe a zero et n'ajoutez de la capacite 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 creation jusqu'a son expiration ou sa suppression, donc un pool chaud consomme de l'allocation meme au repos.

Snapshots ou pooling ?

Les deux si possible. Le snapshot supprime la configuration a l'interieur d'une org ; le pooling supprime l'attente de l'org elle-meme. Batir le pool depuis un snapshot vous donne les deux.

Le pooling aide-t-il aussi les equipes org-a-org ?

Moins. Sans chaine de dependances a installer, une creation a froid coute bien moins cher, donc le retour est plus faible que pour les equipes package.