Le developpement pilote par la source dans Salesforce, explique

La definition d'abord : le developpement pilote par la source est le modele ou votre depot Git, et aucune org, fait autorite sur la configuration et le code Salesforce. Les orgs deviennent des environnements jetables vers lesquels vous deployez depuis le depot, plutot que des endroits entre lesquels vous copiez des changements. Tout le reste de ce guide decoule de cette phrase.

Qu'est-ce que le developpement pilote par la source dans Salesforce ?

Dans ce modele, chaque changement arrive d'abord dans le controle de version et seulement ensuite dans une org. Le depot contient l'etat voulu de l'org. Un deploiement est l'acte de rendre une org conforme a cette intention.

Trois proprietes pratiques l'accompagnent :

• Historique. Chaque changement porte un auteur, une date et une raison.
• Reversibilite. Revenir en arriere consiste a deployer un etat connu comme bon, pas a le reconstruire de memoire.
• Parallelisme. Deux personnes peuvent travailler sur le meme objet sans que l'une ecrase silencieusement l'autre, parce que la fusion est explicite.

En quoi cela differe-t-il du deploiement d'org a org ?

Le deploiement d'org a org, par change sets ou par comparaison directe de deux orgs, prend une org vivante comme reference. C'est la vraie distinction, et elle a des consequences.

• Ou vit la verite. Org a org : l'org source. Pilote par la source : la branche.
• Ce qu'est une release. Org a org : une liste de composants assemblee par une personne. Pilote par la source : un diff entre deux commits.
• L'historique obtenu. Org a org : ce que le journal de deploiement a bien voulu garder. Pilote par la source : tout l'historique, pour toujours.
• Le retour arriere. Org a org : reconstruire l'etat precedent a la main. Pilote par la source : deployer le commit precedent.
• Qui peut auditer. Org a org : qui possede un acces admin. Pilote par la source : quiconque peut lire le depot, y compris des auditeurs qui ne devraient jamais toucher la production.

Notez ce qui n'est pas dans cette liste : la vitesse. Ce modele n'est pas automatiquement plus rapide. Il est reproductible, ce qui est une propriete differente et plus durable.

Qu'est-ce que le source tracking et ou fonctionne-t-il ?

Le source tracking est la fonction de la plateforme qui enregistre quels composants ont change dans une org ou dans votre projet local depuis la derniere synchronisation, afin de ne recuperer que ce qui a reellement bouge au lieu de tout retirer et de lire un diff.

La limite que l'on rencontre est la couverture. Le source tracking est disponible dans les scratch orgs et dans les sandboxes Developer et Developer Pro. Il ne l'est pas partout, donc un modele pilote par la source doit repondre pour les environnements incapables de suivre les changements : sandboxes full, copies partielles et production. Ce sont exactement les orgs ou naissent les changements non documentes.

Source format ou metadata format : que commite-t-on ?

On commite le source format. Les deux formats decrivent les memes metadonnees differemment :

• Le metadata format est la forme de la Metadata API : de gros fichiers par objet plus un manifeste package.xml. Modifier un champ reecrit un gros fichier, donc le diff embarque tout l'objet et la revue devient bruyante.
• Le source format decompose cette structure : chaque champ, regle de validation et vue de liste obtient son propre fichier dans une arborescence, avec les repertoires de package declares dans sfdx-project.json.

L'effet porte sur la revue et la fusion, pas sur la fonction. De petits fichiers donnent des diffs lisibles et bien moins de conflits quand deux personnes touchent le meme objet, et c'est precisement la situation que ce modele existe pour survivre.

Que faire quand l'org et le depot divergent ?

C'est la question que la plupart des explications evitent, et celle qui decide si le modele survit au contact d'une vraie equipe Salesforce. Quelqu'un modifiera toujours quelque chose en production : un correctif a minuit, un admin qui ajoute une valeur de liste, une mise a jour de package qui reecrit des metadonnees que vous aviez commitees.

Tranchez ces trois points avant la migration, pas apres :

1. Qui gagne. Le depot gagne, par politique. Un changement hors circuit n'est donc pas "perdu" mais reconcilie : recupere, commite avec une explication, puis redeploye depuis la branche.
2. Comment vous l'apprenez. Faites tourner une detection de derive contre la production selon un calendrier. Decouvrir la divergence au moment de la release, c'est la decouvrir trop tard.
3. Ce qui est volontairement hors perimetre. Certaines metadonnees sont reellement propres a l'environnement ou appartiennent a un package installe. Ecrivez cette liste d'exclusions. Une liste honnete vaut mieux qu'un depot que tout le monde soupconne en silence.

Comment adopter cela sans equipe a l'aise avec Git ?

La plupart des equipes Salesforce sont des admins et des consultants, pas des utilisateurs de CLI, et c'est la que les migrations calent. Ordonnez les etapes pour que personne n'ait a apprendre Git pour continuer a travailler :

1. Commencez par une frontiere de package. Une equipe, un jeu de metadonnees. N'essayez pas de commiter toute l'org la premiere semaine.
2. Recuperez en source format et obtenez un deploiement propre de ce perimetre vers une sandbox avant que quiconque change ses habitudes.
3. Mettez une porte devant la production. Meme une approbation manuelle sur une branche compte. Une verite sans porte derive en un mois.
4. Gardez l'interface quotidienne familiere. Les admins continuent de travailler dans un ticket ou un work item ; commit, branche et fusion doivent se produire en dessous.
5. Ajoutez la detection de derive en dernier. Une fois le pipeline credible, elle vous dit ou le modele fuit.

FAQ

Faut-il que chaque admin apprenne Git ?

Non. Il faut que le depot fasse autorite. Qui manipule Git directement est un choix d'outillage, pas une propriete du modele.

Faut-il convertir toute l'org en source format d'un coup ?

Non. Convertissez par frontiere de package ou par equipe. Un depot partiel reellement faisant autorite sur son perimetre vaut mieux qu'un depot complet auquel personne ne se fie.

Est-ce la meme chose que le CI/CD ?

Non. Le modele pilote par la source decide ou vit la verite. Le CI/CD automatise son transport vers les orgs. Le premier peut exister sans le second, l'inverse n'a guere de sens.

Et les metadonnees non versionnables ?

Certains parametres et composants appartenant a un package ne font pas l'aller-retour proprement. Documentez-les comme exclus et pilotez-les par procedure au lieu de pretendre que le depot les couvre.

Serpent est concu pour exactement l'equipe decrite ici : le depot reste la source de verite pendant que les admins et consultants travaillent dans des tickets, avec deploiements delta, detection de derive et retour arriere en un clic par-dessus. D'autres guides de reference sont dans SF Guides.