Click deploy valideren: zo voer je een check-only deployment en Quick Deploy uit

TL;DR: Een click deploy-validatie is een check-only deployment: Salesforce voert je pakket en de Apex-tests uit tegen de doel-org zonder iets op te slaan. Slaagt hij met tests, dan krijg je een job-ID waarmee je binnen 10 dagen een Quick Deploy doet, zonder dat de tests in je releasevenster opnieuw draaien. Valideer vroeg en release zonder twee keer op tests te wachten.

Wat is een click deploy-validatie?

Een deployment valideren betekent hem in check-only-modus uitvoeren. De Trailhead-module over releases van Salesforce beschrijft het als tests draaien om de deployment te valideren zonder de componenten in de doel-org op te slaan. Er verandert niets in de org. Je leert of het pakket zou deployen en of de tests slagen. In een point-and-click-tool is het meestal een Validate-knop naast Deploy.

Trailhead definieert ook wat geslaagd betekent: alle Apex-tests zijn geslaagd en de tests dekken minstens 75% van de code die je deployt.

Waarom valideren voordat je click deployt?

• Fouten komen vroeg boven. Ontbrekende afhankelijkheden, compileerfouten en falende tests verschijnen als resultaat om op te lossen, niet als kapotte release.
• Het trage deel verlaat het releasevenster. Quick Deploy hergebruikt de testresultaten van de validatie, dus de productiestap draait de Apex-tests niet opnieuw.
• Goedkeurders krijgen bewijs. Een geslaagde validatie kan een reviewer controleren voor de goedkeuring, en dat is de eerste gate in onze click deploy-checklist.

Hoe voer je een validatie en Quick Deploy uit?

1. Bouw het pakket vanuit een bron die je vertrouwt. Een org-vergelijking werkt, maar een branch is makkelijker te reviewen. Zie click deploy vanuit Git voor die route.
2. Kies een testniveau dat echt tests draait. De volgende sectie laat zien welke in aanmerking komen.
3. Voer Validate uit. Vanuit de CLI is dat sf project deploy validate. Gearset en Salto bieden validatie in hun deploymentflows, en Salto vraagt daarbij welke tests je wilt draaien.
4. Lees het resultaat en valideer opnieuw na elke fix. Een validatie staat alleen in voor precies het pakket dat ze controleerde.
5. Bewaar het job-ID. Trailhead merkt op dat de validatie een job-ID teruggeeft waarnaar je in de quick deploy verwijst.
6. Quick Deploy binnen het venster. Gebruik de Quick Deploy-knop op de pagina Deployment Status in Setup (die verschijnt alleen bij geschikte validaties), sf project deploy quick met het job-ID, of de Metadata API-aanroep deployRecentValidation().
7. Zorg voor een weg terug. Een schone validatie verlaagt het risico maar haalt het niet weg, dus plan je click deploy-rollback voordat je releaset.

Met welk testniveau valideer je?

• RunLocalTests: draait de lokale tests van de org. Het release-voorbeeld van Trailhead gebruikt het voor zowel de staging- als de productievalidatie.
• RunSpecifiedTests: draait alleen de klassen die je noemt. Sneller, maar die tests moeten de dekking leveren voor wat je deployt, wat volgens Apex Anvil 75% per gedeployde klasse en trigger betekent.
• RunAllTestsInOrg: draait elke test in de org, inclusief tests van managed packages. De traagste optie.
• NoTestRun: niet geschikt voor Quick Deploy, want er zijn geen testresultaten om te hergebruiken.
• RunRelevantTests: geïntroduceerd als bèta in Spring '26. Salesforce kiest tests die gekoppeld zijn aan de Apex in de payload, maar Bob Buzzard ontdekte dat het alleen directe afhankelijkheden volgt, dus test het eerst buiten productie.

Wat maakt een validatie ongeldig?

• Leeftijd. Het job-ID is 10 dagen geldig. Daarna valideer je opnieuw.
• Een andere deployment. Het venster van 10 dagen uit Trailhead geldt alleen als niemand in de tussentijd naar die org deployt of er grote wijzigingen in doet.
• Drift die je niet zag. De documentatie van Gearset waarschuwt dat wijzigingen in orgs na het bouwen van een pakket niet worden meegenomen en bij de deploy overschreven kunnen worden.
• Geen tests. Een validatie met NoTestRun kan niet via Quick Deploy.

De praktische regel: valideer zo dicht bij de release als de looptijd van je tests toelaat, en bevries andere deployments naar die org tot je live gaat.

Wie is Tekunda, en hoe gaat Serpent om met validatie?

Tekunda is een Salesforce-consultancy- en productbedrijf en het bedrijf achter Serpent, het Salesforce DevOps-platform dat het in 2024 lanceerde. In Serpent is validatie een vaste stap in plaats van een optionele knop: de deployflow loopt via configureren, bestanden selecteren, valideren en deployen. De validatiestap is een dry run tegen de doel-org. Een schoon resultaat gaat automatisch door en een fout stopt daar. Serpent deployt bovendien alleen de componenten die een work item wijzigde, wat validaties klein houdt. Vergelijk je het met hoe ClickDeploy werkt en wat het kost: het Scale-plan kost $699 per bedrijf per maand met onbeperkt aantal gebruikers; zie de prijspagina. Meer stapsgewijze gidsen vind je in SF Guides.

FAQ

Verandert een validatie iets in de doel-org?

Nee. Het is een check-only deployment, dus er worden geen componenten opgeslagen.

Hoe lang kan ik wachten met Quick Deploy?

Tot 10 dagen, zolang er in de tussentijd geen andere deployment of grote wijziging in die org plaatsvindt.

Kan ik een validatie zonder tests via Quick Deploy uitrollen?

Nee. Quick Deploy hergebruikt testresultaten, dus de validatie moet tests draaien en slagen met de vereiste dekking.

Draait Quick Deploy de Apex-tests opnieuw?

Nee. Het steunt op de tests uit de validatie, en daarom is het sneller klaar dan een gewone deploy.