Als ontwikkelaar bouw en test je het liefst op een Sandbox-omgeving en niet direct in Productie. Maar hoe krijg je op een juiste manier de APEX-classen, Visualforce-pagina’s, objecten, velden etc. naar productie overgezet? Dat gaat we in dit artikel behandelen.
Soorten sandboxen
In Salesforce kun je verschillende soorten ontwikkelomgevingen (Sandboxen) creëren. Salesforce biedt Developer, Developer Pro, Partial Copy, en Full sandboxen voor respectievelijk ontwikkeling, uitgebreide ontwikkeling, gedeeltelijke data en metadata kopieën, en volledige productie-replicaties. In mijn geval heb ik een developer sandbox gemaakt wat in de meeste gevallen ruim voldoende is.Testdata in de Sandbox
En dan is het zaak om te gaan bouwen in je nieuwe sandbox omgeving. Het is belangrijk om te weten dat alle data niet meegenomen wordt in een Sandbox en ook niet als je vervolgens de sandbox met een change set weer terugzet naar productie. In de sandbox kun je dus met testdata werken.Inbound en Outbound changesets
In Salesforce heb je 2 soorten changeset, namelijk een inbound en een outbound changeset:
Outbound Changeset: Dit is een verzameling aanpassingen die je vanuit je huidige Salesforce-org (bijvoorbeeld een sandbox) samenstelt en naar een andere org (zoals productie) verzendt. Je maakt en verzendt de changeset vanuit de bronorg.
Inbound Changeset: Dit is een verzameling aanpassingen die je ontvangt in je Salesforce-org (bijvoorbeeld productie) vanuit een andere org (zoals een sandbox). Je importeert en implementeert de changeset in de doelorg.
Kort gezegd, Outbound changesets worden verzonden vanuit een org, terwijl Inbound changesets worden ontvangen en geïmplementeerd in een org. Dit houdt in dat we eerst een outbound changeset in de sandbox moeten maken en vervolgens een inbound changeset in de productieomgeving.
Het maken van een outbound changeset
Om een outbound changeset te maken (in de sandbox!), gaan we in de setup naar Environments > Change Sets > Outbound Change Sets en klikken vervolgens op “New”. Na het geven van een naam en een evenetuele omschrijving heb je de mogelijkheid om componenten en profielen toe te voegen. In mijn geval ga ik voor deze keer Componenten toevoegen.
Changeset samenstellen
Ik kies in eerste instantie de App en druk vervolgens op “View/Add dependencies”. Op deze manier kan ik alle gerelateerde objecten/velden/pagina lay-outs/assets etc. selecteren, behorende bij deze App. Vervolgens wil ik nog een APEX class toevoegen, vanuit dit artikel, dus die selecteer ik separaat. Als ik dan vervolgens weer op “View/Add dependencies” kan ik een flow toevoegen die getriggerd wordt vanuit de APEX etc. Op deze manier kun je snel een change set maken. een Force.com site kun je helaas niet direct aan de change set toevoegen. Als je klaar bent druk je op “Upload”. Daarna kun je nog checken of de changeset naar de juiste omgeving gestuurd wordt (productie) en druk je nogmaals op “upload” en zie je als het goed is de melding “Your upload is currently in progress. We’ll send you an email when it’s complete.”.
De inbound changeset op productie
Als je een mail ontvangen hebt en je logt in op productie, kun je vervolgens via Setup naar “Inbound changesets” gaan. Onder het kopje “Change Sets Awaiting Deployment” staat als het goed is nu de door jou aangemaakte changeset. Klik op “validate” om een controle uit te voeren of alles compleet en compatible is. Je hebt 4 soorten testen:
- Default: Geen tests in sandbox, lokale tests in productie zonder Apex-pakketten.
- Run local tests: Alle lokale tests, behalve van managed packages.
- Run all tests: Alle tests in de organisatie, inclusief van managed packages.
- Run specified tests: Alleen gespecificeerde tests; in productie minimaal 75% code coverage voor Apex in change set.
In mijn geval kies ik voor “Run local tests”, omdat er geen managed packages tussen zitten.
Fouten oplossen uit de test
Ik had zelf nog best wat issues na de test (17 stuks), maar deze waren relatief makkelijk te verhelpen. Er waren wat afhankelijkheden op velden, waarbij deze velden niet in productie zaten en er zat nog een issue in een APEX-script. Daarom is het altijd goed om te testen! Als er geen fouten meer in de deployment zitten kun je de deployment starten en is de migratie klaar.
