Si je vous dis… Change Sets, qu’est-ce que ça évoque chez vous ?
Si vous venez de faire une grimace, alors continuez cet article.
Pourquoi est-ce que dans toutes les technos on pourrait gérer nos projets en maitrisant le cycle de vie de notre application, sauf avec Salesforce, à part en prenant des licences additionnelles qui coutent un bras ?
Face à ce constat, mon équipe et moi-même chez Cloudity avons décidé d’agir : dans cet article je vais vous expliquer pourquoi et comment nous avons créé la suite sfdx-hardis, et vous donner quelques billes afin de vous permettre d’évaluer factuellement si c’est dans l’intérêt de vos projets ou non de l’utiliser.
Au programme :
- Résumé de la saison précédente
- Episode 1 : La création
- Episode 2 : Pour vos projets ?
- Episode 3 : Le grand saut !
- Episode 4 : Que se cache-t-il derrière tout ça ?
- Episode 5 : A vous de jouer !
Résumé de la saison précédente
J’ai commencé à travailler sur Salesforce en 2017 : nous étions 10 collègues à paramétrer et développer dans la même org, et malgré nos tentatives désespérées de synchronisation, c’était un cauchemar de savoir qui fait quoi, où, pourquoi, et je ne parlerai même pas des performances atroces…
Nous avions mis en place quelques tentatives d’industrialisation… plutôt bancales : lignes de commande Ant copiées collées depuis un fichier Word stocké sur un disque réseau, package.xml écrits manuellement… les journées de mise en production étaient redoutées de tous, et parfois même moi j’ai hésité à poser un RTT pour éviter de vivre un tel sacerdoce…
A l’annonce de la sortie de Salesforce DX, nous aperçûmes une lumière au bout du tunnel des galères de déploiement : nous allions enfin pouvoir gérer notre projet de manière professionnelle avec du git, des pipelines CI/CD, comme dans n’importe quelle autre technologie depuis plus de dix ans !
Mais la joie fut de courte durée. SFDX est un bel outil… pour livrer des projets de type « Hello world ».
Il faut l’appeler de manière dynamique, et donc scriptée, pour le rendre applicable au cycle de vie d’un projet complexe, et sans scripts avancés nous avons rencontrés les irritants suivants :
- La nécessité de manuellement mettre à jour des fichiers XML pour que leur déploiement ne provoque pas d’obscures erreurs de la metadata API ;
- L’écrasement régulier de configurations directement effectuées dans les orgs ;
- De gros problèmes d’adoption auprès des utilisateurs non techniques.
Nous avons donc du scripter, scripter et encore scripter (en Bash, en Groovy ou en Node.js, selon l’humeur voire la météo…) jusqu’à atteindre un état à peu près acceptable de la chaîne d’intégration et de déploiement continue (la fameuse CI/CD !).
Mais ces scripts devaient être maintenus directement dans le repository git du projet, ce qui était terriblement chronophage, et nécessitait l’expertise d’un architecte DevOps.
Episode 1 : La création
Lorsqu’ Hardis-Group m’a fait l’extrême honneur de m’embaucher en tant que CTO de leur département dédié à l’intégration Salesforce (désormais la filiale Cloudity), certains de nos clients avaient déjà exigé de travailler en versionnement et CI/CD.
Les quelques projets CI/CD existants maintenaient leurs propres pipelines et scripts chacun de leur côté, selon leurs besoins spécifiques mais souvent analogues.
Cette situation était gérable, mais pas scalable, nous avons par conséquent dû réévaluer les différentes orientations disponibles dans l’écosystème Salesforce :
- Acheter de couteuses licences d’un outil DevOps tiers du marché comme Copado, Gearset, Flosum, Autorabit, Blue Canvas, Prodly ou Opsera ;
- Continuer à travailler avec des pipelines CI/CD faits maison (et les maintenir avec souffrance sur chacun de nos projets).
Afin de réfléchir aux avantages et inconvénients de chaque option, nous avons défini une matrice décisionnelle.
Nous n’étions pas franchement emballés par les options commerciales, car nos clients n’ont pas tous le budget nécessaire.
La plupart d’entre eux auraient été réticents à l’idée d’acheter de couteuses licences additionnelles, pour une utilisation qui restait encore très abstraite dans leur esprit.
« Pourquoi payer pour du DevOps alors qu’avec les Change Sets on y arrivait à peu près jusqu’ici ? »
Comme nous avions de sérieuses compétences en interne sur les pipelines CI/CD scriptés, nous avons décidé de conserver ce modus operandi.
Mais nous ne souhaitions pas alourdir nos charges en maintenant des scripts pour chacun de nos clients. Cela nous a donné l’idée de les factoriser en packageant un moteur open-source, qui serait utilisé sur tous les projets, ces derniers contenant uniquement la configuration appliquée par le moteur.
C’est ainsi qu’est né le plugin Salesforce DX sfdx-hardis !
Les plugins Salesforce DX fonctionnent en ligne de commande, et certains de nos collègues consultants fonctionnels et administrateurs étaient très peu enthousiastes à la perspective d’écrire des lignes barbares dans un terminal.
Nous avons donc décidé de créer une interface utilisateur permettant d’interagir avec l’outillage avec des clics et non des lignes de commande.
Ainsi fut posée la première pierre de l’extension VsCode sfdx-hardis.
Episode 2 : Pour vos projets ?
Vous êtes fatigué(e)s des Change Sets, de manquer de maitrise, de maintenir les scripts de votre pipeline, ou alors vous ne voulez ou ne pouvez pas payer pour un des produits DevOps du marché ?
Alors il est peut-être temps de basculer du modèle «Org-Based Artisanal» avec déploiements manuels au modèle «Source-Based Industrialisé» avec déploiements automatisés !
Après avoir franchi ce cap, vous bénéficierez bien avant de déployer en production de ces importants patterns :
- Le Versionnement, pour tracer qui a fait quoi, quand, où et pourquoi ;
- Les Simulations de déploiements dès le premier niveau de la chaîne, y compris la couverture exhaustive des tests unitaires Apex et LWC ;
- Les Contrôles de la qualité du code, pour diminuer les risques de bugs, régressions, ainsi que maîtriser la dette technique ;
- La Gestion des conflits, pour tout simplement éviter d’écraser le travail de vos collègues (ou inversement !) ;
- Les Déploiements automatisés : laissez les serveurs CI déployer pour vous, avec un minimum d’actions manuelles nécessaires.
Le diagramme suivant peut vous donner une idée de l’évolution entre un projet non-CI/CD et un projet géré en CI/CD, notamment au niveau des déploiements.
Les automatismes sont exécutés sur un serveur CI qui orchestre l’ensemble des jobs de contrôle et de déploiement.
La chaîne CI/CD amène des avantages cruciaux :
- Grâce aux jobs de contrôle automatisés, tout ce qui sera déployé avec succès dans l’org d’intégration sera ensuite déployé de manière transparente vers la recette, la pré-production, et enfin l’org de production ;
- L’intégration étant linéaire et continue, ce que vous testerez fonctionnellement en recette coïncidera avec ce qui sera déployé en production.
Episode 3 : Le grand saut !
Voici quelques modèles courants d’utilisation de sfdx-hardis. Mais avant de vous lancer, certains prérequis sont nécessaires :
- L’accès à un serveur GIT & CI/CD. C’est le serveur qui exécute les scripts pour gérer la chaîne CI/CD. sfdx-hardis est nativement intégré avec Gitlab CI et Azure Pipelines. Vous pouvez également l’adapter à Github Actions, Bitbucket Pipelines et Jenkins ;
- La nomination d’un Release Manager, qui a des compétences en Git et Salesforce DX ;
- La volonté d’évoluer : vos équipes doivent être suffisamment matures pour accepter d’adapter leurs méthodes de travail à la chaîne d’intégration continue, ainsi que de laisser les Change Sets aux oubliettes, dans l’objectif de produire des livrables mieux maîtrisés et de meilleure qualité.
Maintenant, allons voir comment sfdx-hardis s’applique en fonction de votre rôle dans l’équipe d’un projet Salesforce.
- Setup Manager ;
- Release Manager (peut également être le Setup Manager) ;
- Contributeur (consultants fonctionnels et techniques, administrateurs).
En tant que Setup Manager
Le Setup Manager va initialiser les éléments techniques du projet Salesforce CI/CD (repository Git, stratégie de branches, pipeline CI/CD, authentification entre le serveur CI et les orgs Salesforce…).
Voici un exemple de stratégie de branches avancée, avec une gestion parallèle de BUILD et de RUN pour un projet, mais selon la complexité de votre besoin, il est également possible de définir une stratégie de branches beaucoup plus simple avec uniquement une préproduction (branche & org) et une production (branche & org).
Toutes les étapes de l’initialisation sont détaillées dans le Sfdx-hardis Setup Guide, incluant des tutoriels et vidéos.
En tant que release manager
Le rôle du release manager sera d’assister les contributeurs, de valider les Merge Requests et de procéder aux déploiements entre les branches majeures (exemples : recette vers pré-production, pré-production vers production).
Toutes les activités du Release Manager sont détaillées dans le sfdx-hardis Release Manager Guide, incluant des tutoriels et vidéos.
En tant que contributeur
Le rôle des contributeurs est de fournir de nouvelles fonctionnalités et des correctifs.
Ils travailleront dans des Sandbox (ou parfois scratch orgs), et utiliseront les menus interactifs de VsCode SFDX Hardis pour :
- Démarrer une nouvelle User Story ;
- Ouvrir leur sandbox pour y effectuer la configuration et les développements ;
- Rapatrier de leur sandbox les mises à jour sous forme de fichiers metadatas ;
- Préparer les Merge Requests pour publier leurs évolutions au niveau supérieur .
Les commandes pour consultants/admins sont simplifiées, cependant les développeurs auront accès à beaucoup d’actions plus avancées !
Toutes les activités des contributeurs sont détaillées dans sfdx-hardis User Guide, incluant des tutoriels et vidéos.
Episode 4 : Que se cache-t-il derrière tout ça ?
Pas de boîte noire ou de magie vaudou en arrière-plan… mais des outils simples et robustes, tels que décrits dans les sections suivantes.
Plugin Salesforce DX : sfdx-hardis
sfdx-hardis est essentiellement un orchestrateur de:
- commandes Salesforce DX natives
- commandes Git
- commandes d’autres plugins Salesforce DX.
Il a été conçu de manière à assister les utilisateurs à l’aide de parcours interactifs leur demandant de répondre à des questions et saisir des valeurs.
Les commandes lancées en arrière-plan sont affichées en direct dans les logs du terminal, afin que les utilisateurs les plus techniques comprennent mieux les actions de l’outillage et montent en compétences sur git et Salesforce DX par la même occasion.
Un des grands avantages de l’outillage est qu’il automatise certaines opérations fastidieuses, et met à jour le XML lorsque cela est nécessaire, par exemple :
- Mise à jour automatique des package.xml et destructiveChanges.xml avant de commiter (grâce à sfdx-git-delta !) ;
- Installation automatique des Managed Packages au cours des déploiements ;
- Import automatique de données référentielles (ex : Maps, CPQ) au cours des déploiements (grâce à sfdmu !) ;
- Suppression des permissions sur les profils, pour éviter des soucis futurs en 2026 avec leur dépréciation ;
- Correction automatique des fichiers XML afin qu’ils puissent être déployés sans erreurs ;
- Gestion de l’évitement des écrasements non souhaités d’éléments dans les orgs cibles de déploiement, lorsqu’il est prévu qu’ils soient directement maintenus en production ;
- Initialisation des sandboxes et des scratch orgs avec des affectations utilisateur, des scripts Apex, des échantillons de données…
- Enforcement du rapatriement de metadonnées qui ne sont parfois pas détectées par le tracking SFDX ;
- Génération de certificats, déploiement d’une Connected App et définition de variables d’environnement pour créer une connexion sécurisée entre le serveur CI et les orgs ;
- Instructions compréhensibles par un être humain pour résoudre les erreurs de déploiement ;
- Et bien d’autres choses encore !
La majorité de la configuration est située dans un unique fichier YAML dans votre repository, livré avec une documentation exhaustive ainsi qu’une auto-complétion dans votre IDE. Son contenu est principalement mis à jour par les commandes de configuration sfdx-hardis.
Lorsque vous utilisez la commande « Create sfdx-hardis project », elle génère des pipelines CI/CD prêts à l’emploi :
-
- Pour Gitlab : gitlab-ci.yml
- Pour Azure : azure-pipelines-checks.yml, azure-pipelines-deployment.yml
Sfdx-hardis fournit également une commande qui permet de créer un repository additionnel de monitoring, qui effectuera une sauvegarde journalière de toutes les métadonnées de toute org, afin que vous puissiez :
- Tracer de manière fine les mises à jour manuelles effectuées par les administrateurs en production ;
- Anticiper les problèmes liés aux futures mises à jour de la plateforme Salesforce, comme par exemple la dépréciation des anciennes versions des API ;
- Comparer le contenu de vos différentes orgs majeures.
Extension Visual Studio Code : VsCode SFDX Hardis
VsCode SFDX Hardis contient principalement un menu permettant de lancer les différentes commandes, mais aussi :
- Une intégration entre les lignes de commande sfdx-hardis et l’interface utilisateur de Visual Studio Code, pour une meilleure expérience utilisateur, avec des clics plutôt que des lignes de commande.
- La vérification de la présence et de la conformité des outils et dépendances (Node.js, sfdx-cli, plugins SFDX…), ainsi que des messages visuels pour assister les utilisateurs lorsque des installations ou mises à jour sont nécessaires.
Episode 5: A vous de jouer !
Comme nous l’utilisons avec succès sur de nombreux projets clients, nous considérons que notre suite open-source pour gérer les projets en CI/CD est suffisamment mature pour être officiellement partagée avec la communauté des trailblazers !
Il s’agit de l’humble présent de Cloudity à l’Ohana Salesforce : tout ce que nous demandons en retour, c’est du feedback, et peut-être quelques Github Stars 🙂
Les Pull Requests sont bien évidemment les bienvenues pour tous ceux qui souhaitent participer à cette belle aventure, et cela même si vous êtes un concurrent, car c’est ainsi que fonctionne la communauté open-source : chacun apporte sa pierre à l’édifice et tout le monde en profite 😊
Remerciements particuliers à :
- Vernon Keenan pour m’avoir donné l’opportunité de poster sur salesforcedevops.net
- Maxime Guenego, Clément Fernandez, Remy Vultaggio Focher & Fabien Taillon pour les relectures.
Nicolas Vuillamy a été invité par Vernon Keenan à réaliser une interview sur notre SFDX-HARDIS.
Vous pouvez écouter le podcast ici 👉
Si vous voulez lire l’article original, cliquez ici.
