Comment passer des change sets à la gestion de source (étape par étape)

En bref : Pour passer des change sets à la gestion de source, récupérez les métadonnées de votre org dans un projet Salesforce DX, commitez-les dans un dépôt Git comme source unique de vérité, adoptez un modèle une branche par environnement et déployez via un pipeline automatisé plutôt qu'en cliquant des change sets d'org en org. Procédez par étapes : commencez par un projet, validez le flux, puis basculez le reste.

Pourquoi passer des change sets à la gestion de source ?

Les change sets sont un outil manuel d'org à org avec trois limites strictes : pas d'historique de version, pas de rollback et pas de piste d'audit. Chaque déploiement est une réécriture complète des métadonnées sans trace de ce qui a changé ni pourquoi, et ils ne circulent qu'entre des orgs partageant la même production. Salesforce recommande désormais aux équipes d'adopter des pratiques DevOps et de dépasser le modèle de release d'org à org.

La gestion de source corrige les trois. Git vous donne une source unique de vérité, un historique complet de chaque changement, du branching et du merging pour le travail parallèle, et la possibilité de revenir à un état sain connu en quelques minutes. C'est le socle sur lequel repose toute autre pratique DevOps.

Quand est-il temps de basculer ?

Envisagez le passage dès que l'un de ces points est vrai :

• Plus d'une personne effectue des changements en parallèle.
• Vous exploitez trois environnements ou plus.
• Vous livrez des releases fréquentes ou d'urgence.
• Vous avez des besoins de conformité - approbations, séparation des tâches, pistes d'audit.

Si deux ou plus s'appliquent, les change sets vous coûtent déjà plus qu'ils ne rapportent.

Comment passer des change sets à la gestion de source, étape par étape ?

1. Convertissez vos métadonnées au format source. Utilisez la Salesforce CLI pour récupérer les métadonnées dans un projet Salesforce DX (SFDX), afin que votre org soit décrite sous forme de fichiers plutôt qu'en instantané de change set.
2. Créez un dépôt Git. Commitez ce projet comme référence de départ - la première source unique de vérité de l'org.
3. Choisissez un modèle de branches. Le plus simple est une branche longue durée par environnement (par exemple dev, uat, main), avec des branches de fonctionnalité fusionnées via des pull requests.
4. Automatisez le déploiement. Câblez un pipeline qui déploie de chaque branche vers son environnement au merge, en exécutant validation et tests automatiquement au lieu de téléversements manuels de change sets.
5. Ajoutez tests et contrôles. Exigez que les tests Apex, la revue de code et la validation passent avant qu'un merge n'atteigne la production.
6. Retirez les change sets. Ne les gardez qu'en secours d'urgence une fois le pipeline éprouvé.

Vous n'êtes pas obligé de tout faire d'un coup. Commencez par un seul projet ou une seule équipe, validez le flux, puis basculez le reste de l'org.

De quels outils avez-vous besoin pour la bascule ?

Au minimum : un hébergeur Git (GitHub, GitLab ou Bitbucket), la Salesforce CLI et un projet Salesforce DX. Le DevOps Center gratuit de Salesforce ajoute gestion de source, work items et suivi des changements via une interface en pointer-cliquer, un solide premier pas pour les équipes low-code. Les équipes en croissance migrent en général vers une plateforme dédiée qui regroupe gestion de source, tests automatisés et rollback pour que les admins n'aient pas à vivre dans la CLI. Voyez comment les pièces s'assemblent dans notre bibliothèque SF Guides.

Pour le changement d'état d'esprit derrière la bascule, lisez le virage que vous ne pouvez plus ignorer, et quand vous êtes prêt à bâtir un flux de release reproductible, notre playbook des change sets à la livraison continue va plus loin.

Comment éviter les erreurs de migration courantes ?

• Ne récupérez pas tout d'un coup. Commencez par les métadonnées que votre équipe modifie activement, puis étendez.
• Surveillez les profils et les permission sets. Ce sont les métadonnées les plus délicates à versionner proprement, planifiez-les avec soin.
• Ne faites pas tourner change sets et Git en parallèle sur la durée. Deux sources de vérité anéantissent l'objectif.
• Embarquez les admins. La bascule échoue plus souvent sur la culture que sur l'outillage.

Quand vous êtes prêt à basculer sans la charge manuelle, notre guide de migration parcourt tout le chemin avec vous.

FAQ

Puis-je passer des change sets à Git sans écrire de code ?

En grande partie oui. Le DevOps Center et les plateformes tierces offrent une gestion de source en pointer-cliquer, même si quelqu'un exécute encore la récupération CLI initiale pour amorcer le dépôt.

Qu'est-ce qu'un projet Salesforce DX ?

C'est la représentation au format source des métadonnées de votre org sous forme de fichiers et dossiers, récupérée avec la Salesforce CLI, que Git suit et versionne ensuite.

Le DevOps Center remplace-t-il totalement les change sets ?

Pour beaucoup d'équipes, oui. Il ajoute gestion de version et suivi des changements au-dessus de Git, mais les équipes plus grandes ont souvent besoin des tests automatisés et du rollback qu'offrent les plateformes dédiées.

Combien de temps prend la migration ?

Un seul projet peut basculer en quelques jours. Une org complète multi-équipes est en général un déploiement par phases sur plusieurs semaines, environnement par environnement.