Comment Configurer un Pipeline CI/CD Salesforce avec GitHub Actions

Pour configurer un pipeline CI/CD Salesforce avec GitHub Actions, vous stockez votre metadata dans Git en source format, vous authentifiez GitHub auprès de votre org via une Connected App basée sur JWT, et vous ajoutez un workflow qui valide les changements à chaque pull request et les déploie au merge. Tout le pipeline tient dans un seul fichier YAML sous .github/workflows et tourne sur le Salesforce CLI. Ce guide déroule la méthode actuelle, en sf v2, puis signale les parties qui cassent discrètement en production. Il fait partie de notre bibliothèque SF Guides sur /serpent/resources.

De quoi avez-vous besoin avant de commencer ?

Un pipeline qui marche suppose que quelques éléments sont déjà en place :

• Projet en source format. Votre metadata vit sous force-app en source format, committée dans un dépôt GitHub.
• Salesforce CLI v2 (sf). L'ancien CLI sfdx est déprécié, alors bâtissez sur sf.
• Une cible de déploiement. Une sandbox pour la validation et un org de production ou de staging pour la release.
• Une Connected App dans l'org cible avec les signatures numériques activées, plus un utilisateur d'intégration préautorisé.

Si votre metadata n'est pas encore dans Git, cette migration passe d'abord. Nous couvrons la mécanique de branching et d'environnements dans notre guide complémentaire pour construire un pipeline CI/CD Salesforce avec GitHub Actions.

Comment relier GitHub Actions à Salesforce en toute sécurité ?

Utilisez le JWT Bearer Flow. Il est headless, ne nécessite aucune connexion interactive, et c'est ce que Salesforce recommande pour la CI. Générez une paire de clés, téléversez le certificat dans une Connected App, puis connectez-vous depuis le runner avec la clé privée.

1. Créez la clé et le certificat : openssl genrsa -out server.key 2048 puis openssl req -new -x509 -nodes -sha256 -days 365 -key server.key -out server.crt.
2. Créez une Connected App dans l'org, activez Use digital signatures et téléversez server.crt.
3. Stockez server.key ainsi que votre consumer key, votre nom d'utilisateur et l'instance URL comme secrets du dépôt GitHub, jamais dans le YAML.
4. Authentifiez-vous sur le runner : sf org login jwt --client-id $SF_CONSUMER_KEY --jwt-key-file server.key --username $SF_USERNAME --instance-url $SF_INSTANCE_URL --set-default-org.

À quoi ressemble le workflow GitHub Actions ?

Le schéma central est un seul workflow avec deux comportements, selon l'événement. Validez sur une pull request pour que rien qui échouerait ne soit mergé ; déployez pour de vrai quand le changement atterrit sur votre branche main.

• Déclencheurs : pull_request contre main pour la validation, push vers main pour le déploiement.
• Étape de validation (PR) : sf project deploy validate --source-dir force-app --test-level RunLocalTests --wait 30 --verbose. C'est un run check-only, donc rien n'est écrit dans l'org.
• Étape de déploiement (merge) : sf project deploy start --source-dir force-app --test-level RunLocalTests --wait 30 --verbose.

Utilisez une condition if: sur chaque job pour que le même fichier gère les deux événements. Lancer les tests locaux à la validation est ce qui en fait une vraie barrière plutôt qu'un tampon, et c'est l'ossature de tout pipeline d'automatisation des tests Salesforce en CI sérieux.

Comment déployer uniquement ce qui a changé ?

Déployer tout le répertoire force-app à chaque fois est lent et empire à mesure que le dépôt grossit. L'outil communautaire sfdx-git-delta calcule la différence entre deux commits et produit un package contenant uniquement la metadata modifiée :

sf sgd source delta --to HEAD --from HEAD~1 --output delta --generate-delta --source-dir force-app

Vous pointez ensuite la commande de déploiement vers le répertoire delta. Cela réduit fortement le temps de déploiement, mais lisez la section suivante avant de lui faire aveuglément confiance.

Qu'est-ce qui casse discrètement un pipeline fait main ?

La plupart des tutoriels s'arrêtent à un déploiement vert. Les échecs surgissent plus tard, et ils sont la raison pour laquelle nous construisons de l'outillage autour plutôt que de laisser aux équipes un YAML brut :

• Les suppressions. Un delta naïf déploie les ajouts et les modifications mais ne retire pas les composants supprimés. Il vous faut une étape destructive-changes, sinon la metadata dérive et les composants obsolètes s'accumulent.
• La metadata partielle. Les profiles, permission sets et quelques autres types vivent encore dans de gros fichiers partagés qui ne se diffent pas proprement, donc les déploiements delta peuvent les manquer ou les écraser.
• La maintenance est à vous. Chaque changement de CLI, chaque nouveau type de metadata et chaque cas limite est désormais le YAML de votre équipe à réparer. Ce coût s'accumule, et c'est exactement ce que la back-promotion entre environnements aggrave si vous la scriptez à la main.

Si vous préférez ne pas posséder ce pipeline à vie, une plateforme managée gère le delta, les destructive changes et les bords de metadata partielle à votre place. Voyez ce que Serpent couvre et son tarif avant d'engager un trimestre de temps d'ingénierie dans un pipeline maison.

FAQ

Dois-je utiliser sfdx ou sf pour un pipeline Salesforce GitHub Actions ?

Utilisez sf (Salesforce CLI v2). L'ancien CLI sfdx est déprécié et ne devrait pas être la base d'un nouveau pipeline.

Pourquoi l'auth JWT plutôt qu'un nom d'utilisateur et un mot de passe ?

Le JWT Bearer Flow est headless et ne nécessite aucune connexion interactive ni invite MFA, ce qu'exige un runner CI, et Salesforce le recommande pour l'automatisation.

Quelle est la différence entre deploy validate et deploy start ?

Validate est un run check-only qui vérifie et lance les tests sans modifier l'org, idéal sur les pull requests ; start effectue le déploiement réel au merge.

Ai-je besoin de sfdx-git-delta ?

Non, mais il en vaut la peine dès que les déploiements deviennent lents. Associez-le simplement à une étape destructive-changes pour que les suppressions soient gérées et non silencieusement ignorées.