Pre-warmed scratch org pooling: het verborgen plafond op ISV-releasesnelheid

Kort antwoord: een pre-warmed scratch org pool is een set scratch orgs die vooraf is aangemaakt en volledig ingericht, zodat een build of een developer een klaarstaande omgeving ophaalt in plaats van erop te wachten. Voor ISV-teams telt dit zwaarder dan voor org-to-org-teams, omdat elke packagevalidatie eerst een org moet aanmaken en een hele afhankelijkheidsketen moet installeren voordat er ook maar een test draait. Pooling haalt die kosten van het kritieke pad af.

Niemand zet "aanmaaktijd van scratch orgs" op een roadmapslide. Toch bepaalt het het plafond van hoe vaak een ISV een package kan valideren, en de meeste teams zien het niet omdat het wachten verdeeld is over elke pull request in plaats van als een post zichtbaar te zijn.

Wat is pre-warmed scratch org pooling?

Een pool is een achtergrondproces dat N scratch orgs klaar en levend houdt, elk al voorzien van wat je build nodig heeft: de juiste edition en features, de dependency-packages geinstalleerd, seed data geladen, permission sets toegewezen. Vraagt een pipeline of een developer om een omgeving, dan geeft de pool er een af en begint stilletjes aan een vervanger.

De definitie is saai. Het gevolg niet: de tijd tot een bruikbare org zakt naar de tijd om er een uit te checken, en die varieert niet langer met hoe complex je packageboom vorig kwartaal is geworden.

Waarom begrenst aanmaaktijd de releasesnelheid van een ISV?

Loop na wat een enkele packagevalidatie echt doet:

1. De scratch org aanmaken en wachten tot Salesforce hem levert.
2. De afhankelijkheidsketen installeren, managed package voor managed package, op volgorde.
3. Het te testen package installeren of deployen.
4. Seed data laden, permission sets toewijzen, setup-Apex draaien.
5. De tests draaien. Alleen deze stap levert informatie op.

Stap 1 tot en met 4 is wachttijd. Ze geven elke run hetzelfde resultaat, en bij een ISV met een echte dependency-graph domineren ze meestal het totaal. Dat is het stille plafond: naarmate de packageboom groeit wordt feedback trager terwijl de testsuite niet veranderd is, dus valideren teams minder vaak, bundelen ze meer wijzigingen per validatie en vinden ze conflicten later. Niemand besluit om te vertragen. Het gebeurt gewoon.

De rekening landt precies waar ISV's het voelen: pull request checks, nachtelijke regressie over meerdere editions, en de pre-releaserun tegen elke versie die je nog ondersteunt in subscriber orgs.

Wat verandert een warme pool concreet?

• Feedbacktijd volgt niet langer de diepte van je dependencies. Een vijfde dependency kost niet nog eens minuten per PR.
• Parallel testen wordt betaalbaar. Drie editions tegelijk testen is drie orgs uitchecken, geen drie koude builds.
• Fouten worden eerlijk. Als provisioning van het kritieke pad af is, is een rode build veel vaker jouw code dan een instabiele installatiestap.
• Reviewers krijgen een org, geen diff. Een reviewer een levende omgeving geven is geen gunst meer maar de standaard.

Hoeveel orgs kan een ISV eigenlijk poolen?

Hier ontmoet het plan de allocatie. Salesforce documenteert de limieten voor partners: een actieve Partner Business Org krijgt 150 actieve scratch orgs en 300 per dag, een trial-PBO 20 actieve en 40 per dag (zie de allocatiedocumentatie voor partners). Daar volgen twee dingen uit.

Ten eerste is de dagelijkse ruimte ongeveer het dubbele van de actieve, wat Salesforce laat weten dat verloop verwacht wordt en hamsteren niet. Ten tweede is een pool niet gratis: elke org die warm staat is een actieve org die je elders niet kunt gebruiken. Dimensioneer op je piekvraag plus een kleine buffer, niet op je headcount.

Is een scratch org snapshot hetzelfde als een pool?

Nee, en dat verschil is het waard om precies te zijn, want ze lossen aangrenzende problemen op. Een snapshot is een kopie van een scratch org op een moment in de tijd, inclusief geinstalleerde packages, features, licenties, metadata en data, en je maakt er nieuwe orgs uit. Dat haalt het inrichtwerk weg. Het haalt het wachten op provisioning niet weg.

Snapshots hebben ook eigen randvoorwaarden: ze verlopen na 90 dagen, de allocatie loopt van 3 op Developer Edition tot 100 op Unlimited en Performance, en connected apps, external credentials en named credentials worden niet meegekopieerd. Voor ISV's betekent dat: een snapshot veroudert zodra een dependencyversie verschuift.

De twee combineren juist goed. Bouw de pool uit een snapshot en je slaat zowel het inrichtwerk als het wachten over.

Hoe draai je een pool zonder je allocatie op te branden?

1. Scheid pools op doel. Een kortlevende CI-pool en een langerlevende developerpool hebben andere expiry en andere inhoud.
2. Pin dependencyversies in de pooldefinitie. Een pool op "latest" is een pool die stilletjes wegdrijft van wat je uitlevert.
3. Vul continu aan, niet een keer per nacht. Bijvullen zodra orgs worden opgehaald, zodat de pool halverwege de ochtend niet leeg is.
4. Laat agressief verlopen. Oude warme orgs zijn verouderde orgs die actieve allocatie gijzelen.
5. Monitor de diepte, niet alleen het succes. Het getal dat een slechte week voorspelt is hoe vaak de pool nul raakte.

Waar krijg je pooling?

Je kunt het zelf bouwen met de open source sfp-tooling die het flxbl-project documenteert, zoals de vroege gebruikers het deden. In Serpent zijn scratch orgs op elk plan beschikbaar en komt pre-warmed pooling mee op Scale en Enterprise, naast de 1GP- en 2GP-workflows, cross-package dependency resolution en AppExchange-releasegates die packageteams op hetzelfde platform nodig hebben. Welke route je ook kiest: eis dat de pool je dependency-graph begrijpt. Een pool van lege orgs lost de kleinste helft van het probleem op.

Ben je een ISV waarvan de PR-checks stilletjes van vier naar twintig minuten zijn gekropen, kijk dan waar die twintig minuten aan opgaan voordat je ook maar een test optimaliseert. Serpent is precies voor dat team gebouwd.

FAQ

Hoe groot moet een scratch org pool zijn?

Begin bij je piekvraag plus twee. Volg hoe vaak de pool nul raakt en breid pas uit als dat gebeurt, want elke warme org verbruikt je actieve scratch org allocatie.

Tellen pooled scratch orgs mee voor de Salesforce-limieten?

Ja. Een scratch org is actief vanaf het aanmaken tot hij verloopt of wordt verwijderd, dus een warme pool verbruikt allocatie zolang hij stilstaat.

Snapshots of pooling?

Allebei, als het kan. Snapshots schrappen het inrichtwerk binnen een org; pooling schrapt het wachten op de org zelf. Je pool uit een snapshot bouwen geeft je beide.

Helpt pooling ook org-to-org-teams?

Minder. Zonder afhankelijkheidsketen om te installeren is koud aanmaken veel goedkoper, dus de terugverdientijd is korter dan bij packageteams.