Checklist click deploy : comment réussir un déploiement Salesforce en point-and-click

En bref : un click deploy déplace des métadonnées Salesforce d'une org à une autre en sélectionnant des composants dans une interface, au lieu de construire un change set ou de taper des commandes CLI. Pour le faire sans risque : comparez les orgs, ajoutez les dépendances, validez avec un niveau de test Apex choisi délibérément, puis lancez un quick deploy du package validé et vérifiez-le. La checklist complète suit.

Qu'est-ce qu'un click deploy dans Salesforce ?

« Click deploy » désigne le déploiement en point-and-click : un outil compare une org source et une org cible, affiche ce qui a changé et déploie les composants que vous cochez. Le nom vient de ClickDeploy, racheté par Copado en 2020 et vendu aujourd'hui sous le nom Copado Essentials ; nous détaillons son histoire et ses tarifs dans comment fonctionne ClickDeploy et combien il coûte. Copado Essentials, Gearset et les autres outils à base de clics transmettent tous le package final à la Metadata API de Salesforce : les règles de la plateforme s'appliquent quel que soit l'outil. C'est pourquoi cette checklist vaut partout.

Comment réussir un click deploy, étape par étape ?

1. Actualisez la comparaison. Comparez la source et la cible juste avant de déployer, pas la veille. Quelqu'un a pu modifier la cible entre-temps.
2. Sélectionnez le changement, puis ses dépendances. Un nouveau champ a besoin de son objet, et un Flow peut avoir besoin de champs, de classes Apex ou de permission sets. La plupart des outils signalent les dépendances manquantes ; fiez-vous à l'alerte, pas à votre mémoire.
3. Gardez le package léger. Ne livrez que ce qui a changé. Salesforce limite le .zip de déploiement à 39 Mo, comme le rappelle la documentation de Gearset, et un petit package se débogue plus facilement. Les déploiements delta en font la norme.
4. Planifiez les suppressions à part. Les suppressions passent par des manifestes destructive changes, que la CLI Salesforce applique avant ou après le déploiement. Choisissez l'ordre selon ce qui référence encore le composant.
5. Validez d'abord. Lancez une validation check-only. Elle exécute les tests Apex et signale les erreurs sans rien enregistrer dans l'org.
6. Choisissez le niveau de test délibérément. La valeur par défaut n'est pas toujours la bonne ; voir la section suivante.
7. Lancez un quick deploy du package validé. En production, une validation réussie peut être déployée plus tard sans relancer les tests Apex. D'après la référence de la CLI, l'ID du job reste valable 10 jours à partir du début de la validation : vous pouvez valider l'après-midi et livrer dans un créneau calme.
8. Vérifiez et documentez. Ouvrez les pages modifiées, faites un smoke test rapide et notez précisément ce qui a été livré, pour qu'un rollback ait un point de retour.

Quel niveau de test Apex choisir ?

La CLI Salesforce documente cinq niveaux de test, et la plupart des outils à clics affichent la même liste sous des noms plus parlants :

• NoTestRun : aucun test. Autorisé uniquement pour les environnements de développement comme les sandboxes, les orgs Developer Edition et d'essai.
• RunSpecifiedTests : seulement les tests que vous nommez. Le guide de Gearset précise que chaque classe ou trigger du package doit alors atteindre seul 75 % de couverture.
• RunLocalTests : tous les tests sauf ceux des packages managés et unlocked installés. C'est le niveau par défaut des déploiements en production qui contiennent des classes ou triggers Apex.
• RunAllTestsInOrg : tout, y compris les tests des packages managés.
• RunRelevantTests (bêta) : Salesforce choisit les tests en analysant le package et ses dépendances. Nécessite l'API version 66 ou ultérieure.

Prudence avec RunRelevantTests en production. Les tests de Bob Buzzard sur Spring '26 ont montré qu'il retenait les tests liés directement au code modifié, mais manquait les chaînes indirectes et les classes instanciées dynamiquement. Marquez les tests indispensables avec @IsTest(critical=true) avant de vous y fier.

Quand le click deploy est-il le mauvais outil ?

• Plusieurs personnes livrent dans la même org. Les déploiements d'org à org ne gardent aucun historique partagé : le second déploiement peut écraser le premier.
• Vous avez besoin d'un rollback fiable. Revenir en arrière est plus simple quand chaque release a été commitée avant sa livraison.
• Vous livrez un package managé. Les ISV publient des versions de package pour leurs abonnés, pas des différences entre orgs ; voir les packages managés de deuxième génération.

Abandonner le déploiement d'org à org ne veut pas dire abandonner les clics. Les admins peuvent continuer à sélectionner leurs changements dans une interface pendant que l'outil écrit les commits Git, comme nous le montrons dans le DevOps pour admins sans toucher à Git.

Comment Tekunda aborde-t-il le déploiement par clics ?

Tekunda est la société de conseil et de produits Salesforce derrière Serpent, la plateforme DevOps qu'elle utilise aussi pour ses propres livraisons clients. Serpent conserve l'expérience de sélection par clics : vous choisissez vos changements, les rattachez à un ticket et les promouvez dans votre pipeline, pendant que Git, les pull requests, la validation et les tests Apex tournent en arrière-plan, avec une revue de code IA sur chaque offre. Rien n'est installé dans votre org et vous démarrez gratuitement, avec un prix d'équipe fixe sur notre page de tarifs. D'autres guides pas à pas vous attendent dans la bibliothèque SF Guides.

FAQ

Un click deploy est-il la même chose qu'un change set ?

Non. Les deux déplacent des métadonnées entre orgs, mais un outil à clics construit le package à partir d'une comparaison d'orgs au lieu que vous ajoutiez les composants un par un à un change set.

Combien de temps puis-je attendre entre validation et quick deploy ?

Jusqu'à 10 jours à partir du début de la validation, selon la référence de la CLI Salesforce.

Les déploiements en sandbox exécutent-ils les tests Apex ?

Pas par défaut. Le niveau par défaut de Salesforce n'exécute aucun test en sandbox, alors que les déploiements en production contenant des classes ou triggers Apex exécutent les tests locaux.

Peut-on faire un click deploy gratuitement ?

Oui. Copado Essentials propose une offre gratuite jusqu'à 15 déploiements par mois pour un utilisateur, et Serpent propose aussi un plan gratuit.