Comment passer des change sets au controle de source dans Salesforce

En bref : Pour passer des change sets au controle de source, placez les metadonnees de votre org dans un depot Git, adoptez un environnement de developpement suivi, et deployez via un pipeline au lieu de choisir des composants a la main. Faites-le par etapes : activez le source tracking, pilotez une equipe sur Git avec un pipeline en validation seule, puis retirez les change sets perimetre par perimetre.

Salesforce recommande desormais aux clients de depasser le modele de release org a 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 executer sans geler la livraison.

Que signifie passer des change sets au controle de source ?

Cela signifie sortir la source de verite de vos metadonnees de l'org pour la placer dans un systeme de controle de version, generalement Git. Les change sets copient des composants d'org a org et ne laissent aucun historique. Le controle de source stocke chaque layout, flow, permission set et classe Apex sous forme de fichiers versionnes, de sorte que vous pouvez brancher, relire, deployer et revenir en arriere. L'org devient une cible de deploiement plutot que l'enregistrement maitre.

Pourquoi quitter les change sets ?

Les change sets sont un bon point de depart et restent utiles pour de petites equipes. Ils atteignent une limite avec la croissance :

• Pas de controle de version ni d'historique de qui a change quoi.
• Pas de rollback automatique si un deploiement tourne mal.
• Pas de revue de code avant que les changements n'arrivent.
• Selection manuelle de chaque composant, lente et sujette aux erreurs.
• Types de metadonnees non pris en charge et televersements immuables, non modifiables.

Comment migrer des change sets vers le controle de source ?

Executez ces etapes dans l'ordre. L'objectif est un pipeline fonctionnel pour un perimetre avant d'etendre.

1. Creez le depot. Montez un depot Git et convenez d'un modele de branches que votre equipe comprend.
2. Activez le source tracking en production. Les nouvelles sandboxes Developer et Developer Pro en heritent alors, ce qui rend possible la capture automatique des changements.
3. Etablissez une baseline. Recuperez les metadonnees de votre org avec la Salesforce CLI et validez-les comme premier instantane de verite.
4. Convertissez au format source. Utilisez la CLI pour decouper les gros fichiers de metadonnees en fichiers source plus petits et fusionnables qui reduisent les conflits.
5. Pilotez une equipe. Deplacez une seule equipe ou un projet vers des branches de fonctionnalite et un deploiement en validation seule pendant que les autres continuent avec les change sets.
6. Ajoutez l'integration continue. Cablez un pipeline qui valide chaque pull request et deploie la source fusionnee vers l'environnement suivant.
7. Retirez les change sets par perimetre. Une fois le premier pipeline eprouve, coupez les change sets pour ce perimetre et recommencez pour l'equipe suivante.

Change sets contre controle de source : qu'est-ce qui change vraiment ?

• Source de verite : l'org devient une cible de deploiement ; le depot detient la reference.
• Capture des changements : le cochage manuel devient un source tracking automatique.
• Revue : pas de revue devient des pull requests.
• Deploiement : les clics manuels deviennent un pipeline reproductible.
• Recuperation : pas de rollback devient revenir-et-redeployer 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 basee sur Git et s'integre a GitHub et Bitbucket. Quand vous avez besoin de pipelines geres, de sauvegardes, de diffs conscients des metadonnees et de controles qualite, des plateformes comme Serpent, Copado, Gearset, AutoRABIT, Flosum, Salto et Blue Canvas s'appuient sur la meme fondation Git. Commencez gratuitement, puis adoptez une plateforme quand le processus, pas l'outillage, est votre goulet. Nous detaillons ce parcours de migration sur change sets versus Serpent. Pour d'autres guides Salesforce DevOps, voyez les guides Serpent.

Comment eviter les erreurs de migration courantes ?

N'essayez pas une bascule d'un coup. Migrez un perimetre a la fois et gardez les change sets en parallele jusqu'a ce que chaque pipeline soit eprouve. Activez le source tracking avant de construire, pas apres, sinon vos premieres sandboxes ne captureront pas les changements. Et faites la baseline de toute l'org avant que quiconque n'ouvre une branche, pour que votre depot reflete la production des le premier jour au lieu de s'en ecarter.

FAQ

Dois-je arreter d'utiliser les change sets immediatement ?

Non. Migrez perimetre par perimetre et gardez les change sets pour les equipes non encore migrees, ainsi la livraison ne gele 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 depart gratuit base sur Git. Ajoutez une plateforme commerciale quand vous avez besoin de pipelines geres, de sauvegardes ou de controles qualite avances.

Comment faire la baseline d'une org existante ?

Recuperez les metadonnees de l'org avec la Salesforce CLI, convertissez-les au format source et validez-les comme premiere version de votre depot.