Zo schrijf je een sandbox-refreshrunbook dat je team echt volgt

Een sandbox-refreshrunbook dat je team volgt, is kort, staat naast je code en geeft elke stap een eigenaar, een tijdsinschatting en een check die bewijst dat hij klaar is. De meeste refreshdocumenten mislukken omdat het lange wikipagina's zijn waar niemand eigenaar van is. Schrijf het jouwe als checklist in vier fases, automatiseer de stappen die mensen overslaan en oefen het één keer voordat je erop vertrouwt.

Wat is een sandbox-refreshrunbook?

Een sandbox-refreshrunbook is de stapsgewijze procedure die je team uitvoert telkens als een Salesforce-sandbox vanuit productie wordt ververst: wat je vooraf veiligstelt, wat je achteraf herstelt, wie elke stap doet en hoe je weet dat het werkte. Het is niet je sandboxstrategie, die bepaalt welke sandboxes er zijn en waarom. Het runbook is het deel dat mensen uitvoeren op de ochtend van de refresh.

Waarom negeren teams refreshrunbooks?

• Geen eigenaar per stap. Als het team de integraties herstelt, doet niemand het.
• Geen definitie van klaar. Integraties opnieuw configureren valt niet te controleren. Een testcallout via de named credential geeft 200 terug wel.
• Het staat op de verkeerde plek. Een wikipagina raakt los van de org. Een Markdown-bestand in de repo wordt gereviewd als de org verandert.
• Te veel handmatige stappen. Elke handmatige stap is er een die iemand onder tijdsdruk overslaat.

Hoe vaak kun je elk type sandbox verversen?

Salesforce begrenst je ritme, dus zet de limieten bovenaan je runbook. Volgens de sandboxgids van Salesforce Ben:

• Developer en Developer Pro: eens per dag, alleen metadata.
• Partial Copy: elke vijf dagen, metadata plus een deel van je data.
• Full: elke 29 dagen, alle productiemetadata en -data.

Een mislukte Full-refresh kan je een maand kosten, dus dat runbook verdient de meeste zorg.

Wat hoort er in elke fase van het runbook?

Schrijf elke stap in hetzelfde format: stap | eigenaar | geautomatiseerd? | minuten | klaar als. Groepeer de stappen daarna in vier fases.

1. Voor de refresh

• Kondig het tijdvak aan bij developers, QA en businesstesters, en vraag om een bevestiging.
• Commit of deploy elke lopende wijziging naar versiebeheer. Een refresh overschrijft de sandbox, en alles wat niet in Git staat is weg.
• Exporteer configuratie die als data is opgeslagen, zoals de instellingsrecords die sommige AppExchange-pakketten buiten metadata bewaren.
• Maak een lijst van de integratie-endpoints, named credentials en connected apps die je moet omzetten.

2. Tijdens de refresh

• Controleer dat productie stabiel is en niet midden in een release zit.
• Geef je post-copy Apex-klasse op bij het starten van de refresh, zodat de automatisering draait zonder dat iemand eraan hoeft te denken.
• Noteer de starttijd en wie de refresh startte.

3. Na de refresh

• Laat e-mailbezorging op System email only staan, de standaard voor nieuwe en ververste sandboxes volgens Apex Hours, tot de data gemaskeerd is.
• Haal het achtervoegsel .invalid alleen weg bij gebruikers die sandboxmail nodig hebben. Salesforce voegt het bij elke refresh of clone toe aan e-mailadressen van gebruikers, zoals het helpartikel uitlegt.
• Maskeer of verwijder persoonsgegevens voordat je de toegang verbreedt.
• Zet integraties om naar hun sandbox-endpoints en authenticeer opnieuw.
• Deploy werk dat voorloopt op productie opnieuw vanuit versiebeheer, en laad daarna testdata.

4. Valideren en overdragen

• Doe een smoketest: log in als tester, doorloop één kernflow, doe één testcallout.
• Draai je Apex-tests, of minstens de subset die je integraties dekt.
• Meld dat de sandbox klaar is, met bekende problemen, en herstel in het runbook zelf wat er misging.

Welke refreshstappen automatiseer je als eerste?

Automatiseer de stappen die vaak voorkomen, foutgevoelig zijn en saai. Met de SandboxPostCopy-interface van Salesforce schrijf je een Apex-klasse die automatisch draait wanneer de sandbox wordt aangemaakt, en de best practices van Salto noemen e-mailadressen maskeren en custom settings en custom metadata bijwerken als typische toepassingen. Goede eerste kandidaten:

1. Persoonsgegevens op contacten en leads maskeren.
2. Custom settings en endpointconfiguratie terugzetten naar sandboxwaarden.
3. E-mail herstellen voor de kleine groep gebruikers die het nodig heeft.
4. Basistestdata opnieuw laden. Onze gids over een Salesforce-sandbox vullen met realistische data behandelt de opties.

Maak de klasse idempotent en log wat ze veranderde, zodat een mislukte run veilig herhaald kan worden.

Hoe past het runbook in je releasepipeline?

Een refresh zet een sandbox terug naar productie, dus alles tussen die sandbox en productie verdwijnt tenzij je pipeline het terugzet. Twee gewoontes voorkomen dat verlies. Ten eerste: maak Git de bron van waarheid, zodat lopend werk opnieuw wordt gedeployed in plaats van opnieuw gebouwd. Ten tweede: richt back-promotion in je Salesforce DevOps-pipeline in, zodat hotfixes uit productie tussen refreshes door naar lagere omgevingen stromen. Draai na de refresh dezelfde checks als bij elke pull request. Onze gids over Salesforce-testautomatisering in CI scheidt wat je per pull request draait van wat je 's nachts draait.

Is opnieuw deployen na elke refresh nog steeds een handmatige middag, dan neemt een DevOps-platform het meeste daarvan over. Het gratis Essentials-plan van Serpent bevat delta-deployments en rollback met één klik; vergelijk de plannen op de prijspagina van Serpent.

Hoe zorg je dat het team het echt volgt?

• Houd elke fase op één scherm en verwijs door voor details.
• Bewaar het runbook in de repo en review wijzigingen eraan zoals code.
• Oefen op een Developer-sandbox, die je dagelijks kunt verversen, vóór de volgende Full-refresh.
• Werk het bij op de dag dat er iets misgaat. Een runbook dat één keer fout zit, wordt voorgoed genegeerd.
• Wijs voor elke stap een back-upeigenaar aan.

Meer praktische gidsen zoals deze vind je in de SF Guides-bibliotheek.

FAQ

Hoe lang moet een sandbox-refreshrunbook zijn?

Kort genoeg voor één scherm per fase. Houd het runbook als checklist en zet details in gelinkte documenten.

Waarvoor gebruik je SandboxPostCopy?

Het is een Apex-interface voor een klasse die automatisch draait wanneer een sandbox wordt aangemaakt, meestal om data te maskeren en instellingen terug te zetten.

Waarom eindigen e-mailadressen op .invalid na een refresh?

Salesforce voegt .invalid toe zodat productiegebruikers geen mail uit de sandbox krijgen. Haal het alleen weg bij gebruikers die sandboxmail nodig hebben.

Hoe vaak kun je een Full-sandbox verversen?

Eens per 29 dagen. Partial Copy-sandboxes kun je elke vijf dagen verversen en Developer-sandboxes dagelijks.