Pas encore sous controle de source : un bon signal, pas une honte

Reponse courte : une equipe Salesforce qui deploie encore avec des change sets n'est pas en retard, elle est libre de toute charge. Aucun pipeline a moitie construit a demonter, aucun modele de branches abandonne a expliquer, aucun script ecrit par quelqu'un qui est parti. Sa premiere semaine sous controle de source est plus courte que pour presque tout le monde, et le gain est plus grand.

Pourquoi "pas encore sous controle de source" est-il un bon signal ?

Parce que l'ecart entre la situation actuelle et la situation possible represente toute la distance, et qu'aucune decision anterieure ne le bloque. Les equipes qui n'ont jamais commence ont trois avantages discrets :

• Rien a migrer. Votre org est aujourd'hui la source de verite. C'est une base propre, pas un desordre.
• Pas de politique des couts irrecuperables. Personne n'a a reconnaitre que le pipeline defendu en 2023 menait nulle part.
• Aucune habitude a desapprendre. L'equipe apprend un seul flux de travail, une fois, et ce flux peut etre le moderne.

Les equipes Salesforce aux pires resultats de release sont rarement celles qui utilisent des change sets. Ce sont les equipes a moitie migrees : deux chemins de deploiement en parallele, une seule personne qui comprend le YAML, et une etape de revue que tout le monde contourne des que la release est en retard.

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

Cette douleur est reelle, et la nommer precisement vaut mieux que de s'entendre dire qu'on est en retard. En s'appuyant sur un bon recapitulatif publie du comportement des change sets, les couts recurrents sont :

• Un change set ne peut pas etre modifie apres l'envoi. Un composant oublie et vous clonez puis reconstruisez le paquet.
• Les composants sont selectionnes a la main, et l'assistant de dependances rate les chaines indirectes de references.
• Les connexions de deploiement sont unidirectionnelles par defaut, et deux orgs de production sans lien ne peuvent pas se deployer l'une vers l'autre.
• Certaines metadonnees ne voyagent tout simplement pas, dont les valeurs de listes de selection standard et les adresses e-mail a l'echelle de l'organisation.
• Les profils ecrasent ceux de l'org cible, en supprimant silencieusement les droits absents de la source.
• Il n'y a pas de rollback apres un deploiement, ni d'instantane pris avant.

Rien de tout cela n'est un probleme de competences. C'est un probleme d'outillage que votre equipe absorbe en heures supplementaires.

Que faut-il reellement apprendre ?

Moins que ne le laisse croire le discours ambiant. L'habitude de repondre a "nous ne sommes pas encore sur Git" par un cours sur les strategies de branches fait de vrais degats, car elle deplace la premiere etape de deployer plus surement vers devenir developpeur. Ce ne sont pas les memes projets.

Une equipe habituee aux change sets possede deja 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 plutot qu'apres l'incident. Git fournit les trois tout en restant en arriere-plan. Que vos admins ouvrent un jour un terminal releve du choix d'outil, pas d'une loi de la plateforme.

Comment demarrer la semaine prochaine sans ingenieur DevOps ?

1. Prenez un instantane de l'org dans un depot. Pas encore pour deployer. Juste pour que l'etat d'aujourd'hui soit consigne 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 a changer le premier jour.
3. Faites passer un type de changement recurrent. Choisissez le deploiement le plus frequent et routez uniquement celui-la par le nouveau chemin pendant deux semaines.
4. Rendez le rollback operationnel avant d'elargir. La premiere fois qu'une release est annulee en une minute plutot qu'en une soiree, le debat est clos.
5. Ajoutez la revue en dernier. Une fois les changements arrivant en diff, un second regard coute quelques minutes. L'imposer avant, c'est exactement ce qui fait abandonner les equipes.

Vous pouvez le faire avec Salesforce DevOps Center, avec Gearset ou Copado, ou avec Serpent. Comparez-les d'abord honnetement sur un axe : quelle part du flux presuppose quelqu'un dont le metier est d'ecrire du YAML.

Que faut-il ignorer ?

• Les modeles de maturite qui vous comparent a des entreprises dotees d'une equipe plateforme de huit personnes.
• Les debats sur les strategies de branches. Une branche principale protegee et des branches de fonctionnalite courtes vous porteront des annees.
• Quiconque laisse entendre que le controle de source est une position morale. C'est un mecanisme pour defaire des erreurs. Cela n'a jamais ete autre chose.

Serpent a ete concu exactement pour ce point de depart : des deploiements pilotes 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 exigee des admins ou des consultants. Il n'installe rien dans votre org, la mise en place prend moins de 15 minutes, et notre equipe anime une session pratique avec tout le monde plutot que de vous remettre un manuel. Il existe une formule Essentials gratuite avec un nombre illimite d'utilisateurs, et vous pouvez choisir un espace de demonstration prerempli 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 supportes et fonctionnent encore. Migrer est une decision sur le risque de deploiement et le temps de l'equipe, pas une echeance manquee.

Nos admins doivent-ils apprendre Git ?

Pas avec un outil qui garde Git en arriere-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 premiere semaine ?

Le rollback. Pouvoir annuler vite une mauvaise release change le rapport d'une equipe au deploiement plus que n'importe quelle autre capacite.

DevOps Center suffit-il ?

C'est un vrai progres par rapport aux change sets et c'est gratuit chez Salesforce, donc un point de depart honnete. Les equipes le depassent en general 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 controle de source telle quelle. Un desordre enregistre s'ameliore bien plus facilement qu'un desordre invisible.