Aller au contenu
← Retour aux projets
Pipeline CI/CD — Déploiement Salesforce multi-environnements — image de couverture
Projet personnel

Pipeline CI/CD — Déploiement Salesforce multi-environnements

Branches Git, validation Apex automatisée et procédure de rollback documentée pour les releases Salesforce — pas une simple checklist de déploiement

Contexte

Salesforce n'a pas de story CI/CD native : les déploiements entre sandboxes et production se font soit via des Change Sets en point-and-click, soit via des scripts maison — et « ça marchait dans ma sandbox » est un mode d'échec classique. J'ai construit ce pipeline en projet personnel pour appliquer la discipline de release que j'appliquerais sur n'importe quelle plateforme — protection des branches, validation automatique à chaque Pull Request, promotion par étapes, procédure de rollback documentée — mais adaptée aux contraintes propres aux déploiements de métadonnées Salesforce : pas de rollback partiel, couverture de tests Apex obligatoire, métadonnées propres à chaque environnement.

Ce que j'ai mis en place

  • Stratégie de branches Git : feature → develop → main, avec protection des branches develop et main
  • Workflow GitHub Actions : validation Apex + tests automatiques à chaque Pull Request
  • Déploiement automatique dans la sandbox d'intégration au merge sur develop, puis dans la sandbox de recette (staging) au merge sur main
  • Mise en production par Quick Deploy, déclenchée manuellement après validation de la recette, en réutilisant la validation déjà exécutée contre la production
  • Gestion des credentials Salesforce via GitHub Secrets (SFDX Auth URL chiffrée)
  • Notifications de statut de déploiement intégrées à chaque étape du pipeline

Outils & Technologies

  • Salesforce CLI (SFDX) — packaging et déploiement des métadonnées
  • GitHub Actions — orchestration du pipeline CI/CD
  • GitHub Secrets — gestion sécurisée des credentials SFDX
  • Apex Test Run — exécution automatisée des tests unitaires
  • SFDX Source Format — versionning des métadonnées Salesforce

Étapes de mise en place

  1. 1
    Analyse
    Cartographie des environnements (Dev, Staging, Prod) et définition de la stratégie de branches adaptée au cycle de release Salesforce
  2. 2
    Configuration SFDX
    Initialisation du projet en SFDX Source Format, configuration des .forceignore et mise en place de l'authentification via SFDX Auth URL
  3. 3
    Pipeline CI
    Création des workflows GitHub Actions : job de validation Apex avec exécution des tests unitaires déclenchée à chaque Pull Request vers develop et vers main
  4. 4
    Pipeline CD
    Automatisation des déploiements : sandbox d'intégration au merge sur develop, sandbox de recette (staging) au merge sur main, accompagnée d'une validation à blanc contre la production — puis Quick Deploy en production, déclenché manuellement, qui réutilise ce test run validé plutôt que de relancer toute la suite
  5. 5
    Sécurisation
    Stockage des credentials SFDX Auth URL dans GitHub Secrets ; develop et main protégées par des contrôles de statut obligatoires (la validation CI doit passer avant tout merge)
  6. 6
    Procédure de rollback
    Les déploiements de métadonnées Salesforce n'ont pas d'annulation native. Procédure documentée : revert du commit de merge sur main, re-tag du dernier package validé, puis re-déploiement via le même pipeline CI — aussi long qu'un déploiement normal, par construction, faute de raccourci possible sur les métadonnées Salesforce

Décisions & Limites

  • Le Quick Deploy réutilise le test run déjà validé côté CI plutôt que de relancer toute la suite Apex — Salesforce l'autorise dans une fenêtre de validation de 10 jours, ce qui réduit chaque release de plusieurs minutes sans sacrifier la couverture
  • Aucun déclenchement automatique de rollback : le rollback reste la procédure manuelle documentée ci-dessus, pas un outil en un clic — un vrai outillage de rollback pour les métadonnées Salesforce serait un projet à part entière
  • La protection de branche repose sur des contrôles de statut obligatoires, pas sur une revue humaine imposée : sur un pipeline à une seule mainteneuse, GitHub ne permet pas d'approuver sa propre Pull Request — un relecteur obligatoire est la première règle que j'ajouterais avec une deuxième contributrice ou un deuxième contributeur
  • Aucun test de fumée post-déploiement : le pipeline valide avant de déployer, pas après — la première limite que je comblerais si ce pipeline devait servir une org de production réelle aujourd'hui

Résultats

3
Environnements couverts
Intégration, recette, production
> 75%
Couverture de tests
Apex — requis pour déploiement