Conception d’une nouvelle source d’informations fiables

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

• Décrire en quoi les modèles de développement organisationnel diffèrent du développement de packages modulaires
  
• Énumérer les avantages du développement de packages
  
• Décrire les principales caractéristiques d’un package
  

Le monde entier est une organisation

Un comédien célèbre, ou peut-être un visionnaire de Salesforce, a dit un jour ceci : « Le monde entier est une organisation ». Traditionnellement, le centre de ce monde est votre organisation de production, et vous avez réalisé une grande partie de votre développement dans les limites d’une sandbox ou d’une organisation de production. (Si vous êtes un partenaire AppExchange, votre monde est quelque peu différent. Cependant, les outils présentés dans cette unité sont également à votre disposition, alors poursuivez votre lecture.)

Gestion traditionnelle du changement

Si vous avez suivi le module Modèle de développement organisationnel, vous vous souvenez peut-être de Calvin Green, l’administrateur de Zephyrus Relocation Services. Au fur et à mesure que Zephyrus se développait, la complexité de son organisation de production augmentait. Afin de répondre à ce changement croissant, il a commencé à adopter les outils de développement modernes de Salesforce pour gérer le cycle de vie des applications de son équipe.

Voyons comment votre équipe de développement pourrait travailler à l’aide du modèle de développement organisationnel.

Vous êtes un responsable du développement pour une entreprise de hautes technologies en évolution rapide. Dans le cadre de la publication d’une version, vous devez personnaliser l’application CRM principale et vous souhaitez également créer une application interne pour votre entreprise. La première étape du développement consiste à vous assurer que vous disposez du cliché instantané le plus à jour de votre organisation de production. Dans le modèle fondé sur l’organisation, votre organisation de production est la source d’informations fiables pour l’ensemble de votre code, votre configuration et vos personnalisations.

Peu importe ce que vous élaborez, vous créez en fin de compte des déploiements adaptés à votre organisation de production. Comme vous le voyez sur le diagramme, même si plusieurs équipes travaillent sur des projets de développement distincts, elles développent et publient leurs mises à jour via le même déploiement. Tout se retrouve dans un seul et même fichier package.xml.

Pour la première version, supposons que vous travaillez sur deux nouveaux projets :

Pour la deuxième version, vous effectuez quelques mises à jour mineures. Cependant, vous continuez à publier et à déployer les deux projets en même temps dans l’organisation de production :

Vos développeurs et responsables de versions considèrent l’organisation comme un ensemble enchevêtré de code et de personnalisations. Pour bien comprendre, regardez à nouveau le diagramme. Le déploiement final n’est pas restreint à l’application de gestion des congés ou uniquement aux extensions du CRM : il inclut toutes les modifications apportées à l’organisation.

Au fur et à mesure que vous effectuez votre travail de développement, vous devez suivre ce que vous modifiez pour vous assurer que vous savez quoi déployer dans l’organisation de production. Vos modifications se mêlent à celles d’autres personnes, ce qui rend le processus délicat et quelque peu manuel. Si vous utilisez le contrôle source dans ce processus, ce même principe d’enchevêtrement de code et de personnalisations se retrouve dans le système de contrôle de source. Vous alignez votre référentiel source sur l’organisation plutôt que sur une partie de cette dernière (par exemple, l’application de gestion des congés).

Toutefois, comment procéder si vous constatez que cet enchevêtrement d’éléments devient trop complexe et que vous avez besoin d’une meilleure façon de gérer les modifications ? Êtes-vous à la recherche d’un modèle de développement plus traditionnel à suivre pour fournir et publier des applications et des solutions ?

Gestion du changement grâce au développement de packages

Au fur et à mesure que la croissance de Zephyrus se poursuivait, ses versions devenaient de plus en plus complexes. Avec l’aide de plusieurs équipes de développement et plusieurs administrateurs Salesforce, Calvin souhaitait trouver un moyen de dissocier les projets de l’imposant processus de publication des versions. Le modèle de développement de packages rationalise l’ensemble du cycle de vie de développement et s’accompagne notamment des avantages suivants :

• L’amélioration du développement et de la collaboration en équipe.
  
• La mise en place d’un processus de développement modulaire avec une spécification des dépendances entre les packages.
  
• L’instauration de la gestion des versions pour faciliter la conduite du changement.
  
• La facilitation de la mise en œuvre des tests automatisés et de l’intégration continue.
  
• Le renforcement de l’efficacité et de l’agilité du cycle de publication.
  
• L’amélioration de la synchronisation du système de contrôle de version (VCS) grâce au suivi des modifications des fonctionnalités de configuration.
  
• Une visibilité et une clarté accrues sur la conduite du changement au sein de votre organisation de production.
  

Qu’est-ce que cela signifie ? Au lieu de créer du code et des personnalisations pour l’organisation, vous créez un package (un ensemble logique de code). Un package est un artefact de version constitué d’un groupe de code et de personnalisations associés.

Le regroupement de composants au sein d’un package peut représenter beaucoup de choses. Le package peut être un ensemble de personnalisations créées pour appuyer l’activité d’une équipe commerciale. Un package peut être constitué des composants Lightning, des objets et des flux de travail relatifs à une application en cours de création dans l’organisation. Un package peut être constitué des extensions que vous créez autour d’un package géré que vous avez installé à partir d’AppExchange.

Grâce à ce nouveau processus, vous pouvez organiser votre organisation en un ensemble de packages. En organisant votre source et vos métadonnées en packages, vous comprenez mieux les relations entre les composants de métadonnées de votre organisation. Plus votre organisation se développe, plus ce processus devient important, alors anticipez et réfléchissez sans cesse à la manière d’organiser votre organisation.

Un VCS est le meilleur allié du développeur et joue un rôle essentiel dans le cycle de vie du développement de packages. Vous stockez l’ensemble des sources de vos packages au sein d’un référentiel de contrôle source, où la source d’informations fiables est gérée. Vous créez des organisations test (de développement) à partir de cette source, afin de pouvoir travailler spécifiquement sur votre package. Nous fournissons des fonctionnalités de suivi des modifications pour que vous puissiez surveiller ce que vous avez créé, mis à jour et supprimé dans l’organisation de développement. Vous pouvez facilement transférer cette source modifiée vers votre système de fichiers et l’archiver dans votre VCS.

Le développement de packages vous offre plus de flexibilité dans la gestion de vos équipes et de vos versions. Vous pouvez affecter des équipes à un package particulier. Les équipes de développement peuvent travailler indépendamment les unes des autres et préparer une version du package au lieu d’une version de mises à jour de l’organisation. Avec ce modèle agile, vous pouvez produire des versions indépendantes plus fréquemment, comme vous pouvez le constater dans le flux de développement, de création et de déploiement.

Pour nos clients entreprises, nous proposons un type de package spécial, appelé package déverrouillé, qui est particulièrement adapté aux applications professionnelles internes.

Flexibilité offerte par les packages déverrouillés

Examinons en quoi les packages déverrouillés changent la façon dont nous publions les personnalisations du CRM et de l’application de gestion des congés.

Dans cet exemple, pour la première version, vous créez deux projets. Ces derniers sont tous deux dans leur version 1.0 et peuvent être créés, puis déployés séparément sur l’organisation de production à l’aide de l’API de métadonnées.

Dans le cadre de la prochaine version, vous pourrez à nouveau créer et déployer chaque version de package indépendamment dans l’organisation de production. De cette façon, vous pouvez conserver des versions distinctes et différentes pour chaque artefact de version (package).

Ce processus s’étend également aux environnements d’intégration continue (CI) et de livraison continue (CD). La création de packages vous permet d’élaborer des plans de test conçus spécifiquement pour le projet. Vous pouvez automatiser le plan de test pour garantir un niveau de qualité constant en exécutant des tests dans plusieurs environnements au fur et à mesure que la source est modifiée via le VCS.

Ressources

• Guide du développeur : Référence de commande de la Salesforce CLI
• Guide du développeur : Guide du développeur Salesforce DX
• Trailhead : Quick Start: Salesforce DX
• Trailhead : Packages déverrouillés pour les clients