Valider un click deploy : déploiement check-only et Quick Deploy

En bref : la validation d'un click deploy est un déploiement check-only : Salesforce exécute votre package et ses tests Apex sur l'org cible sans rien enregistrer. Si elle réussit avec des tests exécutés, vous obtenez un job ID qui permet un Quick Deploy dans les 10 jours, sans relancer les tests pendant votre fenêtre de release. Validez tôt, puis livrez sans attendre les tests deux fois.

Qu'est-ce que la validation d'un click deploy ?

Valider un déploiement, c'est l'exécuter en mode check-only. Le module Trailhead sur les releases de Salesforce le décrit comme l'exécution des tests pour valider le déploiement sans enregistrer les composants dans l'org cible. Rien ne change dans l'org. Vous apprenez si le package se déploierait et si les tests passent. Dans un outil point-and-click, c'est généralement un bouton Validate à côté de Deploy.

Trailhead définit aussi la réussite : tous les tests Apex ont réussi et ils couvrent au moins 75 % du code déployé.

Pourquoi valider avant un click deploy ?

• Les erreurs apparaissent tôt. Dépendances manquantes, erreurs de compilation et tests en échec ressortent comme un résultat à corriger, pas comme une release cassée.
• La partie lente sort de la fenêtre de release. Quick Deploy réutilise les résultats de tests de la validation, donc l'étape de production ne relance pas les tests Apex.
• Les approbateurs disposent d'une preuve. Une validation réussie se vérifie avant la signature, et c'est la première gate de notre checklist click deploy.

Comment lancer une validation puis un Quick Deploy ?

1. Construisez le package depuis une source fiable. Une comparaison d'orgs fonctionne, mais une branche se revoit plus facilement. Voir click deploy depuis Git pour cette approche.
2. Choisissez un niveau de test qui exécute vraiment des tests. La section suivante précise lesquels conviennent.
3. Lancez Validate. Depuis la CLI, c'est sf project deploy validate. Gearset et Salto proposent la validation dans leurs flux de déploiement, et Salto demande quels tests exécuter à cette occasion.
4. Lisez le résultat et revalidez après chaque correction. Une validation ne garantit que le package exact qu'elle a vérifié.
5. Conservez le job ID. Trailhead précise que la validation renvoie un job ID à référencer lors du quick deploy.
6. Lancez le Quick Deploy dans la fenêtre. Utilisez le bouton Quick Deploy de la page Deployment Status dans Setup (il n'apparaît que pour les validations éligibles), sf project deploy quick avec le job ID, ou l'appel Metadata API deployRecentValidation().
7. Prévoyez un retour arrière. Une validation propre réduit le risque sans le supprimer : préparez votre rollback de click deploy avant de livrer.

Avec quel niveau de test valider ?

• RunLocalTests : exécute les tests locaux de l'org. L'exemple de release de Trailhead l'utilise pour la validation en staging comme en production.
• RunSpecifiedTests : n'exécute que les classes que vous désignez. Plus rapide, mais ces tests doivent assurer la couverture de ce que vous déployez, soit, selon Apex Anvil, 75 % pour chaque classe et trigger déployés.
• RunAllTestsInOrg : exécute tous les tests de l'org, y compris ceux des packages managés. L'option la plus lente.
• NoTestRun : incompatible avec Quick Deploy, faute de résultats de tests à réutiliser.
• RunRelevantTests : introduit en bêta avec Spring '26. Salesforce sélectionne les tests liés à l'Apex du package, mais Bob Buzzard a constaté qu'il ne suit que les dépendances directes : testez-le d'abord hors production.

Qu'est-ce qui invalide une validation ?

• L'âge. Le job ID est valable 10 jours. Au-delà, il faut revalider.
• Un autre déploiement. La fenêtre de 10 jours décrite par Trailhead ne tient que si personne ne déploie sur cette org ni n'y apporte de changements majeurs entre-temps.
• Une dérive passée inaperçue. La documentation de Gearset avertit que les changements faits dans les orgs après la création d'un package ne sont pas pris en compte et peuvent être écrasés au déploiement.
• L'absence de tests. Une validation lancée avec NoTestRun ne peut pas passer en Quick Deploy.

La règle pratique : validez aussi près de la release que la durée de vos tests le permet, et gelez les autres déploiements vers cette org jusqu'à la livraison.

Qui est Tekunda, et comment Serpent gère-t-il la validation ?

Tekunda est une société de conseil et de produits Salesforce, et l'entreprise derrière Serpent, la plateforme DevOps Salesforce lancée en 2024. Dans Serpent, la validation est une étape fixe et non un bouton optionnel : le flux de déploiement enchaîne configuration, sélection des fichiers, validation et déploiement. L'étape de validation est un dry run sur l'org cible. Un résultat propre continue automatiquement, un échec s'arrête là. Serpent ne déploie en outre que les composants modifiés par un work item, ce qui garde les validations légères. Si vous le comparez à fonctionnement et coût de ClickDeploy, le plan Scale coûte 699 $ par entreprise et par mois avec un nombre illimité d'utilisateurs ; voir la page des tarifs. D'autres guides pas à pas se trouvent dans SF Guides.

FAQ

Une validation modifie-t-elle quelque chose dans l'org cible ?

Non. C'est un déploiement check-only : aucun composant n'est enregistré.

Combien de temps peut-on attendre avant un Quick Deploy ?

Jusqu'à 10 jours, à condition qu'aucun autre déploiement ni changement majeur ne touche cette org entre-temps.

Peut-on faire un Quick Deploy d'une validation sans tests ?

Non. Quick Deploy réutilise les résultats de tests : la validation doit exécuter des tests et réussir avec la couverture requise.

Quick Deploy relance-t-il les tests Apex ?

Non. Il s'appuie sur les tests de la validation, c'est pourquoi il se termine plus vite qu'un déploiement standard.