• Accueil / Salesforce / Comment créer un…
, Comment créer un pipeline DevOps réussi pour Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">13</span> minutes de lecture</span>

Comment créer un pipeline DevOps réussi pour Salesforce13 minutes de lecture


Dans « Salesforce DevOps : Learning from 300+ Salesforce Deployments », j’ai détaillé mon expérience d’utilisation de DevOps avec Salesforce pour mener à bien des projets. Nous avons couvert des modèles de mise en œuvre typiques, ainsi que la façon de choisir les bons mécanismes de déploiement et l’importance du contrôle de version. Dans cet article, nous approfondirons encore plus les leçons apprises au cours de mon parcours pour créer un pipeline DevOps.

Qu’est-ce qu’un pipeline DevOps ?

Un pipeline DevOps est un ensemble de pratiques, de processus et d’outils que les équipes (développement et opérations) utilisent pour créer, tester et déployer des logiciels. Un pipeline DevOps garantit que le développement logiciel est organisé de manière efficace et minutieusement testé pour éviter des erreurs coûteuses.

, Comment créer un pipeline DevOps réussi pour Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">13</span> minutes de lecture</span>

Mon parcours DevOps

Alors, comment la création d’un pipeline DevOps est-elle devenue une partie si importante de mon rôle, et pourquoi pourriez-vous également en avoir besoin ?

Mon équipe et moi travaillions sur un projet avec un délai extrêmement serré et fixe. L’équipe travaillait également à travers les lieux et les fuseaux horaires, donc la communication et la collaboration allaient être essentielles à notre succès. Nous avons réalisé que notre processus de déploiement traditionnel consistant à utiliser des ensembles de modifications ou ANT n’allait pas nous aider à respecter nos délais stricts. Nous avons décidé que nous devions créer un pipeline DevOps que nous pourrions utiliser dans nos déploiements quotidiens.

Un pipeline DevOps nous aiderait à :

  • Fusionner le code dans un référentiel central
  • Mettre en place la configuration et la gestion de l’infrastructure
  • Mettre en œuvre le contrôle de version
  • Automatiser les tests
  • Surveiller et contrôler les déploiements à partir d’un appareil mobile
  • Assurer la qualité du code
  • Facilitez la communication avec l’équipe

Outils utilisés lors de notre implémentation DevOps

1. Système de contrôle de version (VCS)

Le contrôle de version garde une trace des modifications apportées au code ; s’il y a des problèmes, le contrôle de version nous aide à comparer la base de code avec la version précédente, puis à localiser et à résoudre le problème. Nous avons utilisé « Git » comme notre VCS puisque notre client avait ses autres projets sur Git.

2. Stratégie de branchement

Une stratégie de branchement est une convention, ou un ensemble de règles, qui décrit quand les branches sont créées, les directives de nommage pour les branches, l’utilisation que les branches devraient avoir, etc.
Ce fut la partie la plus difficile de notre implémentation DevOps et je voudrais souligner quelques avantages d’une bonne stratégie de branchement :

  • L’annulation des modifications devient plus facile
  • Les problèmes de remplacement de code seront considérablement réduits et, en cas de problème, nous pouvons facilement annuler les modifications
  • Aide à déployer tout changement indépendamment des autres changements

Nous avons suivi une stratégie de branchement basée sur les fonctionnalités qui était le résultat de notre discussion avec l’équipe. Dans cette stratégie de branchement, nous avions les branches suivantes :

  • Fonctionnalité – pour chaque fonctionnalité / ticket JIRA, les développeurs créent une nouvelle branche à partir du master
  • Développer – branche active où nous fusionnons nos changements quotidiens
  • Libérer – avant de passer nos modifications en production, nous les fusionnons d’abord dans la version
  • Maître – réplique de ce que nous avons en production

Flux de stratégie de branchement :

, Comment créer un pipeline DevOps réussi pour Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">13</span> minutes de lecture</span>

3. Bac à sable / Arrangement d’organisation

Salesforce fournit différents types d’environnements pour le développement, les tests, la correction de bogues, etc., appelés sandbox. Chaque client Salesforce, en fonction de la complexité de la mise en œuvre, utilise les sandbox différemment. Cela peut être aussi simple qu’un seul bac à sable utilisé pour faire du développement et des tests et cela peut être complexe avec plusieurs organisations utilisées. Dans notre cycle de développement, nous avons 5 environnements différents dans lesquels chacun a son propre objectif. Ceux-ci sont expliqués ci-dessous :

Nom de l’organisationObjectif
DEVLes développeurs l’utiliseront pour faire du développement. Cela devrait idéalement être une organisation de travail et non un bac à sable.
TEST DE L’UNITÉUne fois que le développeur a fusionné son code dans Develop, les modifications sont déployées dans ce bac à sable où un développeur testera ses modifications.
AQ / SIT / UATUtilisé par l’équipe d’assurance qualité pour effectuer les tests.
PREPRODAvant la production, les modifications de version sont déployées et testées ici. Idéalement, cette organisation est un bac à sable à copie complète. Très utile pour reproduire les problèmes de production pour fournir un correctif.
PRODOrganisation en direct.

Flux de pipeline

Lors de notre première itération, nous avons implémenté DevOps comme indiqué dans le schéma ci-dessous :

, Comment créer un pipeline DevOps réussi pour Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">13</span> minutes de lecture</span>
  1. Demande de changement (CR) ou bogue créé.
  2. Le développeur crée une branche de fonctionnalité à partir d’un expert pour ce CR ou ce bogue en utilisant le numéro de ticket.
  3. Le développeur valide ses modifications dans la branche de fonctionnalité.
  4. Le développeur crée une pull request à partir de sa fonctionnalité. Branche pour développer la branche et assigne le réviseur.
  5. L’examinateur effectuera les opérations suivantes :
    • une. Examen du code
    • b. Demander des modifications
    • c. Fusionner les modifications dans la branche de développement
  6. Une fois les modifications fusionnées, le pipeline DevOps sera déclenché et il commencera à déployer les modifications sur l’organisation UNITTEST.
  7. ASTUCE – S’il ne s’agit que de déployer des changements, quel est l’avantage de DevOps ? C’est peut-être la question que vous vous posez.

    Donc, pour répondre à cela : le pipeline DevOps ne fera pas que du déploiement ; il peut être configuré pour faire beaucoup de choses qui sont particulièrement importantes dans SDLC :

  • une. Notification sur divers canaux pour informer les personnes concernées que le déploiement est déclenché (dans notre cas, nous avons envoyé une notification sur Slack).
  • b. Intégration avec l’outil d’analyse de code statique – les choses évidentes qui pourraient mal tourner peuvent être suivies à l’aide de cet outil. Cela aidera également à avoir une bonne qualité de code.
  • c. Déploiement des modifications dans l’organisation UNITTEST.
  • ré. Intégration avec les suites de tests d’automatisation – des cas de test automatisés sont exécutés pour rechercher s’il existe des problèmes de régression.
  • Après cela, le développeur effectuera des tests unitaires dans l’organisation UNITTEST.
  • S’il n’y a pas de problèmes, le déploiement sera approuvé pour le bac à sable QA / SIT / UAT, sinon le développeur corrigera tous les problèmes et fusionnera à nouveau ses modifications dans la branche de développement.
  • Une fois la demande de modification testée et approuvée par l’équipe QA/Business, les fonctionnalités sont fusionnées avec la branche de publication.
  • Toutes les étapes mentionnées de 6.a à 6.d seront exécutées et le déploiement vers la préprod sera effectué.
  • Le test de santé mentale sera effectué dans PREPROD. Le responsable des versions lancera une demande d’approbation s’il n’y a pas de problèmes lors des tests de validité.
  • Le gestionnaire de versions fusionnera les modifications apportées à la branche principale, ce qui déclenchera le pipeline de production.
  • Déploiement en production.
  • Après avoir mis en œuvre notre premier pipeline qui nous a aidés à effectuer des déploiements transparents, il était temps de l’améliorer pour réduire certains défis auxquels les développeurs pourraient être confrontés lors du déploiement.

    Nos fonctionnalités de pipeline DevOps

    Comme expliqué ci-dessus, sur la base de nos apprentissages, nous avons construit un pipeline DevOps pour les déploiements Salesforce. Nous avons ensuite ajouté quelques fonctionnalités clés à notre pipeline, décrites ci-dessous, qui nous ont beaucoup aidé lors des déploiements.

    Déploiement complet

    Le déploiement complet consiste à déployer tous les composants d’une branche vers l’instance Salesforce. Vous trouverez ci-dessous quelques caractéristiques clés d’une tâche de déploiement complet :

    1. Utilisé uniquement pour les bacs à sable.
    2. Les travaux de nuit sont exécutés.
    3. Assurez-vous que tous les bacs à sable sont coordonnés avec la branche de développement en remplaçant les modifications directes apportées par tout développeur ou administrateur dans le bac à sable QA/UAT.
    4. Exécutez toutes les classes de test – cela permet de garder un contrôle de nos classes de test. Il y a des chances que les classes de test échouent en raison des récents changements introduits. Les organisations complexes prennent beaucoup de temps pour exécuter des classes de test, ce qui ne peut pas être fait pendant les heures de travail. Ainsi, cela informera le développeur et il pourra prendre les mesures nécessaires.

    Déploiement incrémentiel

    Le déploiement incrémentiel ne déploie que les composants qui ont été modifiés depuis la dernière validation réussie sur la branche cible :

    1. Utilisé pour les bacs à sable ainsi que pour la production.
    2. Utilisé pour tous les déploiements quotidiens.
    3. Les déploiements sont plus rapides car moins de composants doivent être déployés.
    4. Cette fonctionnalité consiste à ne sélectionner que les composants de notre branche qui ont été modifiés depuis notre dernier déploiement réussi. Lorsqu’un développeur valide ses modifications de fonctionnalité, le développeur n’a pas à fournir de fichier manifeste (package.xml). Notre workflow récupère automatiquement les composants et les déploie.

    Pourquoi est-ce utile ? Le développeur gère un fichier manifeste (package.xml) pour conserver une liste de ses modifications. Lorsqu’il est nécessaire de faire des déploiements d’une organisation à une autre, ceux-ci peuvent alors être utilisés. Avec cette fonctionnalité, vous n’avez pas à vous soucier de la gestion d’un fichier manifeste pour le déploiement des modifications dans différentes organisations. Les fichiers manifestes ne seront nécessaires que pour valider ses modifications dans les branches de fonctionnalités. Le pipeline DevOps s’occupera du reste.

    Gestion des classes de test

    Les déploiements Salesforce nécessitent une exécution réussie des classes de test et la couverture du code doit être supérieure à 75 %. Salesforce nous propose 4 options pour exécuter des classes de test lors du déploiement de nos modifications :

    1. Défaut
    2. Exécuter des tests locaux
    3. Exécuter tous les tests
    4. Exécuter des tests spécifiques

    Peu de questions se posent dans l’esprit des développeurs à propos des classes de test :

    1. L’exécution des classes de test est-elle requise ou non ?
    2. Quelle option de test parmi les 4 options doit être choisie pour le déploiement ?
    3. Quelles classes de test exécuter ?

    Vous trouverez ci-dessous quelques considérations lors de l’exécution de classes de test.

    1. Exécuter des classes de test spécifiques

    Lors des déploiements à l’aide d’ensembles de modifications ou d’ANT, si le développeur utilise l’option « Exécuter des tests spécifiques », le développeur doit maintenir une liste des classes de test qui doivent être exécutées pour procéder au déploiement. Notre pipeline est suffisamment intelligent pour trouver les classes de test à exécuter. Cela a réduit la charge de travail des développeurs de maintenir une liste de classes de test à exécuter. Les développeurs devront effectuer un mappage unique de la classe apex et de la classe de test dans un fichier json. Et puis notre pipeline fera le reste du travail pour le développeur.

    2. Quand exécuter des cours de test

    Lors du déploiement de nos modifications, si nous spécifions le niveau de test comme « Par défaut », Salesforce décide d’exécuter ou non des classes de test, en fonction de ce qui est déployé. C’est bien si nous déployons des mises en page, des modèles d’e-mails, des pages flexibles, etc.

    Nous maintenons maintenant un ensemble de types de composants pour lesquels le système doit obligatoirement exécuter des classes de test. Cet ensemble de types de composants peut être modifié en fonction de nos besoins. Cela nous aidera à éviter les problèmes de régression dans le système qui pourraient être introduits en marquant un champ obligatoire, en ajoutant une règle de validation, des exceptions non gérées dans les générateurs de processus sur un objet principal, etc.

    3. Classes d’examen obligatoires

    Malheureusement, il n’est pas rare qu’il y ait des changements de personnel au cours d’un projet, et il est impossible pour un développeur d’être au courant de tous les points de contact du système. Avoir de la documentation aidera le développeur à tout comprendre simplement en lisant. Afin d’effectuer des vérifications de régression/de bon sens, nous avons maintenu un ensemble de classes de test qui ne devraient s’exécuter pour chaque déploiement que si l’exécution de la classe de test est requise sur la base d’une fonctionnalité précédente. Ces classes de test garantiront que les changements n’affectent pas le cœur de notre système.

    Nous avons maintenant ajouté une fonctionnalité dans notre pipeline DevOps qui trouvera la liste des classes de test à exécuter pour ce déploiement. Nous maintenons également un fichier json qui a un mappage d’une classe et sa classe de test qui est utilisé par notre workflow pour trouver des classes de test. Vous pouvez fournir plusieurs classes de test pour une classe.

    Résumé

    Ce n’est pas la fin! Nous améliorons toujours notre pipeline DevOps pour ajouter plus d’avantages. Quelques exemples de plans passionnants, actuellement toujours en cours d’exécution, incluent :

    • Génération de notes de version – nous pouvons obtenir une liste des composants qui sont modifiés dans ce déploiement dans un document.
    • Documentation des codes – nous avons fait un PoC pour cela. C’est possible : nous devons suivre certains formats lorsque nous ajoutons des commentaires dans notre code.
    • Analyse de code statique – nous l’utilisons pour faire des analyses mais pas pour prendre des mesures. Nous essaierons d’utiliser davantage cet outil pour appliquer certaines règles qui amélioreront la qualité du code.

    Nous avons travaillé là-dessus au cours de la dernière année, au cours de laquelle nous avons été confrontés à de nombreux problèmes et avons certainement commis des erreurs en cours de route ! Cependant, nous sommes maintenant fiers d’avoir notre pipeline DevOps prêt à fonctionner et nous continuons à ressentir beaucoup d’enthousiasme pour nos plans d’amélioration future.



    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