Déployer en production est l'un des moments les plus risqués dans tout projet Salesforce. Choisir le mauvais outil — ou utiliser le bon outil incorrectement — mène à des métadonnées manquantes, des dépendances cassées et des rollbacks d'urgence. Voici une comparaison pratique des trois options principales.
Les trois méthodes en un coup d'œil
| Méthode | Idéal pour | Courbe d'apprentissage | Prêt CI/CD | |---------|-----------|------------------------|------------| | Change Sets | Petites orgs, déploiements occasionnels | Faible | ❌ | | Salesforce CLI (SFDX) | Développeurs, automatisation | Moyenne | ✅ | | DevOps Center | Équipes, pipelines, sans code | Faible–Moyenne | ✅ |
Change Sets — Simple mais limité
Les Change Sets sont l'outil de déploiement natif de Salesforce, accessible directement depuis Setup. Vous sélectionnez les composants à déployer, vous les ajoutez à un outbound change set, et vous les déployez vers une org cible connectée.
Quand les utiliser :
- Petites équipes sans processus CI/CD formel
- Déploiements ponctuels de 5 à 20 composants
- Environnements où le CLI n'est pas autorisé
Limites critiques :
- Aucune gestion de version (pas de Git)
- Pas de déploiement automatisable (zéro scripting)
- Pas de rollback automatique
- Dépendances non résolues automatiquement → erreurs de déploiement fréquentes
# Pas de CLI pour les Change Sets — tout se fait dans l'interface Salesforce
# Setup → Deploy → Outbound Change Sets → NewSalesforce CLI (SFDX) — La force des développeurs
La Salesforce CLI transforme le déploiement en commandes scriptables et intégrables dans n'importe quel pipeline CI/CD.
Installation et initialisation :
# Installation (macOS/Linux)
npm install -g @salesforce/cli
# Authentification à une org
sf org login web --alias mon-org-prod
# Récupérer les métadonnées localement
sf project retrieve start \
--metadata ApexClass,CustomObject,Layout \
--target-org mon-org-dev
# Déployer avec validation des tests
sf project deploy start \
--source-dir force-app \
--target-org mon-org-prod \
--test-level RunLocalTests \
--dry-run # validation sans déploiement effectifDéploiement depuis un pipeline GitHub Actions :
# .github/workflows/deploy-prod.yml
name: Deploy to Production
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Salesforce CLI
run: npm install -g @salesforce/cli
- name: Authenticate Production Org
run: |
echo "${{ secrets.SF_AUTH_URL }}" > auth.txt
sf org login sfdx-url --sfdx-url-file auth.txt --alias prod
- name: Run Tests & Deploy
run: |
sf project deploy start \
--source-dir force-app \
--target-org prod \
--test-level RunLocalTests \
--wait 30DevOps Center — Le pipeline sans code
DevOps Center est la réponse de Salesforce aux équipes qui veulent du CI/CD sans maîtriser le CLI. Il s'intègre nativement avec GitHub et offre une interface graphique pour gérer les pipelines.
Quand l'utiliser :
- Équipes mixtes (admins + développeurs)
- Projets où vous voulez Git sans apprendre le CLI
- Organisations qui standardisent sur l'écosystème Salesforce
Flux typique :
- Créer un Work Item dans DevOps Center
- Associer les modifications à ce Work Item
- Promouvoir vers l'environnement suivant (Dev → UAT → Prod)
- DevOps Center gère les commits Git automatiquement
Quelle méthode choisir ?
Équipe de 1-2 personnes, pas de Git ?
→ Change Sets
Développeur solo ou petite équipe technique ?
→ Salesforce CLI + pipeline simple
Équipe mixte admins/devs, besoin de gouvernance ?
→ DevOps Center
Grande organisation avec CI/CD existant (Jenkins, GitHub Actions) ?
→ Salesforce CLI intégré au pipeline d'entreprise
Pièges courants
- Déployer sans valider : toujours utiliser
--dry-runavant un déploiement en production - Oublier les tests : ne jamais déployer avec
--test-level NoTestRunen production - Change Sets pour des projets complexes : les dépendances non résolues causent des erreurs en cascade
- Ignorer le
.forceignore: comme.gitignore, il exclut les fichiers non pertinents du déploiement
Récapitulatif
| Critère | Change Sets | CLI | DevOps Center | |---------|------------|-----|---------------| | Git natif | ❌ | ✅ | ✅ | | Automatisable | ❌ | ✅ | Partiel | | Adapté aux admins | ✅ | ❌ | ✅ | | Rollback | Manuel | Manuel | Via Git | | Coût | Inclus | Inclus | Inclus |
