Click deploy-checklist: zo voer je een veilige point-and-click Salesforce-deployment uit

TL;DR: Een click deploy verplaatst Salesforce-metadata van de ene org naar de andere door componenten in een interface te selecteren, in plaats van een change set te bouwen of CLI-commando's te typen. Doe het veilig: vergelijk de orgs, voeg afhankelijkheden toe, valideer met een bewust gekozen Apex-testniveau en voer daarna een quick deploy van het gevalideerde pakket uit en controleer het. De volledige checklist staat hieronder.

Wat is een click deploy in Salesforce?

"Click deploy" is de korte term voor point-and-click deployment: een tool vergelijkt een bron- en een doel-org, laat zien wat er veranderd is en deployt de componenten die je aanvinkt. De naam komt van ClickDeploy, dat Copado in 2020 overnam en nu verkoopt als Copado Essentials; de geschiedenis en prijzen lees je in hoe ClickDeploy werkt en wat het kost. Copado Essentials, Gearset en andere klikgebaseerde tools geven het uiteindelijke pakket allemaal door aan de Salesforce Metadata API, dus de regels van het platform gelden in welke tool je ook klikt. Daarom werkt deze checklist overal.

Hoe voer je stap voor stap een veilige click deploy uit?

1. Vernieuw de vergelijking. Vergelijk bron en doel vlak voor je deployt, niet de dag ervoor. Iemand kan het doel intussen gewijzigd hebben.
2. Selecteer de wijziging en daarna de afhankelijkheden. Een nieuw veld heeft zijn object nodig, en een Flow kan velden, Apex-klassen of permission sets nodig hebben. De meeste tools signaleren ontbrekende afhankelijkheden; vertrouw op die melding, niet op je geheugen.
3. Houd het pakket klein. Deploy alleen wat veranderd is. Salesforce begrenst een deployment-.zip op 39 MB, zoals de documentatie van Gearset vermeldt, en kleine pakketten zijn makkelijker te debuggen. Delta-deployments maken dat de standaard.
4. Plan verwijderingen apart. Verwijderingen reizen mee in destructive-change-manifesten, die de Salesforce CLI vóór of na de deployment toepast. Kies de volgorde op basis van wat nog naar het component verwijst.
5. Valideer eerst. Voer een check-only-validatie uit. Die draait Apex-tests en meldt fouten zonder iets in de org op te slaan.
6. Kies het testniveau bewust. De standaard is niet altijd juist; zie de volgende sectie.
7. Doe een quick deploy van het gevalideerde pakket. In productie kan een geslaagde validatie later worden uitgerold zonder de Apex-tests opnieuw te draaien. Volgens de CLI-referentie blijft de job-ID 10 dagen geldig vanaf de start van de validatie, dus je kunt 's middags valideren en in een rustig moment uitrollen.
8. Controleer en leg vast. Open de gewijzigde pagina's, doe een korte smoketest en noteer precies wat er live ging, zodat een rollback iets heeft om naar terug te gaan.

Welk Apex-testniveau moet je kiezen?

De Salesforce CLI documenteert vijf testniveaus, en de meeste kliktools tonen dezelfde lijst onder vriendelijkere namen:

• NoTestRun: geen tests. Alleen toegestaan voor ontwikkelomgevingen zoals sandboxes, Developer Edition en trial-orgs.
• RunSpecifiedTests: alleen de tests die je opgeeft. De handleiding van Gearset vermeldt dat elke klasse of trigger in het pakket dan zelf 75% dekking nodig heeft.
• RunLocalTests: alle tests behalve die van geïnstalleerde managed en unlocked packages. Dit is de standaard voor productiedeployments met Apex-klassen of triggers.
• RunAllTestsInOrg: alles, inclusief tests van managed packages.
• RunRelevantTests (bèta): Salesforce kiest tests door de payload en de afhankelijkheden te analyseren. Vereist API-versie 66 of hoger.

Wees voorzichtig met RunRelevantTests in productie. De Spring '26-tests van Bob Buzzard lieten zien dat het tests met directe afhankelijkheden van de gewijzigde code koos, maar indirecte ketens en dynamisch geïnstantieerde klassen miste. Markeer onmisbare tests met @IsTest(critical=true) voordat je erop vertrouwt.

Wanneer is een click deploy de verkeerde tool?

• Meer dan één persoon deployt naar dezelfde org. Org-naar-org-deployments hebben geen gedeelde geschiedenis, dus de tweede deployment kan de eerste overschrijven.
• Je hebt een betrouwbare rollback nodig. Terugdraaien is het makkelijkst als elke release gecommit was voordat hij live ging.
• Je levert een managed package. ISV's brengen pakketversies uit naar subscribers, geen org-diffs; zie second-generation managed packages.

Afscheid nemen van org-naar-org-deployments betekent geen afscheid van klikken. Admins kunnen wijzigingen blijven selecteren in een interface terwijl de tool de Git-commits schrijft, zoals we laten zien in DevOps voor admins zonder Git aan te raken.

Hoe pakt Tekunda klikgebaseerde deployment aan?

Tekunda is het Salesforce-advies- en productbedrijf achter Serpent, het DevOps-platform dat het ook voor eigen klantlevering gebruikt. Serpent behoudt de klik-om-te-selecteren-ervaring: je kiest wijzigingen, koppelt ze aan een ticket en promoot ze door je pipeline, terwijl Git, pull requests, validatie en Apex-tests eronder draaien, met AI-codereview op elk plan. Er wordt niets in je org geïnstalleerd en je start gratis, met een vaste teamprijs op onze prijspagina. Meer stappenplannen vind je in de SF Guides-bibliotheek.

FAQ

Is een click deploy hetzelfde als een change set?

Nee. Beide verplaatsen metadata tussen orgs, maar een kliktool bouwt het pakket op basis van een org-vergelijking in plaats van dat je componenten één voor één aan een change set toevoegt.

Hoe lang kan ik wachten tussen validatie en quick deploy?

Tot 10 dagen vanaf de start van de validatie, volgens de Salesforce CLI-referentie.

Draaien sandbox-deployments Apex-tests?

Standaard niet. Het standaardniveau van Salesforce draait geen tests in een sandbox, terwijl productiedeployments met Apex-klassen of triggers de lokale tests draaien.

Kan ik gratis een click deploy doen?

Ja. Copado Essentials heeft een gratis niveau met tot 15 deployments per maand voor één gebruiker, en Serpent biedt ook een gratis plan.