• Accueil / Salesforce / Leçons tirées de…
, Leçons tirées de la gestion des métadonnées Salesforce &#8211; Arguments en faveur du DevOps<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>

Leçons tirées de la gestion des métadonnées Salesforce – Arguments en faveur du DevOps5 minutes de lecture


La configuration simple par pointer-cliquer est un argument de vente majeur de Salesforce, permettant aux administrateurs et aux développeurs Salesforce d’adapter l’organisation Salesforce aux besoins de leur organisation. La configuration sans effort entraîne-t-elle des problèmes de développement Salesforce qui doivent maintenant être résolus?

« 10 choses que nous avons apprises en analysant 1 milliard d’éléments de métadonnées Salesforce » était un article récemment publié dans lequel Ian Gotts offre des informations fascinantes sur le développement Salesforce en s’appuyant sur l’analyse des éléments de métadonnées Salesforce par son équipe. D’après notre propre expérience chez Gearset, nous ferions écho aux points soulevés dans l’article d’Ian. Nous avons une vision légèrement différente de certaines des implications, cependant, compte tenu de notre expérience DevOps. Alors, voici nos 2 cents…

, Leçons tirées de la gestion des métadonnées Salesforce – Arguments en faveur du DevOps<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>

Défis courants pour la gestion des métadonnées

Ian met en évidence certains des défis courants pour la maintenance et le développement des organisations. Ce sont les mêmes défis que nous aidons les équipes Salesforce à résoudre en tant que fournisseur de solutions DevOps.

Comme Ian, nous voyons des organisations gigantesques avec des quantités «stupéfiantes» de métadonnées: des organisations avec 200 000 modèles de rapports et d’e-mails, 50 000 classes Apex et 1 300 ensembles d’autorisations. En termes de données, nous rencontrons des objets avec des centaines de millions d’enregistrements et des organisations avec jusqu’à 35 000 000 de comptes. La taille et la complexité de ces organisations, résultant d’années de personnalisation, posent des défis importants pour le développement et la maintenance continus du code et des configurations.

Les organisations plus anciennes, en particulier, souffrent souvent de dettes techniques, comme le souligne Ian. D’après notre expérience, c’est une conséquence courante des équipes qui ajoutent ou déploient de plus en plus de changements en production sans une vision claire de l’impact. C’est pourquoi la première chose que nous avons conçue pour Gearset a été l’outil de comparaison, qui permet aux développeurs et aux administrateurs de voir les différences exactes dans les métadonnées entre deux environnements. Les comparaisons permettent aux équipes de comprendre exactement l’effet qu’auront leurs packages de déploiement.

Les équipes rencontrent également des problèmes de dette technique si elles ne tirent pas parti des tests unitaires automatisés et de l’analyse de code statique. Ces outils fournissent des alertes précoces en cas d’échec ou de code mal conçu, ce qui entraîne finalement moins de problèmes en production.

Les déploiements Salesforce peuvent être délicats, et les commentaires d’Ian sur l’API de métadonnées nous intéressent. Au début de la construction de notre moteur de déploiement Salesforce, nous avons décidé de résoudre d’abord les problèmes difficiles. Nous savions que nous devions nous attaquer aux bizarreries du MDAPI si nous voulions offrir à l’écosystème un outil offrant des taux de réussite de déploiement inégalés. Comme Elements.cloud, et sans aucun doute bien d’autres, nous avons affiné la manière dont nous récupérons et renvoyons les métadonnées. Et au fil des ans, nous avons développé des dizaines d’analyseurs de problèmes qui détectent les problèmes courants de blocage du déploiement dans les packages de déploiement de nos utilisateurs et suggèrent automatiquement le correctif nécessaire pour un déploiement réussi.

Un processus robuste pour le développement agile

Face à ces défis, il est important de mettre en place les processus et la culture appropriés pour le développement. Nous ne pourrions être plus d’accord avec Ian pour dire que «de longs cycles de publication = une agilité et un engagement insuffisants». Accélérer votre cadence de publication, expédier petit et souvent, resserre la boucle de rétroaction pour vos développeurs. Et des sprints plus courts améliorent l’agilité de votre entreprise. Nous voyons les équipes monter à plusieurs versions par jour au lieu de publier aussi peu qu’une fois par trimestre.

Nous partageons également la préoccupation d’Ian selon laquelle les équipes Salesforce devraient conserver une documentation expliquant pourquoi des modifications ont été apportées, pas seulement quand et par qui. Les équipes utilisant Gearset génèrent automatiquement des pistes d’audit complètes avec tout ce qu’elles font, y compris tous les déploiements et tâches d’automatisation. Les chefs d’équipe peuvent également rendre les notes de déploiement obligatoires, de sorte que chaque changement dans l’historique de déploiement a une explication. Et pour les équipes utilisant le contrôle de code source, la documentation avec un historique complet des modifications des métadonnées n’est qu’une partie du processus.

DevOps pour Salesforce

De notre point de vue, tout ce qui précède plaide en faveur d’un développement basé sur la source et d’un DevOps automatisé. Nous sommes entièrement d’accord avec le diagnostic d’Ian concernant les problèmes courants rencontrés par les équipes qui s’appuient sur Salesforce et ses idéaux en matière de développement agile. Mais nous ne pensons pas que le développement en production soit nécessaire pour un développement agile; notre recommandation est d’adopter DevOps.

La mise en œuvre des meilleures pratiques DevOps ne signifie pas ajouter de la complexité inutile ou des obstacles au développement agile. Plutôt l’inverse! Il est conçu pour faciliter les pratiques de développement les plus robustes et les plus réactives. Des modifications déclaratives simples peuvent être expédiées toutes les quelques heures via un pipeline de versions hautement automatisé, tandis que les fonctionnalités plus complexes passent par un processus de test et de révision nécessairement robuste.

Chez Gearset, nous avons vu des équipes mûrir leurs processus DevOps et en récolter les fruits: réduire les temps de déploiement de 90%, augmenter les taux de réussite du déploiement à plus de 90% et augmenter les cadences de publication jusqu’à 17 fois à l’aide de nos outils d’intégration continue.



Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Voulez-vous utiliser Pardot à sa capacité maximale et avoir
+ DE LEADS QUALIFIÉS

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer