Table of Content
Dans le secteur du logiciel, il est d’usage de procéder au développement et à l’écriture du code spécifique dans une organisation de développement, de faire passer ces modifications dans une organisation de test, puis de faire passer tout ce code spécifique dans une organisation de production réelle une fois les tests effectués. Le processus consistant à déplacer les modifications s’appelle le déploiement, et les ensembles de modifications Salesforce constituent le seul outil fourni par Salesforce de manière native pour procéder à la migration et au déploiement de ces modifications.
Il est possible d’ajouter divers éléments de Salesforce, comme des classes Apex, des pages Visualforce, des éléments Lightning, des profils et d’autres métadonnées, à un ensemble de modifications créé à partir d’une organisation d’origine. Il suffit ensuite d’importer cet ensemble de modifications dans l’organisation de destination (organisation de test ou de production) et de cliquer sur « valider » pour le déployer dans l’organisation de destination. Si une erreur se produit, elle vous est signalée. Si tout se passe bien, vos modifications sont désormais appliquées.
Cependant, les ensembles de modifications Salesforce ne respectent pas les bonnes pratiques du développement logiciel moderne en matière de déploiement. Il manque notamment une analyse des risques, une visibilité sur les modifications déployées en production ou encore des renseignements exploitables concernant les répercussions sur l’activité et les vulnérabilités associées. Ci-dessous, nous aborderons ces lacunes ainsi que d’autres défauts identifiés par des experts de Salesforce lors de la mise en œuvre d’ensembles de modifications.
On ne peut pas tout déployer
Les ensembles de modifications ne sont pas compatibles avec tous les éléments Salesforce. Un administrateur devra donc effectuer certaines modifications à la main. Parmi les éléments incompatibles, citons les valeurs des listes de sélection standard, les processus de vente, les divisions ou encore les adresses e-mail à l’échelle d’une organisation. À cause de cette limite, une organisation peut rencontrer des problèmes tels que :
- Une augmentation du temps de déploiement
- Une intervention manuelle
- La possibilité d’une erreur humaine
Incapacité à entretenir les chaînes de livraison
Imaginons que vous déployez un ensemble de modifications du développement au contrôle qualité. Tous vos contrôles qualité vérifient que tout fonctionne et votre ensemble de modifications est prêt à passer dans l’environnement de production. Cependant, vous ne pouvez pas faire passer le même ensemble de modifications en production. Vous devez recréer l’ensemble de modifications dans l’environnement de contrôle qualité avant de le passer en production. Cela signifie notamment que les organisations qui disposent de plusieurs environnements de test, de pré-production, puis de production ne peuvent pas établir une chaîne lorsqu’elles utilisent des ensembles de modifications.
Les problèmes qui surviennent dans ce cas comprennent :
- Une augmentation du temps de déploiement
- La possibilité d’une erreur humaine
- L’absence de déploiement continu en un seul clic
Seules les organisations connectées sont compatibles
Cette fois, imaginons que vous créez vos organisations Sandbox de développement et de contrôle qualité à partir d’une seule instance de production. Toutes ces organisations sont connectées, si bien que vous pouvez désormais utiliser les ensembles de modifications pour faire passer les modifications du développement au contrôle qualité puis à la production. Si plusieurs organisations ayant chacune leur propre instance de production utilisent le même produit ou la même application, vous ne pouvez pas définir une connexion de production à production. Il s’agit d’un scénario courant dans le secteur des soins de santé, dans lequel plusieurs hôpitaux utilisent le même produit Salesforce sous-jacent mais des organisations de production différentes.
Ce problème s’accompagne de :
- Une augmentation du temps de déploiement
- Un manque de faisabilité et de réutilisabilité
- Un travail redondant
L’ajout et le retrait d’éléments sont une corvée
La création de grands ensembles de modifications n’est pas aisée Il faut faire défiler diverses pages lorsque l’on a des milliers d’éléments, l’état n’est pas conservé lors des changements de page, et il n’est pas possible d’ajouter des types d’éléments différents en même temps. Pour ne rien arranger, les éléments ajoutés par erreur doivent être retirés un à un. Quelle galère !
À la place, de nombreux administrateurs ont recours à des extensions de navigateur pour résoudre ce problème, ce qui leur permet d’aller plus vite. Cependant, ces extensions prennent le contrôle de vos données et de votre code, ce qui peut constituer une violation des obligations que votre organisation s’est engagée à respecter.
Citons notamment les inconvénients suivants :
- La lenteur de création et d’édition (frustrante)
- Le risque de non-conformité en cas d’utilisation d’extensions de navigateur
Aucune analyse des risques avant le déploiement
Les ensembles de modifications ne présentent aucune analyse des risques liés aux modifications à déployer. Par exemple, ils ne permettent pas de déterminer à quel point une modification est essentielle en fonction du nombre d’endroits où elle est déjà utilisée dans l’application. Cela signifie que vous ne pouvez pas communiquer les risques au client au préalable, ce qui entraîne une réduction de la fiabilité et une augmentation de la vulnérabilité du déploiement. Aujourd’hui, de nombreux clients se voient contraints de recourir à des applications d’identification des risques afin de gérer les risques potentiels associés aux déploiements. Panaya Release Dynamix pour Salesforce fait partie de ces outils capables d’afficher un tableau de bord et un résumé des risques associés à vos déploiements imminents.
L’absence d’analyse des risques appropriée entraîne donc :
- Des vulnérabilités et des risques lors du déploiement
- L’absence d’analyse des dépendances
Aucune intégration avec les systèmes de contrôle des versions
Il est impossible de créer automatiquement des ensembles de modifications en fonction des numéros de révision de Git ou SVN. La plupart des organisations utilisent Git ou SVN comme source d’informations lorsque plusieurs développeurs écrivent du code dans le même système. Cependant, puisque les ensembles de modifications ne sont pas intégrés à la gestion des versions, des efforts supplémentaires sont nécessaires pour identifier les modifications réalisées et la façon de déployer chaque ensemble de modifications à la main un par un. En cas d’utilisation de plusieurs organisations Sandbox de développement, un développeur est susceptible d’écraser les modifications d’un autre développeur, puisque la source d’informations des ensembles de modifications est l’organisation Salesforce, et non Git ou SVN. Une solution consiste à utiliser Jenkins ou d’autres solutions dans le cloud pour effectuer le déploiement en utilisant Git ou SVN comme source d’informations.
Les problèmes qui surviennent sont les suivants :
- Des déploiements faillibles
- Des efforts supplémentaires nécessaires pour créer des ensembles de modifications
Impossibilité de revenir en arrière
Une fois qu’un ensemble de modifications a été déployé dans une organisation de destination, il n’est pas possible d’annuler les modifications si l’activité le nécessite. Cela signifie que le client ou l’activité est bloqué jusqu’à ce que vous ayez inversé toutes les modifications dans votre organisation de contrôle qualité, recréé un ensemble de modifications et déployé à nouveau celui-ci en production. Cela peut facilement entraîner une perte d’activité pour le client si les modifications déployées bloquent ses activités principales. Puisque les ensembles de modifications ne s’accompagnent pas d’analyses des risques, ces demandes de retour arrière ne sont pas rares.
Seul un problème majeur se pose ici : l’absence de solution de repli en cas de problème.
Quels éléments ont été déployés et pour quelle modification ?
Malheureusement, les ensembles de modifications ne permettent pas de répondre à cette question. Ils ne sont pas intégrés aux principaux logiciels de gestion de projet comme JIRA, Mantis et Bugzilla. Il n’est pas non plus possible de créer des groupes d’éléments au sein d’un ensemble de modifications, puisque tous les éléments de toutes les modifications se présentent sous la forme d’une liste unique. Cela signifie que l’on ne bénéficie d’aucune visibilité sur les liens entre la demande du client et les éléments modifiés pour y répondre, ce qui est dangereux lorsque l’on doit revenir en arrière pour identifier l’origine d’un problème.
Les logiciels comme Panaya Release Dynamix pour Salesforce proposent une IU facile à utiliser qui permet de définir le périmètre des spécifications, d’associer les éléments à ces spécifications et d’analyser les risques de façon indépendante. RDx pour Salesforce vous permet également d’associer des scénarios de test au périmètre de chaque spécification ; vous pouvez même créer des scénarios de test automatiques pour répondre à des spécifications complexes.
Le problème principal : un manque de visibilité sur les modifications.
Aucune prise en compte des concepts actuels de cycle de développement du système
Les concepts de cycle de développement du système que sont la CI/CD, la gestion des risques et la livraison avec certitude sont très loin. Les ensembles de modifications ne sont pas compatibles avec l’intégration continue et la livraison continue (CI/CD). Ils ne tiennent certainement pas compte des répercussions sur l’activité que peuvent entraîner les modifications en production. Compte tenu de l’absence de déploiements en un clic et de l’impossibilité d’établir une chaîne de livraison, les déploiements s’accompagnent d’incertitude. Toutes ces lacunes sont incompatibles avec les bonnes pratiques actuelles en matière de développement logiciel.
On retrouve donc ici les problèmes de :
- L’incertitude lors des déploiements
- L’incompatibilité avec les bonnes pratiques
Alors, pourquoi utiliser les ensembles de modifications ?
Malgré leurs nombreux inconvénients, les administrateurs et les développeurs continuent d’utiliser les ensembles de modifications. Cela semble incroyable étant donné le nombre de contraintes et d’obstacles. Comment les ensembles de modifications sont-ils restés un outil aussi répandu pour les déploiements Salesforce pendant plus de 15 ans ? Nous avons consulté de nombreux administrateurs et développeurs afin d’identifier les raisons pour lesquelles les ensembles de modifications sont toujours utilisés. Voici quelques-unes des raisons que nous avons identifiées.
Négligence
Il est possible qu’un grand nombre d’administrateurs et de développeurs trouvent tout simplement plus rapide de négliger les bonnes pratiques en matière de gestion des versions. Par ailleurs, il arrive que nous ne parvenions pas à comprendre les répercussions négatives que cela pourrait avoir sur notre activité.
Travail supplémentaire pour répondre à des besoins spécifiques
Les ensembles de modifications sont créés sur la plateforme Salesforce. Pour utiliser d’autres outils de déploiement comme GIT avec Jenkins, il faut installer ceux-ci en local sur un serveur ou souscrire à des abonnements pour en bénéficier dans le cloud. De nombreuses personnes préfèrent éviter de faire des efforts supplémentaires pour répondre à des besoins spécifiques lors des déploiements.
Manque de connaissances
Peu de développeurs et d’administrateurs du secteur de Salesforce, qui s’est développé ces dix dernières années, connaissent des outils capables de les assister dans leurs déploiements Salesforce. Pourtant, ces outils existent bel et bien. On peut citer les solutions Jenkins dans le cloud ainsi que diverses applications d’éditeurs de logiciels, comme Gearset. Plus rares encore sont ceux qui connaissent la gestion et la planification des risques, que proposent des logiciels comme Panaya Release Dynamix pour Salesforce.
Alternatives
Vous êtes certainement d’accord avec un grand nombre des limites mentionnées ci-dessus. Vous pourriez même avoir été confronté à certaines d’entre elles dans le cadre de vos propres déploiements et versions Salesforce. Alors, comment obtenir une gestion des versions plus moderne et plus sûre ?
Pour commencer, vous pouvez utiliser un système de gestion des versions comme Git ou SVN pour gérer votre source d’informations. Cela permet de s’affranchir des limites de la fusion du code et de promouvoir un meilleur suivi du code. Vous devriez également mettre en œuvre un outil de déploiement afin de déployer les éléments Salesforce à partir de ces systèmes de gestion des versions. Jenkins, par exemple, est un programme en Java qui contient des packages permettant une intégration avec Salesforce. Il est possible de le configurer en local ou d’utiliser une solution dans le cloud.
Ensuite, vous devez vous intéresser aux évaluations des risques et aux analyses d’impact sur l’activité : cet aspect des déploiements est souvent négligé. Des outils comme RD de Panayax s’appuient sur des technologies permettant d’orienter et de calculer les dépendances de chaque modification avec d’autres modifications et d’estimer les risques (faible, moyen, fort) afin de vous permettre de déployer en toute confiance. RDx permet d’associer des scénarios de test à des modifications individuelles pour vous permettre de déterminer si les histoires à fort impact ont été rigoureusement testées. Grâce à cela, vous (et vos supérieurs hiérarchiques) pouvez dormir sur vos deux oreilles.