Salesforce-Deployments mit Scratch Orgs automatisieren

Kurze Antwort: Salesforce-Deployments mit Scratch Orgs zu automatisieren heißt, dass Ihr CI-Job aus einer Definitionsdatei eine Wegwerf-Org erzeugt, Abhängigkeiten installiert, Ihre Quellen deployt, die Tests ausführt und die Org wieder löscht. Die Bausteine sind ein Dev Hub, eine Scratch-Org-Definitionsdatei, sfdx-project.json und vier bis fünf CLI-Befehle. Ob das im echten Team überlebt, entscheidet nicht das Skript, sondern die Limits für Scratch Orgs.

Wann nehmen Sie eine Scratch Org statt einer Sandbox?

Eine Scratch Org ist eine wegwerfbare, quellgesteuerte Org aus einer Konfigurationsdatei, ihre Form liegt also im Repository und nicht im Kopf einer Person. Nehmen Sie sie, wenn die Umgebung durch Code definiert und danach weggeworfen werden soll: Entwicklung je Feature, Validierung je Pull Request, Paketbau und Installationstests.

Bleiben Sie bei einer Sandbox, wenn Sie produktionsnahe Datenmengen oder einen langlebigen Integrationsendpunkt brauchen. Scratch Orgs enden bei etwa 200 MB Datensätzen und 50 MB Dateien, und sie laufen ab (Salesforce Ben).

Was gehört in die Definitionsdatei?

Die Definitionsdatei ist der Bauplan. Pflicht ist nur edition, mit Werten wie Developer, Enterprise, Group, Professional und den Partner-Varianten. Die Schlüssel, die zählen (Salesforce DX Developer Guide):

• features: ein Array zusätzlicher Funktionen, die aktiviert werden.
• settings: Org- und Funktionseinstellungen im Metadata-API-Format. Manches, darunter Experience Cloud, braucht ein Feature und eine passende Einstellung.
• objectSettings: Sharing-Modelle und Standard-Datensatztypen je Objekt.
• release: bindet die Org an ein Salesforce-Release, statt dem Dev Hub zu folgen.
• sourceOrg und snapshot: aus einer Org Shape oder einer Momentaufnahme bauen statt aus einer leeren Edition.
• hasSampleData, orgName, adminEmail, country, language: die Kleinigkeiten, die einen Fehler reproduzierbar machen.

Halten Sie je Zweck eine Definitionsdatei. Eine CI-Definition sollte minimal und schnell sein, eine Demo-Definition darf Beispieldaten tragen. Beides zu mischen ist genau der Weg, auf dem aus einer Pull-Request-Prüfung drei Minuten Wartezeit werden.

Wie kommen Ihre Quellen in die Org?

Scratch Orgs nutzen Source Tracking: Sie deployen Ihr Projekt in die Org und holen Änderungen zurück. In der aktuellen CLI ist das sf project deploy start zum Pushen und sf project retrieve start zum Pullen; die älteren Befehle force:source:push und force:source:deploy wurden darin zusammengeführt (Salesforce DX Developer Guide).

Abhängigkeiten kommen aus sfdx-project.json. Der CI-Job liest dort Namespace und Paketabhängigkeiten und installiert sie, bevor Ihre eigenen Quellen landen. Deshalb ist ein Build, der lokal läuft und in der CI scheitert, meist ein Reihenfolgeproblem bei Abhängigkeiten und kein Metadatenproblem.

Was führt der CI-Job konkret aus?

1. Am Dev Hub authentifizieren mit einem JWT-Schlüssel als CI-Secret. Nie interaktiv anmelden.
2. Org erzeugen: sf org create scratch --definition-file config/project-scratch-def.json --alias ci, mit der kürzesten sinnvollen Laufzeit.
3. Paketabhängigkeiten installieren, die in sfdx-project.json deklariert sind.
4. Quellen deployen mit sf project deploy start.
5. Minimale Testdaten laden, aus einer versionierten Datei im Repository.
6. Apex-Tests ausführen und Ergebnisse veröffentlichen, mit Abbruch bei Coverage- oder Assertion-Fehlern.
7. Org löschen, in einem Schritt, der immer läuft, auch wenn vorherige Schritte fehlschlagen.

Schritt sieben vergessen Teams am häufigsten, und genau er legt die Pipeline eine Woche später still.

Warum scheitern Scratch-Org-Pipelines, sobald das Team Fahrt aufnimmt?

Hier hören die meisten Anleitungen auf, und hier brechen echte Pipelines. Vier Dinge, die Sie einplanen sollten:

• Kontingente. Dev Hubs in Developer, Enterprise, Performance und Unlimited Edition erlauben je 6 Scratch Orgs pro Tag und 3 gleichzeitig aktiv (Salesforce Ben). Zehn Pull Requests am Tag mit je einer Org passen da nicht hinein. Prüfen Sie Ihre Werte mit sf org list limits, bevor Sie den Workflow entwerfen, nicht danach.
• Ablauf. Die Standardlaufzeit sind 7 Tage, das Maximum 30. Jede Umgebung, die ein Mensch prüfen soll, braucht eine ausdrückliche Laufzeit, sonst verschwindet sie mitten im Review.
• Erzeugungszeit. Eine kalte Scratch Org plus Abhängigkeitsinstallation ist Totzeit bei jedem Lauf. Vorgewärmte Pools und Snapshots existieren genau dafür, diese Kosten vom kritischen Pfad zu nehmen.
• Daten. Scratch Orgs starten leer. Befüllen Sie sie aus einer versionierten Datei statt aus einem manuellen Export, sonst bestehen Tests aus Gründen, die niemand reproduzieren kann.

Wer an die Decke stößt, hat drei ehrliche Optionen: Orgs je Pull Request nur für Änderungen an paketierten Metadaten, eine gemeinsame langlebige Org für den Rest, oder ein Pool. Serpent gibt jedem Plan Scratch Orgs und ergänzt auf Scale und Enterprise vorgewärmtes Scratch-Org-Pooling, damit die Org bereitsteht, bevor die Pipeline danach fragt.

FAQ

Brauche ich für Scratch Orgs einen Dev Hub?

Ja. Scratch Orgs werden gegen einen aktivierten Dev Hub erstellt, und dort werden auch Ihre täglichen und aktiven Kontingente gezählt.

Können ISVs so ihre Pakete bauen?

Ja, das ist der Standardweg. Bauen und installieren Sie die Paketversion bei jedem Lauf in einer frischen Scratch Org, damit Installationsfehler in der CI auffallen und nicht beim Abonnenten.

Was unterscheidet Org Shape und Snapshot?

Eine Shape kopiert die Konfiguration einer bestehenden Org in eine neue leere Org. Ein Snapshot kopiert eine Scratch Org zu einem Zeitpunkt, inklusive dessen, was bereits deployt war.

Sollte jeder Pull Request eine eigene Scratch Org bekommen?

Nur wenn Ihr Kontingent das trägt. Bei 3 aktiven Orgs braucht ein belebtes Repository Pooling oder eine gemeinsame Validierungs-Org.

Weitere Schritt-für-Schritt-Anleitungen zu Salesforce DevOps finden Sie in unserer SF-Guides-Bibliothek.