De twee hebben op het eerste gezicht niet veel gemeen, maar als je beter kijkt kun je 2 karakteristieken onderscheiden: 1. Het moet in één keer goed, zodra het om het echie gaat; en 2. Snelheid. De vergelijking vergezocht? Wellicht. Maar het gaat er nu eenmaal om dat u deze blog opent. Lees snel verder over wat Salesforce DX en een goede opzet van je application development lifecycle te maken hebben met snelheid van oplevering!
Bij het ontwikkelen of uitbreiden van software is de tijd tussen ontwerp en release alsmaar korter geworden in de afgelopen jaren, mede dankzij nieuwe, Agile werkwijzen, en technologie die continue deployment mogelijk maakt. Waar vroeger eens in de maand een release plaatsvond, gaat het vandaag de dag bij zowel kleine als grote bedrijven om meerdere, zo niet honderden deployments per dag.
Vanwege de flexibiliteit en de configurabiliteit van het Force.com platform zijn wij als ontwikkelaars en u als gebruiker ook aan deze snelheid gewend geraakt. Vooral de kleinere wijzigingen zijn in een flits gedaan en in productie genomen. Wat betreft complexere wijzigingen die Apex, Lightning Components en/of Visualforce raken, kan het soms wat ingewikkelder liggen en wat langer duren. De verschuiving naar een kortere ontwikkelcyclus en meer frequente deployments in het algemeen is ook Salesforce.com niet ontgaan. Waar tot voor kort een aantal handmatige stappen nodig waren voor het testen en deployen van nieuwe functionaliteit, heeft Salesforce een grote stap gezet in het ondersteunen van zogenaamde continuous integration met Salesforce DX.

Salesforce DX is een verzameling van nieuwe gereedschappen die door Salesforce zijn ontwikkeld om de workflow van ontwikkelaars te kunnen versnellen. Als eerst is de vorm en structuur, de metadata, van een Salesforce omgeving nog verder losgeweekt om de bron van je org zo te kunnen opslaan in een versiebeheersysteem (VCS). Daardoor kun je de source-of-truth verschuiven van de org naar een repository als GitHub of BitBucket. Wat dit concreet betekent? Dat waar voorheen de functionaliteit in de productieomgeving de basislijn bepaalde voor nieuwe ontwikkelingen, kun je met Salesforce DX de metadata in een versiebeheersysteem stoppen waardoor je altijd snapshots hebt van je org, en kun je nieuwe functies gemakkelijk samenvoegen met bestaande code. Daarbij kun je hiermee altijd terug naar een oudere versie van je metadata door deze vanuit je VCS naar productie te pushen.
Met Salesforce DX wordt er niet meer in een traditionele sandbox ontwikkeld, maar in een zogeheten scratch org. Dit is een tijdelijke omgeving die je in een mum van tijd kunt aanmaken om hierin wijzigingen te doen. Zodra je deze wijzigingen hebt getest, voeg je deze door middel van je VCS samen met je bestaande metadata, en bijvoorbeeld met de wijzigingen van andere ontwikkelaars die vanuit hun eigen scratch org werken. Het grote voordeel hiervan is dat het testen en de integratie geautomatiseerd kan worden door middel van speciale, bestaande tools hiervoor.
Dan vraagt u zich natuurlijk nu af: wat gebeurt er met sandboxes? Deze blijven gewoon bestaan. Sterker nog: deze zijn ook een belangrijk onderdeel van het nieuwe deploymentproces. Het idee is dat er straks ook eerst naar een sandbox wordt gedeployd, om daar de eindgebruiker te kunnen laten testen. Ook is er in de laatste release, van Spring ‘18, naast de hier al genoemde nieuwe functionaliteit, een feature in bèta genomen, namelijk het klonen van een sandbox. Dit geeft aan dat Salesforce.com duidelijk een plaats ziet voor traditionele sandboxes in het ontwikkelproces.

Met een makkelijk te configureren omgeving als Salesforce is het verleidelijk om kleine wijzigingen rechtstreeks in productie te doen, maar een ongeluk zit in een klein hoekje. Wij raden daarom aan om gebruik te maken van de gratis Partial Copy sandbox die (sinds Spring ‘16) beschikbaar is voor alle Enterprise-gebruikers. Door middel van een script kunnen we ervoor zorgen dat bijvoorbeeld alle e-mailadressen worden aangepast of verwijderd zodat u zonder problemen alles kunt testen tegen een kopie van productiedata, en deze kopie frequent kunt verversen.
Op die manier kun je deze sandbox als staging-omgeving inzetten waar alle nieuwe functionaliteit of wijzigingen in configuratie én code kunnen worden getest voordat je deze in productie neemt. We helpen u er graag bij!

Reacties

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Fill out this field
Fill out this field
Geef een geldig e-mailadres op.

Menu