Vorgewärmtes Scratch-Org-Pooling: der versteckte Deckel für ISV-Releases

Kurze Antwort: Ein vorgewärmter Scratch-Org-Pool ist eine Menge vorab erzeugter und vollständig provisionierter Scratch Orgs, sodass ein Build oder eine Entwicklerin eine fertige Umgebung abholt statt zu warten. Für ISV-Teams zählt das mehr als für Org-zu-Org-Teams, weil jede Paketvalidierung erst eine Org anlegen und eine ganze Abhängigkeitskette installieren muss, bevor ein einziger Test läuft. Pooling nimmt diese Kosten vom kritischen Pfad.

Niemand setzt "Erstellzeit von Scratch Orgs" auf eine Roadmap-Folie. Trotzdem deckelt sie, wie oft ein ISV ein Paket validieren kann, und die meisten Teams sehen es nicht, weil die Wartezeit über jeden Pull Request verteilt ist statt als ein Posten aufzutauchen.

Was ist vorgewärmtes Scratch-Org-Pooling?

Ein Pool ist ein Hintergrundprozess, der N Scratch Orgs bereit hält, jede bereits mit allem ausgestattet, was der Build braucht: passende Edition und Features, installierte Abhängigkeitspakete, geladene Testdaten, zugewiesene Permission Sets. Fragt eine Pipeline oder eine Entwicklerin nach einer Umgebung, gibt der Pool eine heraus und beginnt still mit dem Nachbau.

Die Definition ist langweilig. Die Folge nicht: Die Zeit bis zur nutzbaren Org sinkt auf die Zeit eines Checkouts und hängt nicht mehr davon ab, wie komplex der Paketbaum im letzten Quartal geworden ist.

Warum deckelt die Erstellzeit die Release-Geschwindigkeit von ISVs?

Sehen Sie sich an, was eine einzelne Paketvalidierung wirklich tut:

1. Die Scratch Org anlegen und warten, bis Salesforce sie bereitstellt.
2. Die Abhängigkeitskette installieren, ein Managed Package nach dem anderen, in Reihenfolge.
3. Das zu testende Paket installieren oder deployen.
4. Testdaten laden, Permission Sets zuweisen, Setup-Apex ausführen.
5. Die Tests laufen lassen. Nur dieser Schritt erzeugt Information.

Schritt 1 bis 4 ist Wartezeit. Sie liefern in jedem Lauf dasselbe Ergebnis, und bei einem ISV mit echtem Abhängigkeitsgraph dominieren sie in der Regel die Gesamtdauer. Das ist der stille Deckel: Wächst der Paketbaum, wird das Feedback langsamer, obwohl sich die Testsuite nicht geändert hat. Teams validieren daraufhin seltener, bündeln mehr Änderungen pro Validierung und finden Konflikte später. Niemand entscheidet sich für Langsamkeit. Sie stellt sich ein.

Die Kosten landen genau dort, wo ISVs sie spüren: Pull-Request-Prüfungen, nächtliche Regression über mehrere Editionen und der Vorab-Lauf gegen jede Version, die Sie in Subscriber Orgs noch unterstützen.

Was ändert ein warmer Pool konkret?

• Die Feedbackzeit folgt nicht mehr der Abhängigkeitstiefe. Eine fünfte Abhängigkeit kostet nicht länger Minuten pro PR.
• Parallelität wird bezahlbar. Drei Editionen gleichzeitig zu testen sind drei Checkouts, nicht drei Kaltstarts.
• Fehler werden ehrlich. Ist das Provisioning vom kritischen Pfad, liegt ein roter Build weit häufiger an Ihrem Code als an einem wackligen Installationsschritt.
• Reviewer bekommen eine Org, keinen Diff. Eine lebende Umgebung zu übergeben ist kein Gefallen mehr, sondern Standard.

Wie viele Orgs kann ein ISV wirklich poolen?

Hier trifft der Plan auf die Zuteilung. Salesforce dokumentiert die Partnerlimits: Eine aktive Partner Business Org erhält 150 aktive Scratch Orgs und 300 pro Tag, eine Trial-PBO 20 aktive und 40 pro Tag (siehe die Partner-Zuteilungsdokumentation). Daraus folgen zwei Dinge.

Erstens ist das Tageskontingent etwa doppelt so groß wie das aktive: Salesforce sagt damit, dass Umschlag erwartet wird und Horten nicht. Zweitens ist ein Pool nicht gratis: Jede warm gehaltene Org ist eine aktive Org, die anderswo fehlt. Dimensionieren Sie auf die Spitzenlast plus kleinen Puffer, nicht auf die Teamgröße.

Ist ein Scratch-Org-Snapshot dasselbe wie ein Pool?

Nein, und der Unterschied lohnt Präzision, denn beide lösen benachbarte Probleme. Ein Snapshot ist eine Momentkopie einer Scratch Org samt installierter Pakete, Features, Lizenzen, Metadaten und Daten, aus der Sie neue Orgs erzeugen. Das nimmt die Einrichtungsarbeit weg. Das Warten auf die Bereitstellung nimmt es nicht weg.

Snapshots haben eigene Grenzen: Sie laufen nach 90 Tagen ab, die Zuteilung reicht von 3 in der Developer Edition bis 100 in Unlimited und Performance, und Connected Apps, External Credentials und Named Credentials werden nicht mitkopiert. Für ISVs heißt das: Ein Snapshot veraltet, sobald sich eine Abhängigkeitsversion bewegt.

Beides ergänzt sich gut. Bauen Sie den Pool aus einem Snapshot, sparen Sie Einrichtung und Wartezeit zugleich.

Wie betreibt man einen Pool, ohne die Zuteilung zu verbrennen?

1. Trennen Sie Pools nach Zweck. Ein kurzlebiger CI-Pool und ein langlebiger Entwicklerpool haben andere Ablaufzeiten und andere Inhalte.
2. Pinnen Sie Abhängigkeitsversionen in der Pooldefinition. Ein Pool auf "latest" driftet still von dem weg, was Sie ausliefern.
3. Füllen Sie laufend nach, nicht einmal nachts. Nachschieben, sobald Orgs entnommen werden, damit der Pool nicht vormittags leer ist.
4. Lassen Sie konsequent ablaufen. Alte warme Orgs sind veraltete Orgs, die aktive Zuteilung blockieren.
5. Überwachen Sie die Füllhöhe, nicht nur den Erfolg. Die Zahl, die eine schlechte Woche vorhersagt, ist wie oft der Pool auf null fiel.

Woher bekommt man Pooling?

Sie können es selbst mit dem quelloffenen sfp-Tooling bauen, das das flxbl-Projekt dokumentiert, so haben es die frühen Anwender gemacht. In Serpent sind Scratch Orgs in jedem Plan enthalten und vorgewärmtes Pooling gehört zu Scale und Enterprise, neben den 1GP- und 2GP-Workflows, der paketübergreifenden Abhängigkeitsauflösung und den AppExchange-Release-Gates, die Paketteams auf derselben Plattform brauchen. Welchen Weg Sie auch wählen: Bestehen Sie darauf, dass der Pool Ihren Abhängigkeitsgraphen versteht. Ein Pool leerer Orgs löst die kleinere Hälfte des Problems.

Wenn Ihre PR-Prüfungen still von vier auf zwanzig Minuten gewachsen sind, schauen Sie nach, wofür diese zwanzig Minuten draufgehen, bevor Sie einen einzigen Test optimieren. Serpent ist genau für dieses Team gebaut.

FAQ

Wie groß sollte ein Scratch-Org-Pool sein?

Beginnen Sie mit Ihrer gleichzeitigen Spitzenlast plus zwei. Messen Sie, wie oft der Pool auf null fällt, und erhöhen Sie nur dann, denn jede warme Org verbraucht aktive Zuteilung.

Zählen gepoolte Scratch Orgs gegen die Salesforce-Limits?

Ja. Eine Scratch Org gilt ab der Erstellung bis zum Ablauf oder Löschen als aktiv, ein warmer Pool verbraucht also Zuteilung, auch wenn er ruht.

Snapshots oder Pooling?

Wenn möglich beides. Snapshots sparen die Einrichtung in der Org, Pooling spart das Warten auf die Org. Der Pool aus einem Snapshot gibt Ihnen beides.

Hilft Pooling auch Org-zu-Org-Teams?

Weniger. Ohne Abhängigkeitskette ist die Kalterstellung viel günstiger, der Nutzen fällt also kleiner aus als bei Paketteams.