Suivez votre progression
Accueil Trailhead
Accueil Trailhead

Comprendre ce qu’est la gestion du cycle de vie des applications

Objectifs de formation

Une fois cette unité terminée, vous pourrez :
  • Identifier les personnalisations pouvant être réalisées directement et en toute sécurité dans l’organisation de production.
  • Définir la gestion du cycle de vie des applications.
  • Expliquer pourquoi l’utilisation du processus de gestion du cycle de vie des applications permet aux équipes de développer des applications plus rapidement.

Introduction

Salesforce propose divers outils et processus de développement pour répondre aux besoins des clients. Ce module présente le processus de gestion du cycle de vie des applications (ALM) et les trois modèles de développement.
  • Développement d’ensembles de modifications
  • Développement organisationnel
  • Développement de packages

Globalement, les trois modèles de développement suivent le même processus ALM. Mais les modèles vous permettent de gérer les modifications apportées à votre organisation de différentes façons. La gestion des modifications est un enjeu important dans le développement logiciel. Vous pouvez choisir le modèle de développement le mieux adapté à votre situation si vous comprenez vos options.

Suivons le parcours d’un professionnel Salesforce et de son entreprise, confrontés à l’évolution des difficultés de développement au fil du temps. Au cours de ce récit, vous découvrirez comment chaque modèle de développement répond aux besoins de situations différentes. Les détails concernant l’utilisation des modèles de développement sont traités dans d’autres modules de ce parcours.

Remarque

Remarque

Dans des circonstances similaires, vous et votre équipe pourriez faire des choix différents de ceux de la société fictive présentée dans ce module. Le plus important est de connaître vos options.

Rencontrez Calvin, l’administrateur Salesforce chez Zephyrus Relocation Services, Inc.

Calvin Green assume de nombreux rôles techniques pour Zephyrus Relocation Services, une société de mobilité de talents basée à Fairfax, en Virginie aux États-Unis. L’un des rôles de Calvin consiste à personnaliser Salesforce pour l’équipe de vente à faibles effectifs, mais en pleine croissance. À l’aide de l’interface de configuration de l’organisation de production, il génère de nombreux nouveaux tableaux de bord et rapports différents.

Calvin a développé ses compétences en tant qu’administrateur Salesforce via Vetforce, le programme de formation professionnelle et d’accélérateur de carrière de Salesforce destiné aux membres des forces armées, aux anciens combattants et à leurs conjoints.

Calvin debout près de son bureau chez Zephyrus, tenant sa tasse à café Vetforce.

Que pouvons-nous changer en toute sécurité en production ?

Vous pouvez développer en toute sécurité de nouvelles fonctionnalités dans une organisation de production. Les personnalisations qui n’affectent pas les données peuvent être créées sans risque dans une organisation de production, par exemple le développement de nouveaux tableaux de bord, rapports et modèles d’e-mail. Mais certaines personnalisations effectuées directement en production peuvent semer le trouble en supprimant des données, voire pire.

Que se passe-t-il si vous ne testez pas les modifications avant de les publier en production ?

  • Une règle de workflow crée accidentellement une boucle de traitement infinie.
  • Une modification d’un type de champ modifie les données de manière irréversible.
  • Une erreur de logique dans une règle de validation vous empêche de sauvegarder un enregistrement.
  • Les changements de présentation de page désorientent davantage de utilisateurs qu'elles n'améliorent leur expérience.

Le moyen le plus sûr de personnaliser votre organisation consiste à effectuer et à tester des modifications au sein d’un environnement dédié au développement. En effet, certaines modifications doivent impérativement être effectuées dans un environnement de développement. Par exemple, vous ne pouvez pas écrire un code Apex directement dans une organisation de production.

Passer aux ensembles de modifications pour des personnalisations plus sûres

Alors que Zephyrus continue de croître, la demande de personnalisations Salesforce s’accroît elle aussi. La société ajoute un autre membre du personnel en soutien. Le nombre croissant de demandes de personnalisation inclut de nouvelles règles de workflow et de nouvelles présentations de page, et Calvin résiste judicieusement à la tentation de réaliser ces modifications directement dans l’organisation de production.

Pour répondre à ses besoins commerciaux en constante évolution, Zephyrus décide d’une mise à niveau vers la version Professional Edition. Dans la Professional Edition, Zephyrus peut créer et tester ses besoins à l’aide d’outils de développement déclaratifs (pointer-cliquer) dans un environnement de développement distinct.

Dans le modèle de développement des ensembles de modifications, Calvin et sa collègue Ella peuvent gérer leur application à l’aide d’outils déclaratifs. Ils n’ont pas besoin d’utiliser une interface de ligne de commande ou un logiciel de gestion de versions pour répondre aux besoins croissants de personnalisation de l’équipe de vente qu’ils prennent en charge.

Grâce aux outils déclaratifs, Calvin et Ella peuvent créer de nombreux éléments astucieux qui améliorent la productivité de l’équipe de vente. Par exemple, Calvin utilise le Générateur d’applications Lightning pour créer un filtre qui affiche un composant de texte enrichi sur une page d’opportunité lorsque le montant atteint au moins 1 million de dollars.

Utilisation du Générateur d’applications Lightning pour créer un filtre.

Appliquer un peu d’ordre au sein du chaos

Comme les personnalisations sont désormais réalisées par plusieurs personnes dans plusieurs environnements, Calvin réfléchit à la manière dont il peut gérer l’impact en aval de modifications, même mineures.

Par exemple, l'objet standard Contact ne dispose pas du champ Type de contact. Calvin peut facilement ajouter ce champ personnalisé et diffuser immédiatement le nouveau champ Type de contact à tous les utilisateurs. Mais est-il judicieux de le faire ?

  • Le nouveau champ Type de contact entre-t-il en conflit avec les personnalisations apportées par quelqu’un d’autre ?
  • L’équipe de vente sait-elle utiliser le nouveau champ ou devra-t-elle y être formée ?
  • Si le champ est nécessaire, les intégrations ou les processus d’importation doivent-ils être mis à jour ?
  • Où le champ apparaît-il ? Sur toutes les présentations de page ? Quelles vues de liste ? Est-ce qu’il apparaît dans les rapports ou les tableaux de bord ?
  • Le champ doit-il figurer également sur l’objet de piste ? Si oui, le processus de conversion des pistes change-t-il ?
  • Ce champ est-il nécessaire aux intégrations avec d’autres systèmes ? Si oui, vous devrez peut-être modifier les logiciels médiateurs, les mappages de champs, les points de terminaison, etc.

Dans la Trailblazer Community de Salesforce, d’autres membres encouragent Calvin à examiner les étapes de la gestion du cycle de vie des applications recommandées par Salesforce pour le développement d’applications nouvelles et personnalisées.

Sur le site Web Salesforce Developers, Calvin apprend qu’ALM définit le processus de gestion du développement d’une application, de la conception à la version finale. ALM crée également un cadre permettant de corriger les bogues d’application et d’améliorer les fonctionnalités au fil du temps.

Ajouter des processus ne ralentit-il pas le développement ?

Lors d’une réunion avec Ernesto Rondán, directeur du service informatique, Calvin plaide pour un passage à la gestion du cycle de vie des applications. ALM leur apporte les processus et les règles permettant de créer des applications sans heurts, et donc plus rapidement, sans rupture. Les applications et les outils peuvent varier, mais les étapes du cycle ALM concernent tous les projets de développement Salesforce.

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

Étape 1 – Planification de la version
Commencez par planifier votre projet de personnalisation ou de développement. Collectez les exigences et analysez-les. Demandez à votre responsable produit (ou équivalent) de créer les spécifications de conception et de les partager avec l’équipe de développement pour leur mise en œuvre. Déterminez les divers environnements de développement et de test dont l’équipe a besoin au fur et à mesure que le projet avance dans le cycle ALM.
Étape 2 – Développement
Réalisez le travail en respectant les spécifications de conception, et ce, dans un environnement contenant une copie des métadonnées de l’organisation de production, mais dépourvu des données de production. Travaillez sur la plate-forme Lightning en combinant des outils déclaratifs (générateur de processus, assistant d’objets personnalisés et autres outils de l’interface utilisateur) et des outils de programmation (Developer Console, éditeur de code source ou Visual Studio Code).
Étape 3 – Test
Testez les modifications que vous apportez pour vérifier qu’elles fonctionnent comme prévu avant de les intégrer au travail d’autres personnes. Ces tests doivent être réalisés dans le même type d’environnement que celui utilisé lors de l’étape de développement, tout en maintenant vos environnements de développement et de tests intégrés distincts. À ce stade, concentrez-vous sur le test de vos modifications elles-mêmes et non sur la compréhension de l’impact de vos modifications sur d’autres parties de la version ou sur l’application dans son ensemble.
Étape 4 – Compilation de la version
Regroupez tous les actifs que vous avez créés ou modifiés au cours de la phase de développement en un seul artefact, un ensemble logique de personnalisations que vous déployez en production. À partir de ce moment-là, concentrez-vous sur ce que vous allez publier, et non sur les contributions individuelles.
Étape 5 – Test de la version
Testez ce que vous allez réellement déployer, mais testez-le en toute sécurité, dans un environnement de transfert qui reproduit autant que possible la production. Utilisez une quantité réaliste de données de production représentatives. Connectez vos environnements de test à tous les systèmes externes dont ils ont besoin pour reproduire les points d’intégration de votre système de production. Exécutez la régression complète et les tests de performance finaux à cette étape. Testez la version avec un petit groupe de personnes expérimentées qui pourront en apporter des retours (technique appelée test d’acceptation de l’utilisateur).
Étape 6 – Publication
Lorsque vous avez terminé vos tests et atteint vos critères de qualité, vous pouvez déployer la personnalisation en production. Formez vos employés et partenaires au sujet de ces modifications. Si une version a un impact significatif sur l’utilisateur, créez un environnement distinct avec des données réalistes pour la formation des utilisateurs.