Comment passer des change sets au contrôle de source dans Salesforce

En bref : Pour passer des change sets au contrôle de source, placez les métadonnées de votre org dans un dépôt Git, adoptez un environnement de développement suivi, et déployez via un pipeline au lieu de choisir des composants à la main. Faites-le par étapes : activez le source tracking, pilotez une équipe sur Git avec un pipeline en validation seule, puis retirez les change sets périmètre par périmètre.

Salesforce recommande désormais aux clients de dépasser le modèle de release org à org, et la plupart des guides expliquent pourquoi les change sets ne suffisent pas. Peu vous donnent le vrai chemin de migration. Ce guide est ce chemin : un playbook reproductible que vous pouvez exécuter sans geler la livraison.

Que signifie passer des change sets au contrôle de source ?

Cela signifie sortir la source de vérité de vos métadonnées de l'org pour la placer dans un système de contrôle de version, généralement Git. Les change sets copient des composants d'org à org et ne laissent aucun historique. Le contrôle de source stocke chaque layout, flow, permission set et classe Apex sous forme de fichiers versionnés, de sorte que vous pouvez brancher, relire, déployer et revenir en arrière. L'org devient une cible de déploiement plutôt que l'enregistrement maître.

Pourquoi quitter les change sets ?

Les change sets sont un bon point de départ et restent utiles pour de petites équipes. Ils atteignent une limite avec la croissance :

• Pas de contrôle de version ni d'historique de qui a changé quoi.
• Pas de rollback automatique si un déploiement tourne mal.
• Pas de revue de code avant que les changements n'arrivent.
• Sélection manuelle de chaque composant, lente et sujette aux erreurs.
• Types de métadonnées non pris en charge et téléversements immuables, non modifiables.

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 migrer des change sets vers le contrôle de source ?

Exécutez ces étapes dans l'ordre. L'objectif est un pipeline fonctionnel pour un périmètre avant d'étendre.

1. Créez le dépôt. Montez un dépôt Git et convenez d'un modèle de branches que votre équipe comprend.
2. Activez le source tracking en production. Les nouvelles sandboxes Developer et Developer Pro en héritent alors, ce qui rend possible la capture automatique des changements.
3. Établissez une baseline. Récupérez les métadonnées de votre org avec la Salesforce CLI et validez-les comme premier instantané de vérité.
4. Convertissez au format source. Utilisez la CLI pour découper les gros fichiers de métadonnées en fichiers source plus petits et fusionnables qui réduisent les conflits.
5. Pilotez une équipe. Déplacez une seule équipe ou un projet vers des branches de fonctionnalité et un déploiement en validation seule pendant que les autres continuent avec les change sets.
6. Ajoutez l'intégration continue. Câblez un pipeline qui valide chaque pull request et déploie la source fusionnée vers l'environnement suivant.
7. Retirez les change sets par périmètre. Une fois le premier pipeline éprouvé, coupez les change sets pour ce périmètre et recommencez pour l'équipe suivante.

Change sets contre contrôle de source : qu'est-ce qui change vraiment ?

• Source de vérité : l'org devient une cible de déploiement ; le dépôt détient la référence.
• Capture des changements : le cochage manuel devient un source tracking automatique.
• Revue : pas de revue devient des pull requests.
• Déploiement : les clics manuels deviennent un pipeline reproductible.
• Récupération : pas de rollback devient revenir-et-redéployer depuis l'historique.

Quels outils utiliser ?

La base gratuite vient de Salesforce : la Salesforce CLI, Salesforce DX et DevOps Center, qui remplace les change sets par une interface basée sur Git et s'intègre à GitHub et Bitbucket. Quand vous avez besoin de pipelines gérés, de sauvegardes, de diffs conscients des métadonnées et de contrôles qualité, des plateformes comme Serpent, Copado, Gearset, AutoRABIT, Flosum, Salto et Blue Canvas s'appuient sur la même fondation Git. Commencez gratuitement, puis adoptez une plateforme quand le processus, pas l'outillage, est votre goulet. Nous détaillons ce parcours de migration sur change sets versus Serpent. Pour d'autres guides Salesforce DevOps, voyez les guides Serpent.

Pour le changement d'état d'esprit derrière ce passage, 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 ?

N'essayez pas une bascule d'un coup. Migrez un périmètre à la fois et gardez les change sets en parallèle jusqu'à ce que chaque pipeline soit éprouvé. Activez le source tracking avant de construire, pas après, sinon vos premières sandboxes ne captureront pas les changements. Et faites la baseline de toute l'org avant que quiconque n'ouvre une branche, pour que votre dépôt reflète la production dès le premier jour au lieu de s'en écarter.

Planifiez les profiles et les permission sets avec soin : ce sont les métadonnées les plus délicates à versionner proprement. Gardez la période en parallèle courte, car deux sources de vérité sur la durée anéantissent l'objectif. Et embarquez les admins dès le départ : la bascule échoue plus souvent sur la culture que sur l'outillage.

FAQ

Dois-je arrêter d'utiliser les change sets immédiatement ?

Non. Migrez périmètre par périmètre et gardez les change sets pour les équipes non encore migrées, ainsi la livraison ne gèle jamais.

Quels environnements prennent en charge le source tracking ?

Les scratch orgs et les sandboxes Developer et Developer Pro le prennent en charge ; les sandboxes Partial Copy et Full non.

DevOps Center suffit-il, ou faut-il un outil payant ?

DevOps Center est un point de départ gratuit basé sur Git. Ajoutez une plateforme commerciale quand vous avez besoin de pipelines gérés, de sauvegardes ou de contrôles qualité avancés.

Comment faire la baseline d'une org existante ?

Récupérez les métadonnées de l'org avec la Salesforce CLI, convertissez-les au format source et validez-les comme première version de votre dépôt.

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

Oui. Serpent donne aux admins un contrôle de source en pointer-cliquer sur Git, et notre équipe amorce le dépôt avec vous, comme nous le montrons dans change sets versus Serpent.