• Accueil / Salesforce / Un guide de…
, Un guide de l&rsquo;administrateur Salesforce sur DevOps<span class="wtr-time-wrap after-title"><span class="wtr-time-number">9</span> minutes de lecture</span>

Un guide de l’administrateur Salesforce sur DevOps9 minutes de lecture


Les organisations dépendent de plus en plus des systèmes numériques et font confiance aux équipes qui les entretiennent pour fournir de l’innovation sans risquer de perdre du temps. Salesforce fournit une plate-forme extrêmement stable qui permet aux administrateurs sans code d’innover rapidement pour répondre aux besoins changeants de l’entreprise.

La portée et la complexité de la plupart des organisations Salesforce ont atteint une échelle telle qu’elles ne peuvent plus être gérées efficacement sans un processus de déploiement, de test et de collaboration mature. La communauté DevOps est devenue un lieu de rassemblement pour les idées et les pratiques les plus sophistiquées autour de systèmes informatiques évolutifs à grande échelle. Ces pratiques sont de plus en plus adoptées par les équipes qui gèrent les instances Salesforce; mais ils comptent sur l’utilisation contrôle de version et d’autres processus qui sont inconnu de la plupart des administrateurs sans code.

Définition de DevOps

De nombreuses personnes dépendent de votre organisation Salesforce pour effectuer leur travail, il n’est donc pas judicieux d’apporter des modifications de configuration directement en production. Les petites équipes effectuant un nombre modéré de modifications utilisent souvent des ensembles de modifications ou migrent manuellement les modifications des bacs à sable vers la production. Mais le processus est fastidieux et sujet aux erreurs. DevOps est un terme utilisé pour décrire un ensemble complet et réfléchi de pratiques et d’attitudes qui permettent aux équipes de migrer les modifications du développement vers la production avec frottement et gaspillage minimaux. C’est un sujet important, mais qui englobe toutes les personnes, tous les processus et tous les outils utilisés pour gérer le cycle de vie du développement.

Si votre entreprise a investi dans un outil de gestion des versions convivial comme Copado, considérez-vous chanceux – vous pouvez devenir une superstar DevOps avec des clics, pas du code! Si votre entreprise adopte une approche plus traditionnelle consistant à utiliser directement le contrôle de version et les outils de CI à usage général, ne vous inquiétez pas. Vous avez l’opportunité d’apprendre des outils puissants et flexibles qui sont couramment utilisés par les équipes travaillant sur une vaste gamme de technologies.

Le rôle joué par les outils DevOps

DevOps implique un processus (passage du développement à la production), il est donc important d’apprécier le avantages de ne pas faire de changements directement dans la production. Votre travail consiste alors à accéder à un environnement de développement, à apporter et à capturer vos modifications à partir de cet environnement afin qu’elles puissent être envoyées via le processus de déploiement et de test, et de participer à l’amélioration progressive de ce processus.

Un adage commun est que les outils DevOps sont beaucoup moins importants que le changement de culture impliqué. Ce qui compte, c’est que tous ceux dont le travail a un impact sur votre organisation de production soient capables de collaborer sur des systèmes communs et qu’il y ait un sens partagé de la responsabilité pour permettre l’innovation et réduire les risques et la confusion.

Ne pas renvoyer le contrôle de version

Pour accéder à un environnement de développement, il peut être nécessaire d’utiliser un sandbox de développement partagé ou d’exécuter des commandes pour cloner un sandbox ou une organisation scratch de courte durée. Dès que vous commencerez à travailler dans un environnement de développement, vous comprendrez pourquoi les développeurs font tant de bruit lorsque ces environnements ne sont pas synchronisés avec la production.

Faire vos propres modifications (créer des champs, utiliser App Builder, etc.) est la partie dans laquelle vous êtes déjà doué. C’est la partie créative de votre travail, et c’est tout naturellement que vous renvoyer tous les frais généraux impliqués dans la capture de vos modifications du contrôle de version. Mais si vous n’avez pas passé beaucoup de temps (ou pas du tout) à écrire du code, il est extrêmement utile de commencer à exploiter le processus consistant à voir votre configuration représentée sous forme de XML et à suivre et comparer votre travail de contrôle de version aux côtés des développeurs.

L’écart entre les développeurs et les non-développeurs

Il y a une énorme mystique autour de la programmation. La culture populaire perpétue cela, tout comme les développeurs, qui apprécient l’air de mystère et l’exclusivité de faire un travail qui semble si étranger aux autres. Mais écrire du code, ce n’est qu’écrire. Les éditeurs de code ne sont pour la plupart que des éditeurs de texte. Et l’écart entre les codeurs et les non-codeurs n’est que l’écart entre ceux qui sont alphabétisés dans une langue particulière et ceux qui ne le sont pas. Pensez à vous familiariser avec le code comme à développer une connaissance de base du code. Tout comme les taux d’analphabétisme baissent dans le monde (voir la figure ci-dessous), la maîtrise du code vous sera également très utile dans le monde moderne.

, Un guide de l&rsquo;administrateur Salesforce sur DevOps<span class="wtr-time-wrap after-title"><span class="wtr-time-number">9</span> minutes de lecture</span>

L’analphabétisme mondial a diminué de moitié entre 1970 et 2015

Étonnamment, le code fonctionne comme un langage universel. Mais c’est un domaine dans lequel les ordinateurs vous indiquent si vous l’avez écrit correctement ou non. Cela le rend bien adapté aux introvertis qui sont heureux d’apprendre sans interaction humaine. Mais même les codeurs expérimentés ont du mal et échouent comme de petits enfants lorsqu’ils apprennent pour la première fois un nouveau langage ou une nouvelle technique de programmation. Leurs pairs peuvent penser qu’ils ont des compétences surhumaines mais, en privé, même les développeurs les plus brillants utilisent des exemples «Hello World» et parcourent minutieusement des extraits de code pour se lancer dans les nouvelles technologies.

À mon avis, ce qui distingue les programmeurs, c’est seulement qu’ils ont la patience, la confiance et la motivation nécessaires pour travailler à travers ce processus d’apprentissage encore, et encore, et encore. Même une petite expérience de l’utilisation de Git et de l’exécution de scripts de ligne de commande peut vous donner l’assurance que le code n’est pas un monde étrange et inaccessible.

Administrateurs: il est temps de s’impliquer

Les meilleurs administrateurs Salesforce que je connais sont ravis et fiers d’acquérir une petite expérience du code et de la ligne de commande. Une telle expérience ouvre la possibilité de plonger plus profondément dans le codage, même si vous choisissez de ne pas le faire.

Si vous surmontez cette bosse et que vous vous sentez à l’aise pour suivre vos modifications de configuration dans le contrôle de version, vous êtes plus ou moins libre. Si votre équipe a mis en place un moteur CI et un pipeline de livraison, le suivi de votre travail dans le contrôle de version est le seul processus obscur et manuel que vous ayez à faire. Les ordinateurs feront le reste du travail, exécutant des déploiements et des tests automatisés.

Faire face aux erreurs de déploiement

Vous devrez faire face erreurs de déploiement. Mais vous y feriez face même si vous travailliez avec des ensembles de modifications. Et vous devrez peut-être faire face à des conflits de fusion Git. Les conflits de fusion pour la plupart des types de métadonnées ne sont pas difficiles à résoudre, en particulier à l’aide d’un éditeur de code tel que VS Code. Mais les conflits de fusion pour les profils et certains autres types de métadonnées peuvent être très laids. Cela vous aidera à comprendre pourquoi Salesforce encourage de plus en plus l’utilisation d’ensembles d’autorisations à la place.

Test automatisé et couverture du code

Enfin, une fois que vous participez à ce pipeline de diffusion, vous partagez la responsabilité de le maintenir en marche et de l’améliorer. L’amélioration signifie principalement l’amélioration des tests automatisés. Les outils de test que votre équipe utilise peuvent varier de ceux axés sur les développeurs à ceux adaptés aux administrateurs. Les outils de test d’interface utilisateur tels que Provar, Selenium et Tosca sont conçus pour être plus accessibles que les tests basés sur du code. Si vous avez la possibilité d’aider à créer ou à spécifier ces tests, vous contribuez à garantir que les modifications que vous apportez seront protégées au fil du temps.

La logique que vous intégrez dans un processus ou un flux peut être tout aussi complexe que la logique dans un morceau de code. Salesforce a commencé à appliquer les exigences de couverture de code même sur les flux et les processus, ce qui est une décision intéressante qui confirme l’opinion de Salesforce selon laquelle les tests automatisés sont essentiels. Encouragez vos développeurs à rédiger leurs tests unitaires de manière flexible afin que les entrées et sorties attendues puissent être réglées facilement. Les tests de style BDD (Behavior Driven Development) sont censés avoir des entrées et des sorties lisibles par l’homme. Cela facilite la création de plusieurs variantes d’un test pour examiner la logique métier par rapport à différents cas extrêmes. Si les développeurs écrivent des tests de manière modulaire, vous pouvez facilement copier et coller un seul test et ajuster les entrées et les sorties attendues pour aider à valider la logique de vos processus, flux, flux de travail ou règles de validation. S’essayer aux tests unitaires est l’un des moyens les plus simples et les moins risqués de commencer à coder, car ils n’ont aucun impact sur le comportement de l’organisation.

Résumé

Le but d’adopter cette approche est de rassembler les administrateurs et les développeurs dans un système commun cela leur permet d’expérimenter avec moins de risque d’impacter les utilisateurs de production. Même les experts Salesforce vont parfois se tromper. Si vous n’êtes pas familiarisé avec le travail dans une organisation de développement, cela signifie que chaque expérience que vous effectuez met en péril vos données, vos utilisateurs et leur affection pour vous. Travailler sur un pipeline de livraison commun est un investissement dans la collaboration et la gouvernance qui vous donne plus de raisons de parler aux équipes de développement et vous permet de construire avec rapidité et de livrer en production en toute confiance.



Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

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

Fermer