Suivez votre progression
Accueil Trailhead
Accueil Trailhead

Planification des modifications à apporter à votre organisation

Objectifs de formation

Une fois cette unité terminée, vous pourrez :
  • identifier l’environnement de développement à utiliser à chaque étape ALM lorsque vous travaillez dans le modèle de développement d’ensemble de modifications ;
  • créer une sandbox ;
  • mettre en place une méthode de suivi des modifications apportées dans une version.

Introduction

Si vous avez terminé le module Cycle de vie des applications et modèles de développement, vous avez déjà rencontré Calvin Green de Zephyrus Relocation Services (sinon, nous vous recommandons de le suivre avant de commencer ce module). Dans ce module, l’équipe de Zephyrus utilise le développement d’ensembles déclaratifs de modifications pour livrer une personnalisation Salesforce.

Calvin se tenant debout à son bureau au sein de Zephyrus, sa tasse de café Vetforce à la main.

Zephyrus souhaite proposer des services de formation linguistique à ses clients qui s’implantent à l’étranger. L’équipe de formation de l’entreprise comprend désormais des linguistes qui développent une vaste gamme de cours différents. Certains clients commencent l’apprentissage d’une nouvelle langue, tandis que d’autres ont simplement besoin de cours de rappel. D’autres encore désirent maîtriser un vocabulaire spécialisé, éventuellement pour le travail. De nombreux facteurs doivent être pris en compte lors de la recommandation d’un cours de langue à un client.

Calvin et son équipe décident d’utiliser le développement d’ensemble de modifications pour ajouter des informations relatives aux cours de langue à leur organisation.

Le cycle ALM : planifier la version, développer, tester, compiler la version, tester la version, publier

Rédaction de vos plans de publication

Calvin rédige son plan de publication afin que les personnes impliquées soient informées des avancées, évitant ainsi les risques de confusion. Il constate également qu’écrire les choses permet souvent de mettre la lumière sur des problèmes latents. Les attributions, les plans de tests, les décisions et les jalons sont plus faciles à étudier de façon concrète que lorsqu’ils restent abstraits. Calvin est conscient que rien n’est gravé dans le marbre : il compte réviser son plan tout au long de la publication en fonction des nouvelles informations disponibles.

Préparation des environnements de version

Lorsque vous planifiez une version, assurez-vous que les personnes qui y participent peuvent accéder aux environnements dont ils ont besoin à chaque étape du processus ALM. Calvin et son équipe utilisent le modèle de développement d’ensembles de modifications. Ils utilisent donc des environnements sandbox optimisés pour les tâches de chaque étape ALM. N’oubliez pas qu’une sandbox n’est qu’une copie de votre organisation de production dans un environnement séparé. Certaines sandbox ne contiennent aucune donnée de production, alors que d’autres en contiennent des quantités variables. Voici comment l’équipe de Calvin utilise des sandbox à chaque étape ALM.
  • Étapes de développement et de test : chaque membre de l’équipe dispose de sa propre sandbox Developer pour élaborer la personnalisation qui lui est attribuée. Les sandbox Developer ne contiennent aucune donnée de production.
  • Compilation de la version : chaque membre de l’équipe migre ses personnalisations depuis sa sandbox Developer respective vers une sandbox Developer Pro partagée en vue de l’intégration. Les sandbox Developer Pro ne contiennent pas de données de production, mais vous pouvez y intégrer des données test.
  • Test de la version : pour les tests d’acceptation utilisateurs, l’équipe utilise une sandbox Full afin de créer une copie conforme de la production. Une sandbox Full contient les données de production.
  • Publication : une fois la version en production, l’équipe peut utiliser la sandbox Full créée lors de la dernière étape pour former les utilisateurs sans exposer les données de production.

Les étapes du cycle de vie des applications : développement et test avec des sandbox Developer, compilation de la version avec une sandbox Developer Pro, test de la version avec une sandbox Full et mise en production

Création des environnements

Calvin commence par créer deux sandbox Developer : une pour lui-même et une pour sa collègue, Ella. Dans ces sandbox, Calvin et Ella élaborent et testent leurs personnalisations respectives. La création d’une sandbox pour chaque développeur permet à Calvin d’isoler les modifications jusqu’à ce que l’équipe soit prête à les intégrer.

Les sandbox sont disponibles dans les éditions Professional, Enterprise, Unlimited et Performance. Calvin montre à Ella comment créer une sandbox.

  1. Dans Configuration, saisissez Sandbox dans la case Recherche rapide, puis sélectionnez Sandbox.
  2. Cliquez sur Nouveau Sandbox.
  3. Saisissez le nom et la description du sandbox.
  4. Sélectionnez Developer comme type de sandbox.
  5. Cliquez sur Démarrer la copie.

La création de la copie peut prendre un certain temps, particulièrement si votre organisation de production contient beaucoup de données ou de personnalisations. Calvin reçoit un e-mail de notification lorsque la copie de la sandbox est terminée.

Calvin fait de même pour la création d’une sandbox Developer Pro en vue de l’intégration et d’une sandbox Full en vue des tests d’acceptation utilisateur et de la formation des utilisateurs.

Mise en place de votre méthode de suivi des modifications

Lorsque vous utilisez le modèle de développement d’ensemble de modifications, il est important de suivre chaque modification, en particulier les modifications nécessitant une migration manuelle. Lorsque vous migrez manuellement une modification, vous prenez des modifications d’un environnement et vous les recréez de manière identique dans un autre environnement. Vous devez migrer une modification manuellement si le composant modifié n’est pas encore pris en charge dans l’API de métadonnées.

Comment Calvin sait-il quels composants sont pris en charge dans l’API de métadonnées ? Le rapport Couverture des métadonnées vous indique les types de métadonnées pris en charge par l’API de métadonnées et d’autres canaux de métadonnées. Ce rapport est généré dynamiquement, et il constitue la meilleure source d'informations sur la couverture des métadonnées. Pour accéder au rapport Couverture des métadonnées, accédez à https://developer.salesforce.com/docs/metadata-coverage.

Calvin suit chaque modification et amélioration demandées par l’équipe commerciale. Il utilise un outil personnalisé qui permet aux développeurs de consigner chaque modification apportée dans le journal des modifications. Pour plus de sécurité, Calvin s’assure que l’outil dispose des champs comportant les informations cruciales sur chaque modification apportée à une version et les modifications apportées directement en production.

  • Qui est chargé d’effectuer la modification ?
  • Cette modification nécessite-t-elle une migration manuelle ?
  • Quel composant est touché par cette modification ?
  • Quelles organisations disposent actuellement de cette modification ?
  • Quand la modification a-t-elle été effectuée dans chaque environnement ?

Pourquoi Calvin suit-il les modifications apportées en production alors qu’elles ne font pas partie d’une version en développement ? C’est le seul moyen qui lui permet de s’assurer que les personnalisations déployées ne remplaceront pas ou ne modifieront pas de manière inattendue le comportement de l’organisation de production.

Presque toutes les modifications apportées par Calvin ou Ella à l’interface utilisateur de Salesforce sont consignées dans le journal d’audit de configuration. Calvin vérifie la concordance entre le journal d’audit et un rapport dans l’outil de suivi des modifications de l’équipe afin de ne manquer aucune modification.

Pour plus d’informations sur l’utilisation du journal d’audit de configuration, reportez-vous à Surveiller les modifications de configuration dans l’aide Salesforce.