Click deploy depuis Git : déployer des changements Salesforce depuis une branche

En bref : un click deploy depuis Git utilise une branche de dépôt, et non une sandbox, comme source d'un déploiement Salesforce par clics. Les outils proposent en général quatre modes : composants sélectionnés, branche entière, différences entre deux branches, ou tout ce qui a été commité depuis le dernier build réussi. Pour les releases d'équipe, déployez les différences entre branches, validez d'abord et faites passer les suppressions par une pull request.

Qu'est-ce qu'un click deploy depuis Git ?

Un click deploy classique compare deux orgs et livre les composants que vous cochez, comme nous l'expliquons dans comment fonctionne ClickDeploy et combien il coûte. Un click deploy basé sur Git garde la même interface mais change de source : l'outil lit les métadonnées d'une branche d'un dépôt comme GitHub, GitLab, Bitbucket ou Azure DevOps et les déploie vers l'org cible. Vous cliquez toujours. La différence, c'est que chaque changement a été commité avant d'être livré.

Pourquoi déployer depuis une branche plutôt que depuis une org ?

• Un historique partagé. Les déploiements d'org à org ne gardent aucune trace de qui a changé quoi, donc un second déploiement peut écraser le premier sans bruit. Une branche conserve chaque changement et son auteur.
• Une revue avant la release. Les changements peuvent passer par une pull request avant d'atteindre une org.
• Une source de vérité connue. La branche associée à la production montre ce que la production doit contenir, et c'est ce qui rend un rollback fiable.

Attendez-vous à un peu de bruit. La documentation de Gearset rappelle que les orgs changent sans cesse sous l'effet des jobs automatisés, des mises à niveau de la plateforme et de l'activité des utilisateurs, que la Metadata API réordonne le XML de certains types de composants, et que les métadonnées de profil dépendent de ce qui est récupéré avec elles. Elle recommande de suivre les types de métadonnées souvent modifiés et à fort impact plutôt que tout.

Quelles sont les options de source Git pour un click deploy ?

Copado Essentials, l'outil anciennement appelé ClickDeploy, documente quatre options de source Git, qui s'appliquent bien à d'autres outils :

1. Composants sélectionnés dans une branche. Fonctionne comme un déploiement d'org à org : vous choisissez les composants de la branche à la main. Idéal pour un correctif ciblé.
2. Toute la branche. Déploie tout le contenu de la branche d'un coup. Adapté à un environnement neuf ou reconstruit ; vers la production, il livre bien plus que le changement.
3. Différences entre deux branches. Compare une branche source à une branche de comparaison et ne déploie que ce qui diffère. Copado conseille de prendre comme branche de comparaison celle associée à l'org cible.
4. Build incrémental. Un job CI ne déploie que les fichiers commités depuis le dernier build réussi, suivis par un marqueur de build qui avance après chaque déploiement réussi. Un job CI de validation seule ne déplace pas le marqueur, même s'il réussit.

L'option trois est la forme native Git des déploiements delta, et c'est le bon choix par défaut pour promouvoir une fonctionnalité d'une branche d'environnement à la suivante.

Comment faire un click deploy depuis une branche Git, étape par étape ?

1. Connectez le dépôt et l'org cible. Autorisez les deux dans votre outil et gardez le dépôt dans un seul format de métadonnées. Gearset note que les dépôts au format Metadata API et au format DX sont structurés différemment.
2. Associez les branches aux environnements. Décidez quelle branche représente chaque org, par exemple une pour l'UAT et main pour la production. Une comparaison de branches ne vaut que ce que vaut cette association.
3. Choisissez les branches source et de comparaison. Prenez la branche de fonctionnalité ou de release comme source, et la branche associée à l'org cible comme comparaison.
4. Relisez le diff. Lisez ce que l'outil prévoit de déployer. S'il manque des métadonnées attendues, cherchez un package.xml : Gearset filtre les comparaisons par un fichier valide par défaut.
5. Traitez les suppressions délibérément. Dans Copado Essentials, marquer des composants à supprimer dans un flux Git les retire d'abord de la branche : vous commitez le changement et le fusionnez par pull request avant que l'org ne change.
6. Validez, puis déployez. Lancez une validation sans enregistrement avec un niveau de tests Apex choisi, puis déployez. Notre checklist du click deploy couvre les niveaux de tests et le quick deploy.
7. Fusionnez en retour. Après un déploiement réussi, fusionnez la source dans la branche de comparaison pour que la branche corresponde à nouveau à l'org.

Quels outils permettent le click deploy depuis Git, et à quel prix ?

• Copado Essentials : l'intégration Git avec GitHub, Bitbucket, GitLab et Azure DevOps fait partie d'Essentials Plus, à 249 $ par utilisateur et par mois en facturation annuelle ou 289 $ au mois, avec un essai de 21 jours, selon sa page tarifs. Les offres Free et Basic ne mentionnent pas l'intégration Git.
• Gearset : sa page Compare and deploy accepte une branche de source control comme source ou comme cible, selon son centre d'aide.
• DevOps Center : l'option native de Salesforce, par clics et adossée à Git. Salesforce Ben indique que la nouvelle génération tourne nativement dans les orgs de production depuis Spring '26, prend en charge GitHub et Bitbucket, et expose ses opérations via le serveur MCP officiel de Salesforce.
• La voie CLI : les équipes à l'aise avec le terminal utilisent le plugin communautaire sfdx-git-delta, dont la commande sf sgd source delta génère un package.xml et un destructiveChanges.xml à partir de deux commits. Ses mainteneurs précisent qu'il ne s'agit pas d'un outil officiellement pris en charge par Salesforce.

La tarification par utilisateur grimpe vite dès que Git entre en jeu : cinq personnes sur Essentials Plus reviennent à 1 245 $ par mois en facturation annuelle.

Comment Tekunda gère-t-il le click deploy depuis Git ?

Tekunda est la société de conseil et de produits Salesforce derrière Serpent, la plateforme DevOps qu'elle utilise aussi pour ses propres projets clients. Dans Serpent, les admins continuent de cliquer : ils choisissent les changements dans une interface, les rattachent à un ticket et les font avancer dans le pipeline, tandis que les commits Git, les pull requests et les tests Apex tournent en arrière-plan. Nous détaillons ce flux dans le DevOps pour admins sans toucher à Git. Serpent facture par entreprise et non par utilisateur : comparez-le aux outils facturés au siège sur notre page tarifs, et les équipes qui quittent Copado Essentials peuvent suivre le parcours de migration. D'autres guides pratiques vous attendent dans la bibliothèque SF Guides.

FAQ

Puis-je faire un click deploy de GitHub vers Salesforce sans CLI ?

Oui. Copado Essentials Plus, Gearset et DevOps Center déploient tous depuis une branche Git via une interface par clics.

Quelle différence entre un déploiement de branche et un déploiement delta ?

Un déploiement de branche livre tout le contenu de la branche. Un déploiement delta ne livre que ce qui diffère entre deux branches ou deux commits.

Un click deploy depuis Git supprime-t-il des métadonnées ?

Seulement si vous le demandez. Les suppressions passent par des destructive changes et, dans Copado Essentials, elles sont d'abord commitées puis fusionnées par pull request.

Pourquoi ma branche diffère-t-elle de mon org juste après la configuration ?

Les orgs changent en permanence, et la Metadata API peut réordonner le XML ou renvoyer un contenu de profil différent, donc une certaine dérive est normale.