Salesforce-deployments automatiseren met scratch orgs

Kort antwoord: Salesforce-deployments automatiseren met scratch orgs betekent dat je CI-job een wegwerporg maakt op basis van een definitiebestand, je dependencies installeert, je source deployt, de tests draait en de org weer verwijdert. De onderdelen zijn een Dev Hub, een scratch org-definitiebestand, sfdx-project.json en vier of vijf CLI-commando's. Wat bepaalt of het standhoudt bij een echt team is niet het script, maar de limieten op scratch orgs.

Wanneer gebruik je een scratch org in plaats van een sandbox?

Een scratch org is een wegwerporg die brongestuurd uit een configuratiebestand wordt gemaakt, zodat de vorm ervan in je repository staat en niet in iemands hoofd. Gebruik hem als de omgeving door code gedefinieerd hoort te zijn en weggegooid mag worden: ontwikkeling per feature, validatie per pull request, en het bouwen en testen van package-installaties.

Blijf bij een sandbox als je productieachtige datavolumes of een langlevend integratie-endpoint nodig hebt. Scratch orgs lopen tegen ongeveer 200MB aan records en 50MB aan bestanden aan, en ze verlopen (Salesforce Ben).

Wat staat er in het definitiebestand?

Het definitiebestand is de blauwdruk. Alleen edition is verplicht, met waarden als Developer, Enterprise, Group, Professional en de Partner-varianten. De sleutels die ertoe doen (Salesforce DX Developer Guide):

• features: een array met aanvullende features die je aanzet.
• settings: org- en featurevoorkeuren in Metadata API-formaat. Sommige mogelijkheden, waaronder Experience Cloud, hebben zowel een feature als een bijpassende setting nodig.
• objectSettings: sharingmodellen en standaard recordtypes per object.
• release: zet de org vast op een Salesforce-release in plaats van de Dev Hub te volgen.
• sourceOrg en snapshot: bouw vanuit een org shape of een kopie op een moment in de tijd in plaats van een kale editie.
• hasSampleData, orgName, adminEmail, country, language: de kleine dingen die een storing reproduceerbaar maken.

Houd een definitiebestand per doel aan. Een CI-definitie hoort minimaal en snel te zijn; een demodefinitie mag voorbeelddata dragen. Die twee mengen is precies hoe een pull request-check verandert in drie minuten wachten.

Hoe komt je source in de org?

Scratch orgs gebruiken source tracking, dus je deployt je project naar de org en haalt wijzigingen weer op. In de huidige CLI is dat sf project deploy start om te pushen en sf project retrieve start om te pullen; de oudere commando's force:source:push en force:source:deploy zijn daarin samengevoegd (Salesforce DX Developer Guide).

Dependencies komen uit sfdx-project.json. De CI-job leest daar de namespace en de package-dependencies en installeert die voordat je eigen source landt. Daarom is een build die lokaal werkt maar in CI faalt meestal een volgordeprobleem met dependencies, geen metadataprobleem.

Wat draait de CI-job precies?

1. Authenticeer bij de Dev Hub met een JWT-sleutel die als CI-secret is opgeslagen. Nooit een interactieve login.
2. Maak de org: sf org create scratch --definition-file config/project-scratch-def.json --alias ci, met de kortst bruikbare looptijd.
3. Installeer de package-dependencies uit sfdx-project.json.
4. Deploy je source met sf project deploy start.
5. Zet de minimale data klaar die de tests nodig hebben, uit een bestand in versiebeheer.
6. Draai de Apex-tests en publiceer de resultaten; laat de job falen op coverage of assertions.
7. Verwijder de org in een stap die altijd draait, ook als eerdere stappen faalden.

Stap zeven is degene die teams vergeten, en degene die de pipeline een week later stilletjes breekt.

Waarom sneuvelen scratch org-pipelines zodra het team druk wordt?

Hier stoppen de meeste handleidingen, en hier breken echte pipelines. Vier dingen om op te plannen:

• Toewijzingslimieten. Dev Hubs op Developer, Enterprise, Performance en Unlimited Edition staan elk 6 scratch orgs per dag en 3 actief tegelijk toe (Salesforce Ben). Tien pull requests per dag met een org per PR passen daar niet in. Controleer je eigen limieten met sf org list limits vóór je de workflow ontwerpt, niet erna.
• Verval. De standaardlooptijd is 7 dagen, het maximum 30. Elke omgeving die een mens moet beoordelen, hoort met een expliciete looptijd te worden gemaakt, anders verdwijnt hij midden in de review.
• Aanmaaktijd. Een koude scratch org plus dependency-installaties is dode tijd bij elke run. Voorverwarmde pools en snapshots bestaan juist om die kosten van het kritieke pad te halen.
• Data. Scratch orgs starten leeg. Vul ze vanuit een bestand in versiebeheer in plaats van een handmatige export, anders slagen je tests om redenen die niemand kan reproduceren.

Loop je tegen het plafond aan, dan zijn de eerlijke opties: reserveer orgs per PR voor wijzigingen die packaged metadata raken, gebruik een gedeelde langlevende org voor de rest, of draai een pool. Serpent geeft scratch orgs op elk plan en voegt op Scale en Enterprise voorverwarmde scratch org-pooling toe, zodat de org al klaarstaat voordat de pipeline erom vraagt.

FAQ

Heb ik een Dev Hub nodig voor scratch orgs?

Ja. Scratch orgs worden aangemaakt tegen een ingeschakelde Dev Hub, en daar worden je dagelijkse en actieve toewijzingen ook geteld.

Kan een ISV zo packages bouwen?

Ja, en het is de standaardroute. Bouw en installeer de packageversie bij elke run in een verse scratch org, zodat installatiefouten in CI opduiken en niet bij een klant.

Wat is het verschil tussen een org shape en een snapshot?

Een shape kopieert de configuratie van een bestaande org naar een nieuwe lege org. Een snapshot kopieert een scratch org op een moment in de tijd, inclusief wat er al naartoe was gedeployed.

Moet elke pull request een eigen scratch org krijgen?

Alleen als je toewijzing dat aankan. Met 3 actieve orgs heeft een drukke repository pooling of een gedeelde validatie-org nodig.

Meer stapsgewijze Salesforce DevOps-gidsen staan in onze SF Guides-bibliotheek.