Pas encore sous contrôle de source : un bon signal, pas une honte

Réponse courte : une équipe Salesforce qui déploie encore avec des change sets n'est pas en retard, elle est libre de toute charge. Aucun pipeline à moitié construit à démonter, aucun modèle de branches abandonné à expliquer, aucun script écrit par quelqu'un qui est parti. Sa première semaine sous contrôle de source est plus courte que pour presque tout le monde, et le gain est plus grand.

Pourquoi "pas encore sous contrôle de source" est-il un bon signal ?

Parce que l'écart entre la situation actuelle et la situation possible représente toute la distance, et qu'aucune décision antérieure ne le bloque. Les équipes qui n'ont jamais commencé ont trois avantages discrets :

• Rien à migrer. Votre org est aujourd'hui la source de vérité. C'est une base propre, pas un désordre.
• Pas de politique des coûts irrécupérables. Personne n'a à reconnaître que le pipeline défendu en 2023 menait nulle part.
• Aucune habitude à désapprendre. L'équipe apprend un seul flux de travail, une fois, et ce flux peut être le moderne.

Les équipes Salesforce aux pires résultats de release sont rarement celles qui utilisent des change sets. Ce sont les équipes à moitié migrées : deux chemins de déploiement en parallèle, une seule personne qui comprend le YAML, et une étape de revue que tout le monde contourne dès que la release est en retard.

De quoi la douleur des change sets est-elle faite ?

Cette douleur est réelle, et la nommer précisément vaut mieux que de s'entendre dire qu'on est en retard. En s'appuyant sur un bon récapitulatif publié du comportement des change sets, les coûts récurrents sont :

• Un change set ne peut pas être modifié après l'envoi. Un composant oublié et vous clonez puis reconstruisez le paquet.
• Les composants sont sélectionnés à la main, et l'assistant de dépendances rate les chaînes indirectes de références.
• Les connexions de déploiement sont unidirectionnelles par défaut, et deux orgs de production sans lien ne peuvent pas se déployer l'une vers l'autre.
• Certaines métadonnées ne voyagent tout simplement pas, dont les valeurs de listes de sélection standard et les adresses e-mail à l'échelle de l'organisation.
• Les profils écrasent ceux de l'org cible, en supprimant silencieusement les droits absents de la source.
• Il n'y a pas de rollback après un déploiement, ni d'instantané pris avant.

Rien de tout cela n'est un problème de compétences. C'est un problème d'outillage que votre équipe absorbe en heures supplémentaires.

Que faut-il réellement apprendre ?

Moins que ne le laisse croire le discours ambiant. L'habitude de répondre à "nous ne sommes pas encore sur Git" par un cours sur les stratégies de branches fait de vrais dégâts, car elle déplace la première étape de déployer plus sûrement vers devenir développeur. Ce ne sont pas les mêmes projets.

Une équipe habituée aux change sets possède déjà l'essentiel : la connaissance de l'org, l'habitude des sandboxes, l'intuition de ce qui casse. Ce qui lui manque, c'est un enregistrement de chaque changement, un moyen d'en annuler un, et une revue qui a lieu avant la production plutôt qu'après l'incident. Git fournit les trois tout en restant en arrière-plan. Que vos admins ouvrent un jour un terminal relève du choix d'outil, pas d'une loi de la plateforme.

Comment démarrer la semaine prochaine sans ingénieur DevOps ?

1. Prenez un instantané de l'org dans un dépôt. Pas encore pour déployer. Juste pour que l'état d'aujourd'hui soit consigné et que les changements de demain apparaissent en diff.
2. Connectez vos sandboxes existantes. Gardez les environnements en place. Le chemin sandbox de dev vers UAT puis production n'a pas à changer le premier jour.
3. Faites passer un type de changement récurrent. Choisissez le déploiement le plus fréquent et routez uniquement celui-là par le nouveau chemin pendant deux semaines.
4. Rendez le rollback opérationnel avant d'élargir. La première fois qu'une release est annulée en une minute plutôt qu'en une soirée, le débat est clos.
5. Ajoutez la revue en dernier. Une fois les changements arrivant en diff, un second regard coûte quelques minutes. L'imposer avant, c'est exactement ce qui fait abandonner les équipes.

Vous pouvez le faire avec Salesforce DevOps Center, avec Gearset ou Copado, ou avec Serpent. Comparez-les d'abord honnêtement sur un axe : quelle part du flux présuppose quelqu'un dont le métier est d'écrire du YAML.

Que faut-il ignorer ?

• Les modèles de maturité qui vous comparent à des entreprises dotées d'une équipe plateforme de huit personnes.
• Les débats sur les stratégies de branches. Une branche principale protégée et des branches de fonctionnalité courtes vous porteront des années.
• Quiconque laisse entendre que le contrôle de source est une position morale. C'est un mécanisme pour défaire des erreurs. Cela n'a jamais été autre chose.

Serpent a été conçu exactement pour ce point de départ : des déploiements pilotés par tickets avec Git en dessous, un rollback en un clic, la revue de code par IA sur toutes les formules, et aucune expertise Git exigée des admins ou des consultants. Il n'installe rien dans votre org, la mise en place prend moins de 15 minutes, et notre équipe anime une session pratique avec tout le monde plutôt que de vous remettre un manuel. Il existe une formule Essentials gratuite avec un nombre illimité d'utilisateurs, et vous pouvez choisir un espace de démonstration prérempli lors de l'inscription si vous voulez regarder avant de connecter quoi que ce soit. Commencez sur Serpent.

FAQ

Est-il trop tard pour quitter les change sets ?

Non. Les change sets restent supportés et fonctionnent encore. Migrer est une décision sur le risque de déploiement et le temps de l'équipe, pas une échéance manquée.

Nos admins doivent-ils apprendre Git ?

Pas avec un outil qui garde Git en arrière-plan. Un admin doit comprendre ce qu'est une version et un rollback. Les commandes de branches sont optionnelles.

Quel est le plus grand gain de la première semaine ?

Le rollback. Pouvoir annuler vite une mauvaise release change le rapport d'une équipe au déploiement plus que n'importe quelle autre capacité.

DevOps Center suffit-il ?

C'est un vrai progrès par rapport aux change sets et c'est gratuit chez Salesforce, donc un point de départ honnête. Les équipes le dépassent en général quand elles ont besoin de packaging, de portes de test ou d'un rollback plus riche.

Faut-il nettoyer l'org avant de commencer ?

Non. Mettez l'org sous contrôle de source telle quelle. Un désordre enregistré s'améliore bien plus facilement qu'un désordre invisible.