“Mag de Partial gerefreshed worden?” is een vraag die ik met enige regelmaat voorbij zie komen en die ik helaas ook zelf wel eens moet stellen. Er is een goede manier om deze vraag overbodig te maken en nooit het risico te lopen om nog niet gepubliceerd werk te verliezen.

Misschien goed om je een beetje uitleg te geven over het bovenstaande. Wellicht lees je een aantal termen die nieuw voor je zijn. Die zal ik toelichten, want de les die ik in dit artikel wil meegeven is een heel waardevolle voor jezelf, maar ook voor iedereen met wie je samenwerkt aan de configuratie van je omgeving.

Wat is een Sandbox

Als je nieuwe functionaliteit wilt toevoegen of gewoon iets dat je geleerd hebt wilt uitproberen, doe dat dan in een Sandbox. Dit is een kopie van je productie omgeving waarin je kunt expirimenteren zonder onbedoeld functionaliteit kapot te maken of de data waar je bedrijf van afhankelijk is te vervuilen. Een veilige speeltuin dus. Of een zandbak…

Er zijn – in de meeste gevallen – twee soorten Sandboxes.

Developer Sandbox

Een developer Sandbox bevat alleen alle metadata van je productie omgeving (velden, pagina layouts, flows, goedkeuringsprocessen etc.), maar geen data (zoals klanten, contactpersonen, cases of contracten). Om iets te kunnen testen of demonstreren zul je dan dus wel nog even zelf data in die sandbox moeten aanmaken. Bij Enterprise Edition – welke ik het vaakst gebruikt zie worden – kun je tot 25 developer sandboxen tegelijk actief hebben.

Partial Sandbox

Een Partial Sandbox bevat naast alle metadata ook een deel van de data van de productie omgeving. Dit is een handige omgeving voor uitgebreid testen van nieuwe functionaliteiten. Hier van kun je er bij Enterprise Edition 1 tegelijk actief hebben.

Een Partial Sandbox aanmaken of verversen duurt langer dan aanmaken van een Developer Sandbox en mag je ook minder frequent doen.

Wat betekent Refreshen van een Sandbox

Op het moment dat je een Sandbox aanmaakt of ververst (refresh), maak je een momentopname. Je Sandbox is op dat moment qua configuratie en metadata indentiek aan je productie omgeving.

Na verloop van tijd kan een sandbox met de productie omgeving uit de pas gaan lopen. Bijvoorbeeld als er wijzigingen rechtstreeks in de Productie omgeving zijn gemaakt. Als dat zo is, kun je niet blind op de testen die je in de Partial Sandbox doet vertrouwen en loop je zelfs de kans onbedoeld functionaliteiten in de productie omgeving te overschrijven.

Als je vermoedt of zeker weet dat je Partial Sandbox en Productie omgeving niet ‘in sync’ zijn, wil je de sandbox verversen – een nieuwe momentopname maken. Als je daar met meerdere mensen in werkt, zou je door te verversen ook wel eens onderhanden werk van iemand anders kunnen verwijderen. Vandaar dat je dit wel even wilt afstemmen, met je collega admin(s) en consultants en developer van je technische partner.

Sandboxen beheren

Sandboxen aanmaken, verversen en wissen kun je doen via Setup > Sandboxen

Bouw en test volgens een vaste methode

Het is waardevol om je Partial Sandbox wat metadata / configuratie betreft zo nauwkeurig mogelijk gelijk te houden aan je productie omgeving. Dit maakt dat verversen onnodig is. Wanneer je een sandbox ververst, kun je nieuw gebouwde features, die nog niet in de productie omgeving staan, kwijtraken.

Daarom is het een goede gewoonte om nieuwe functionaliteit in een Developer Sandbox te ontwikkelen en door middel van wijzigingensets naar de Partial omgeving te publiceren voor het testen. Mocht de Partial Sandbox dan toch ververst worden, dan heb je nog een back up en kun je de eerder gebruikte wijzigingenset in je Developer Sandbox gebruiken om de functionaliteit opnieuw te publiceren naar de Partial Sandbox.

Door in een Developer Sandbox te werken, kun je daar eerst je werk perfectioneren voor je de Partial Sandbox vervuilt met achterhaalde Flow versies of velden die je later toch niet meer nodig blijkt te hebben.

En als iedereen netjes alles wat naar Productie gaat ook naar de Partial publiceert, blijft die laatste ook een betrouwbare en actuele kopie van de Productie omgeving.

Een goede back up

Tijdens het testen of zelfs tijdens het gebruik in productie kom je ongetwijfeld in de verleiding om een kleine wijziging meteen in de Partial of Productie omgeving te maken. Wen je aan om zelfs de kleinste wijzigingen consequent in de Developer Sandbox te maken en van daaruit te publiceren. Op die manier is de Developer Sandbox altijd een betrouwbare, volledige en actuele back up van je functionaliteit.

Het onderstaande schema laat zien hoe deze werkwijze er precies uitziet.

Wanneer de functionaliteit helemaal live is, kan het fijn zijn om de Developer Sandbox waarin je de functionaliteit gebouwd hebt, op te ruimen. Doe dit meteen op het moment dat je zeker weet dat alle functionaliteit die daar gemaakt is ook veilig geborgd is in een andere omgeving (Productie). Anders zou je wel eens kunnen eindigen met een hele serie Developer Sandboxen die je niet durft te wissen omdat er misschien nog iets belangrijks in staat, maar wat was het ook alweer…

Wijzigingensets

Wijzigingensets zijn de manier om de meeste soorten wijzigingen van metadata tussen aan elkaar gerelateerde omgevingen uit te wisselen. Over wijzigingensets is veel te vertellen, maar dat wordt een ander artikel.