Click Deploy validieren: Check-only-Deployment und Quick Deploy

Kurz gesagt: Eine Click-Deploy-Validierung ist ein Check-only-Deployment: Salesforce führt Ihr Paket und dessen Apex-Tests gegen die Ziel-Org aus, ohne etwas zu speichern. Besteht sie mit ausgeführten Tests, erhalten Sie eine Job-ID, mit der Sie innerhalb von 10 Tagen per Quick Deploy ausliefern, ohne dass die Tests im Release-Fenster erneut laufen. Validieren Sie früh und releasen Sie, ohne zweimal auf Tests zu warten.

Was ist eine Click-Deploy-Validierung?

Ein Deployment zu validieren heißt, es im Check-only-Modus auszuführen. Salesforces Trailhead-Modul zu Releases beschreibt das als Ausführen der Tests, um das Deployment zu validieren, ohne die Komponenten in der Ziel-Org zu speichern. In der Org ändert sich nichts. Sie erfahren, ob das Paket deployen würde und ob die Tests bestehen. In einem Point-and-Click-Tool ist das meist ein Validate-Button neben Deploy.

Trailhead definiert auch, was Erfolg bedeutet: Alle Apex-Tests sind bestanden, und die Tests decken mindestens 75 % des deployten Codes ab.

Warum vor dem Click Deploy validieren?

• Fehler zeigen sich früh. Fehlende Abhängigkeiten, Kompilierfehler und fehlschlagende Tests erscheinen als Ergebnis, das Sie beheben, nicht als kaputtes Release.
• Der langsame Teil verlässt das Release-Fenster. Quick Deploy nutzt die Testergebnisse der Validierung, sodass der Produktionsschritt die Apex-Tests nicht erneut ausführt.
• Freigebende bekommen einen Nachweis. Eine bestandene Validierung kann ein Reviewer vor der Freigabe prüfen, und genau das ist das erste Gate in unserer Click-Deploy-Checkliste.

Wie führen Sie Validierung und Quick Deploy durch?

1. Bauen Sie das Paket aus einer vertrauenswürdigen Quelle. Ein Org-Vergleich funktioniert, aber ein Branch lässt sich leichter reviewen. Siehe Click Deploy aus Git für diesen Weg.
2. Wählen Sie ein Testlevel, das tatsächlich Tests ausführt. Welche infrage kommen, zeigt der nächste Abschnitt.
3. Starten Sie Validate. In der CLI ist das sf project deploy validate. Gearset und Salto bieten die Validierung in ihren Deployment-Abläufen an, und Salto fragt dabei, welche Tests laufen sollen.
4. Lesen Sie das Ergebnis und validieren Sie nach jeder Korrektur neu. Eine Validierung bürgt nur für genau das Paket, das sie geprüft hat.
5. Bewahren Sie die Job-ID auf. Trailhead weist darauf hin, dass die Validierung eine Job-ID zurückgibt, auf die Sie beim Quick Deploy verweisen.
6. Quick Deploy innerhalb des Fensters. Nutzen Sie den Quick-Deploy-Button auf der Seite Deployment Status in Setup (er erscheint nur bei geeigneten Validierungen), sf project deploy quick mit der Job-ID oder den Metadata-API-Aufruf deployRecentValidation().
7. Halten Sie einen Rückweg bereit. Eine saubere Validierung senkt das Risiko, beseitigt es aber nicht, also planen Sie Ihr Click-Deploy-Rollback vor dem Release.

Mit welchem Testlevel sollten Sie validieren?

• RunLocalTests: führt die lokalen Tests der Org aus. Das Release-Beispiel in Trailhead nutzt es sowohl für die Staging- als auch für die Produktionsvalidierung.
• RunSpecifiedTests: führt nur die Klassen aus, die Sie benennen. Schneller, aber diese Tests müssen die Abdeckung für das Deployte liefern, laut Apex Anvil 75 % für jede deployte Klasse und jeden Trigger.
• RunAllTestsInOrg: führt jeden Test der Org aus, auch die aus Managed Packages. Die langsamste Option.
• NoTestRun: nicht mit Quick Deploy kompatibel, weil es keine Testergebnisse zum Wiederverwenden gibt.
• RunRelevantTests: mit Spring '26 als Beta eingeführt. Salesforce wählt Tests, die mit dem Apex im Paket verknüpft sind, doch Bob Buzzard stellte fest, dass nur direkte Abhängigkeiten berücksichtigt werden. Testen Sie es also zuerst außerhalb der Produktion.

Was macht eine Validierung ungültig?

• Alter. Die Job-ID gilt 10 Tage. Danach validieren Sie erneut.
• Ein weiteres Deployment. Das 10-Tage-Fenster aus Trailhead gilt nur, wenn in der Zwischenzeit niemand in diese Org deployt oder größere Änderungen daran vornimmt.
• Unbemerkter Drift. Die Gearset-Dokumentation warnt, dass Änderungen in Orgs nach dem Erstellen eines Pakets nicht berücksichtigt werden und beim Deployment überschrieben werden können.
• Keine Tests. Eine Validierung mit NoTestRun lässt sich nicht per Quick Deploy ausliefern.

Die Faustregel: Validieren Sie so nah am Release, wie es die Laufzeit Ihrer Tests zulässt, und frieren Sie andere Deployments in diese Org bis zur Auslieferung ein.

Wer ist Tekunda, und wie handhabt Serpent die Validierung?

Tekunda ist ein Salesforce-Beratungs- und Produktunternehmen und steht hinter Serpent, der Salesforce-DevOps-Plattform, die es 2024 gestartet hat. In Serpent ist die Validierung ein fester Schritt statt eines optionalen Buttons: Der Deploy-Ablauf führt durch Konfigurieren, Dateien auswählen, Validieren und Deployen. Der Validierungsschritt ist ein Dry Run gegen die Ziel-Org. Ein sauberes Ergebnis läuft automatisch weiter, ein Fehler stoppt dort. Außerdem deployt Serpent nur die Komponenten, die ein Work Item geändert hat, was Validierungen klein hält. Wenn Sie es mit Funktionsweise und Kosten von ClickDeploy vergleichen: Der Scale-Plan kostet $699 pro Unternehmen und Monat mit unbegrenzt vielen Nutzern; siehe die Preisseite. Weitere Schritt-für-Schritt-Anleitungen finden Sie in den SF Guides.

FAQ

Verändert eine Validierung etwas in der Ziel-Org?

Nein. Es ist ein Check-only-Deployment, es werden keine Komponenten gespeichert.

Wie lange kann ich mit dem Quick Deploy warten?

Bis zu 10 Tage, sofern in der Zwischenzeit kein anderes Deployment und keine größere Änderung diese Org trifft.

Kann ich eine Validierung ohne Tests per Quick Deploy ausliefern?

Nein. Quick Deploy nutzt Testergebnisse wieder, daher muss die Validierung Tests ausführen und mit der erforderlichen Abdeckung bestehen.

Führt Quick Deploy die Apex-Tests erneut aus?

Nein. Es stützt sich auf die Tests aus der Validierung und ist deshalb schneller fertig als ein Standard-Deployment.