Décomposez vos métadonnées
Objectifs de formation
Une fois cette unité terminée, vous pourrez :
- Décrire comment les clients d’entreprise utilisent les packages déverrouillés
- Décrire comment le développement de packages est différent du développement d’ensembles de modifications
- Décrire comment vous déployez des métadonnées à l'aide de packages.
Pourquoi le développement de package est l’avenir ?
Si vous avez terminé le module Modèle de développement de package, vous savez que le développement modulaire basé sur les packages change la donne. Mais peut-être vous demandez-vous comment mettre en pratique ces principes ? Comment ce modèle modulaire me facilite-t-il la vie ?
Que vous soyez un nouveau venu sur la plate-forme ou un professionnel chevronné, l'empaquetage est fait pour vous. En tant que client de longue date, plus vous personnalisez et construisez sur la plate-forme, plus vous apportez de la complexité dans votre organisation. Votre seule organisation Salesforce est devenue un énorme conteneur pour toutes les métadonnées que vous gérez et avec lesquelles vous interagissez. Nous appelons cette corne d'abondance votre « soupe heureuse ».
Si vous avez récemment déployé des personnalisations Salesforce, vous avez déployé des métadonnées dans des organisations de production à l’aide d’ensembles de modifications ou même de packages non gérés. Ce modèle de développement traditionnel est ce que nous appelons le développement d’ensembles de modifications. Votre développement s'est produit principalement dans les limites d'une sandbox ou d'une organisation de production.
Le cycle de vie de l’application de développement d’ensembles de modifications consiste à déplacer les modifications d’organisation entre les environnements de test et de développement jusqu’à ce que ces modifications soient publiées dans votre organisation de production. Mais en fin de compte, la « source de vérité » est l'organisation de production. Même si vous suivez les modifications de manière externe dans un système de contrôle de version, vous savez avec certitude que tout se trouve dans votre organisation.
Désormais vous avez plus d’options ! Dans le modèle de développement de package, la source de vérité nouvelle et améliorée est votre système de contrôle de version. Vous utilisez les projets Salesforce DX pour organiser votre source dans les répertoires de packages. Votre but final est de créer des packages en utilisant les répertoires qui peuvent être modifiés, faciles à maintenir, à mettre à jour, à installer et à mettre à niveau.
Ceci étant dit, passer au développement de package n'est pas une proposition à prendre ou à laisser. Nous allons dissiper le mystère et vous montrer comment commencer.
Qu’est-ce qu’un package ?
Si vous découvrez l'empaquetage, vous pouvez considérer un package comme un conteneur que vous remplissez avec des métadonnées. C'est une unité de fonctionnalité distribuable.
Imaginez que vous avez créé une application personnalisée pour vos employés afin de faire le suivi des dépenses. Vous avez inclus des objets personnalisés, des classes Apex, des composants Lightning, etc. Dans le modèle de développement d'ensemble de modifications, toutes les métadonnées appartenant à cette application personnalisée sont contenues dans votre organisation Salesforce. Mais elles ne sont ni isolées ni organisées de manière à faciliter leur mise à niveau et leur maintenance. Dans le modèle de développement de packages, vous organisez ces métadonnées dans des conteneurs bien définis appelés packages.
Désormais, vous ne serez pas surpris de savoir que les raisons les plus convaincantes d'utiliser les packages sont les métadonnées, et plus précisément l'organisation des métadonnées. Sans les packages, vos métadonnées Salesforce peuvent devenir difficiles à gérer.
C’est là que les packages déverrouillés interviennent
Salesforce propose différents types de packages, chacun avec des caractéristiques uniques. Pour l'instant, nous allons travailler avec un type de package spécial, des packages déverrouillés, qui sont particulièrement adaptés aux applications professionnelles internes.
Les packages déverrouillés vous permettent d'ajouter, de modifier et de supprimer des métadonnées dans votre organisation de manière traçable afin que vous puissiez les réutiliser et mettre à jour vos applications Salesforce plus facilement et plus rapidement. Ils comprennent toutes les modifications de métadonnées et les mises à jour que vous prévoyez de faire.
Bien sûr, votre application, et donc le contenu du package, changent au fil du temps. Pour suivre les modifications, vous créez des versions de votre package. Chaque version est un artefact immuable, un instantané du contenu de votre package.
Dans votre organisation de production, vous pouvez vérifier la version de package de provenance des métadonnées et l'ensemble de toutes les métadonnées associées à la version du package. Ce processus d'inspection est le même pour les packages que vous avez installés depuis AppExchange.
Plus besoin de feuilles de calcul pour suivre les modifications des métadonnées. Plus besoin non plus de notes autocollantes !
Qu’est-ce qu’un package déverrouillé ?
Avec un package déverrouillé, vous avez beaucoup de flexibilité. Vos administrateurs peuvent directement apporter des modifications à la production en réponse à des demandes de modification d'urgence, car les métadonnées des packages déverrouillés peuvent être modifiées dans une organisation de production.
Tandis que les packages déverrouillés vous donnent la flexibilité d'effectuer des changements directement dans l'organisation de production, souvenez-vous qu'une grande puissance implique une grande responsabilité. Sentez-vous vos picotements de Spider-Man ?
Les packages déverrouillés sont contrôlés par le développeur. L'installation d’une nouvelle version de package remplace les modifications apportées directement dans l'organisation de production. Il est essentiel que les administrateurs communiquent à l'équipe de développement toute modification apportée directement dans l'organisation de production afin que le package soit mis à jour de manière appropriée.
Alors, que pouvez-vous mettre dans un package déverrouillé ? Bonne nouvelle ! Vous pouvez mettre presque tous les types de métadonnées et de composants Salesforce dans un package déverrouillé.
Le rapport Couverture des métadonnées est la source de vérité des informations de couverture des métadonnées sur plusieurs canaux. Ces canaux comprennent les API des métadonnées, le suivi des sources, les packages déverrouillés, les packages gérés de seconde génération, les packages gérés de première génération et plus encore. Pour accéder au rapport Couverture des métadonnées, accédez à https://developer.salesforce.com/docs/metadata-coverage.
Comment commencer ?
Avant de continuer, il est important de répéter que l’adoption des outils et principes de développement de Salesforce DX n’est pas un projet « tout ou rien ». Vous pouvez commencer par faire des petits pas, ou vous pouvez vous jeter à l'eau. Nous ne vous jugerons pas.
Donc, si vous êtes prêt à élargir votre répertoire, par où commencer ?
- Si vous êtes nouveau sur Salesforce ou que vous lancez un nouveau projet, vous pouvez suivre le modèle de développement de package dès le début.
- Si vous débutez avec une profusion de sources indifférenciées, vous pouvez adopter l’empaquetage progressivement lorsque vous commencez à découper vos métadonnées et à les organiser en conteneurs logiques.
Vous pouvez commencer modestement en empaquetant les composants et les schémas que vous pourrez ensuite réutiliser dans plusieurs applications. Le moment venu, vous pouvez définir des dépendances entre les packages. Vous décidez de la vitesse à laquelle vous allez et de la complexité que vous pouvez absorber.
Cette flexibilité constitue la puissance des packages déverrouillés.
Développement de package avec Salesforce DX
Maintenant que vous comprenez certains concepts de base de l'empaquetage, jetons un coup d'œil sur le flux de travail de l'empaquetage. Par souci de simplicité, supposons que vous êtes le seul développeur et responsable de version, mais qu’un autre collègue s'occupe de l'assurance qualité (QA).
Vous commencez par créer un package associé à un répertoire dans votre projet Salesforce DX. En tant que développeur, vous modifiez les métadonnées de votre projet et les modifications s'accumulent. Vous utilisez les organisations test pour développer et tester individuellement ces modifications (1).
En tant que responsable de version, lorsque vous êtes prêt à la partager avec QA, vous créez une version de package. QA installe le package et se met au travail. Vous utilisez également ce package pour les tests unitaires et CI (2). Au cours de ce processus, vous corrigez des bogues, ajoutez de nouvelles fonctionnalités ou modifiez des fonctionnalités existantes. Vous créez une nouvelle version de package, puis redémarrez le processus de test unitaire (1).
C'est la nature itérative du modèle de développement de package.
Vous répétez ce processus avec QA jusqu'à ce que vous ayez une bonne version, puis vous installez cette version dans votre sandbox pour le test d'acceptation utilisateur (UAT), et finalement dans la production (3).
L'installation de la version du package est similaire au déploiement de métadonnées. Vous pouvez installer une version de package dans n'importe quelle organisation : une organisation test, une organisation sandbox ou une organisation de production, similaire au déploiement d'un ensemble de métadonnées.
Et voilà ! Vous comprenez maintenant le cycle de vie de l’application de base pour le modèle de développement de package.
Maintenant que vous avez publié votre premier package
Dans le monde de la haute technologie et du développement de logiciels, il n'y a jamais beaucoup de temps pour vous reposer sur vos lauriers. La prochaine version est en général imminente. Maintenant, il est de nouveau temps de mettre votre cape et vos collants, de vous remettre au travail et de développer de nouvelles fonctionnalités et personnalisations. Et, vous l'avez deviné, une nouvelle version de package.
Vous pouvez créer toutes les nouvelles versions dont vous avez besoin lorsque vous modifiez, ajoutez ou supprimez des métadonnées de package. Chaque version de package possède un numéro de version (par exemple, 1.3.0.2) et vous pouvez utiliser une mise à niveau de package pour appliquer ces modifications à une version de package installée.
Ce processus, modifier les métadonnées → créer la version du package → version du package de test → déployer en production, peut être fait un nombre illimité de fois.
Prêt à l’essayer ? Allons construire votre premier package déverrouillé.