DevOps Salesforce pour les admins : déployer sans toucher à Git

Réponse courte : un administrateur Salesforce n'a pas besoin d'apprendre Git pour déployer sereinement. Ce qu'il vous faut, c'est un pipeline versionné, et un outil DevOps piloté par tickets peut le faire tourner à votre place : vous choisissez vos changements dans une interface, l'outil les commite, ouvre la pull request, lance les tests et promeut le travail à travers vos environnements. Git tourne toujours en dessous. Il cesse simplement d'être votre interface.

Faut-il connaître Git pour faire du DevOps Salesforce ?

Non. Vous avez besoin de ce que Git apporte, ce qui n'est pas la même chose. Trois notions portent presque toute la valeur, et aucune n'exige un terminal.

• Gestion de versions : une trace permanente de chaque changement de métadonnée, de son auteur et de sa date, pour comparer ou revenir en arrière plus tard.
• Pipeline : un chemin fixe que suivent vos changements, par exemple sandbox de dev vers UAT vers production, avec les mêmes contrôles à chaque étape.
• Ticket de travail : l'élément auquel un changement est rattaché, pour qu'une release soit une liste de tickets approuvés et non une liste de composants dont quelqu'un s'est souvenu.

Un workflow sans Git n'est pas un workflow sans gestion de versions. C'est un workflow où la gestion de versions est automatisée pour vous.

Pourquoi les change sets ne suivent-ils plus quand l'équipe grandit ?

Les change sets restent l'outil en place, et ils tiennent très bien jusqu'à ce qu'une deuxième personne modifie l'org. Deux limites font l'essentiel des dégâts. D'abord, un change set exige une deployment connection et ne circule qu'entre org rattachées à la même org de production : les org non liées sont donc hors d'atteinte (Salesforce Help). Ensuite, un change set est un colis à usage unique : aucun historique, aucune annulation, et impossible à modifier une fois envoyé, si bien qu'une release refusée impose de reconstruire la liste à la main.

L'échec le plus coûteux n'est pas le déploiement qui plante. C'est l'écrasement silencieux : deux personnes modifient le même flow ou la même page layout dans des sandbox différentes, et celui qui déploie en second l'emporte sans bruit.

À quoi ressemble un déploiement par ticket, de bout en bout ?

C'est le processus que l'on ne montre presque jamais aux administrateurs, alors le voici en entier. Rien ci-dessous n'exige une ligne de commande.

1. Connectez les org une seule fois. Autorisez la production et chaque sandbox via OAuth. Une plateforme qui utilise les API Salesforce standard n'installe aucun package dans votre org, il n'y a donc rien à désinstaller ensuite.
2. Définissez le pipeline. Nommez vos environnements et leur ordre de promotion. Cette configuration se fait une fois et devient l'unique route vers la production.
3. Ouvrez un ticket. Un ticket par changement, idéalement par user story. C'est le ticket, et non la sandbox, qui devient l'unité de release.
4. Construisez dans votre sandbox exactement comme aujourd'hui. Clics, Flow Builder, page layouts. Votre manière de configurer Salesforce ne change pas.
5. Sélectionnez vos changements. L'outil liste ce qui a bougé dans cette sandbox depuis la dernière synchronisation. Vous cochez les composants, écrivez une courte description et les rattachez au ticket.
6. Faites relire avant que quoi que ce soit ne bouge. Les tests Apex et la couverture s'exécutent automatiquement, et une revue par IA lit le diff pour repérer les dérives de gouvernance, les problèmes de sécurité et les écarts aux bonnes pratiques. Un collègue approuve le ticket.
7. Promouvez la même sélection. Le ticket approuvé passe en UAT puis en production. Vous ne reconstruisez jamais la liste, et c'est précisément là que les releases par change set perdent des composants.
8. Publiez, et gardez le bouton d'annulation. Le déploiement en production est enregistré : si la release se comporte mal, vous revenez au dernier état sain en une action au lieu de reconstituer ce qui est parti.

Que fait Git pendant que vous cliquez ?

Chaque étape ci-dessus a un équivalent Git que la plateforme exécute pour vous :

• Ouvrir un ticket crée une branche.
• Sélectionner des composants écrit un commit dont votre description est le message.
• Demander une relecture ouvre une pull request et y lance les contrôles automatisés.
• Approuver et promouvoir fusionne cette pull request et déclenche un déploiement via l'API Metadata.
• Revenir en arrière annule le commit et redéploie l'état précédent.

Cela compte pour une raison très concrète : vos développeurs gardent le dépôt, les branches et la CLI qu'ils utilisent déjà, et les administrateurs travaillent dans une interface posée sur le même historique. Il n'y a pas de seconde source de vérité à réconcilier.

DevOps Center suffit-il à lui seul ?

Salesforce propose sa propre option gratuite, et pour une petite équipe qui quitte les change sets, c'est un vrai progrès. Connaissez les limites avant de vous engager. DevOps Center fonctionne uniquement avec les offres GitHub.com hébergées dans le cloud, y compris GitHub Enterprise Cloud, et GitHub Enterprise Server hébergé localement n'est pas pris en charge. Chaque utilisateur doit disposer de son propre compte GitHub.com, et chaque dépôt de projet doit contenir un projet Salesforce DX (Salesforce Help).

L'administrateur ne tape donc jamais de commande Git, mais quelqu'un administre toujours GitHub, et la sauvegarde, le rollback et l'automatisation des tests restent hors du produit. Si cela décrit votre équipe, une plateforme qui couvre tout le trajet sera plus légère.

Que mettre en place la première semaine ?

1. Choisissez un pipeline et une org de production. Ne modélisez pas tous vos environnements dès le premier jour.
2. Faites passer une release à faible risque de bout en bout avant de migrer le backlog.
3. Écrivez une règle de relecture, par exemple : aucun ticket en production sans une approbation.
4. Activez les tests Apex automatiques à l'étape UAT, pas à l'étape production, pour voir les échecs tôt.
5. Effectuez un rollback volontaire dans une sandbox, pour que l'équipe l'ait déjà utilisé avant d'en avoir besoin.

Serpent exécute ce processus avec Git en arrière-plan, n'installe rien dans votre org Salesforce et inclut la revue de code par IA sur tous les plans, y compris le plan gratuit. La mise en place prend moins de 15 minutes et notre équipe la fait avec vous.

FAQ

Un administrateur Salesforce peut-il faire du DevOps sans développeur ?

Oui. Sélectionner des métadonnées, relire un diff et approuver une release sont des compétences d'administrateur. Ce que l'on ne peut pas sauter, c'est le processus : un pipeline, un ticket par changement, une approbation.

Un workflow sans Git offre-t-il quand même le rollback ?

Seulement si l'outil conserve l'historique des versions. Le retour arrière est possible parce que chaque déploiement a d'abord été commité, ce que les change sets ne font jamais.

Une interface pour administrateurs va-t-elle ralentir mes développeurs ?

Non, si les deux côtés partagent un seul dépôt. Les développeurs gardent la CLI et leurs branches ; l'interface est une autre porte vers le même historique.

Que faire de mes change sets existants ?

Gardez-les le temps d'une release pendant que le nouveau pipeline tourne en parallèle, puis retirez-les. Ne migrez jamais une release déjà en cours.

D'autres guides pas à pas sur le DevOps Salesforce vous attendent dans notre bibliothèque SF Guides.