Organisez vos métadonnées

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

• Énumérer les stratégies clés pour organiser les métadonnées non empaquetées dans des packages.
• Identifier comment les package déverrouillés peuvent être interdépendants.
• Décrire les 3 modèles de développement de package et le moment de les utiliser.

Félicitations ! Dans l'unité précédente, vous avez créé un package et installé l'application DreamHouse dans votre Trailhead Playground. Maintenant, nous allons vous montrer comment mettre en pratique certains des principes clés du développement de packages. Rappelez-vous, c'est normal de commencer modestement et de poursuivre sur la lancée de vos succès.

L’organisation de vos métadonnées en packages :

• est souvent un processus itératif.
• N’est pas une proposition tout ou rien.

DreamHouse LWC est un excellent exemple de création d’une application à partir de zéro et de l’empaquetage dans un package déverrouillé de façon à lancer l’application dans votre organisation et à gérer les personnalisations futures. Mais vous pouvez également suivre ce même processus lors de la mise à jour de nouvelles fonctionnalités pour une application personnalisée existante.

En résumé, nous avons créé DreamHouse pour montrer comment :

• Intégrer les CLI, les projets et les packages déverrouillés de Salesforce dans le cycle de vie de votre application.
• Adopter les meilleures pratiques en matière d'organisation des métadonnées et de création de limites de package.
• Implémenter des packages déverrouillés lorsque vous créez une nouvelle application.

Que pouvez-vous faire maintenant que vous avez créé un package déverrouillé pour DreamHouse LWC ?

• Tester et déployer la source pour l'application de manière indépendante.
• Isoler le schéma de l'application (objets personnalisés) des autres métadonnées.
• Continuer à apporter des améliorations à l'application en répétant le processus et en ajoutant de nouvelles fonctionnalités.
• Faire une version de l’application.
• Installer une deuxième version en tant que mise à niveau d'une version existante.

Métadonnées DreamHouse

Comme vous pouvez le voir, l’utilisation du cycle de vie du développement de package pour de nouveaux projets est très judicieuse. Cependant, nous savons que les clients existants, qui ont utilisé le développement d'ensembles de modifications sur une période de plusieurs versions, voire de plusieurs années, réclament des conseils pour savoir par où commencer. Comment pouvez-vous démêler le contenu de votre organisation en projets séparés et, en fin de compte, en répertoires de packages ?

Bien que nous aimerions vous donner l’ingrédient secret, il n'y a pas de plan d'action normatif. La façon dont vous envisagez de décomposer les métadonnées non empaquetées est un mélange de science et d'art. Vous êtes le meilleur juge pour déterminer les éléments de métadonnées qui correspondent aux projets Salesforce DX.

Pour commencer, répondez à ces questions :

• Souhaitez-vous que vos équipes de développement puissent publier des applications, de nouvelles fonctionnalités et des personnalisations de manière indépendante ?
• Pouvez-vous identifier la métadonnée qui représente une application ?
• Pouvez-vous organiser vos métadonnées en modules pour des fonctionnalités distinctes ?
• Lorsque vous créez un package non géré pour cette fonctionnalité ou cette application, quelles dépendances voyez-vous ?

Si vous avez plusieurs applications et personnalisations dans votre organisation, attendez-vous à voir des dépendances parmi les projets Salesforce DX.

Trois modèles pour démêler vos métadonnées

Dans des scénarios concrets, vous devrez probablement adopter une combinaison de ces stratégies et et les affiner pour mieux répondre aux besoins de votre entreprise.

Utilisation d’un package non géré comme point de départ

Voici un bon flux de travail de départ pour organiser vos métadonnées non gérées en plusieurs packages :

1. Sélectionnez un petit ensemble de métadonnées autonomes et non empaquetées dans votre organisation de production. Sélectionnez les métadonnées qui représentent une application, une personnalisation d'une application existante, une fonctionnalité ou une unité fonctionnelle ou des personnalisations d'objets standard.
2. Créez un package non géré pour isoler les métadonnées que vous avez identifiées à partir de la collection globale des métadonnées d'organisation. Lorsque vous y ajoutez des métadonnées, identifiez les métadonnées dépendantes qui sont automatiquement récupérées par le système. Cette étape permet de révéler certaines dépendances qui ne sont pas si évidentes parmi vos métadonnées.
3. Récupérez la source de votre package non géré en utilisant project retrieve start (démarrer la récupération de projet).
4. Configurez un projet Salesforce DX et un dépôt git pour gérer les métadonnées du package.
5. Poussez cette métadonnée vers une organisation test en utilisant project deploy start (démarrer le déploiement de projet) et confirmez que ce sont les métadonnées que vous souhaitez voir dans un package déverrouillé.
6. Créez un package déverrouillé à l’aide de l’indicateur --no-namespace (aucun espace de nom).
7. Testez et déployez le package déverrouillé
8. Une fois que le package déverrouillé a réussi toutes les exécutions CI et UAT dans les sandbox, promouvez la version de package.
9. Installez le package déverrouillé dans l'organisation de production.

Une fois que vous avez créé un package pour cette métadonnée, elle est automatiquement déplacée dans le package. Puisque le nom complet de l'entité identifie les métadonnées dans l'organisation et dans le package, nous remplaçons les métadonnées déjà dans l'organisation et mettons à jour les références internes pour montrer qu'elles sont maintenant contenues dans le package.

À propos des dépendances de package

Le développement et la gestion d’un ensemble de packages interdépendants est une valeur clé des packages déverrouillés.

• Un package déverrouillé peut dépendre d'un package AppExchange. Si vous utilisez un package AppExchange, vous pouvez mettre votre propre personnalisation pour ce package dans un package déverrouillé. Lorsque vous installez le package déverrouillé, le package AppExchange doit être présent.
• Un package déverrouillé peut dépendre d'un autre package déverrouillé. Imaginons que vous créez une nouvelle application que les employés peuvent utiliser pour envoyer des notes de frais. Cette application partage certaines fonctionnalités d'intégration backend avec votre application de paie existante. Dans ce scénario, le package déverrouillé du rapport de dépenses dépendra du package déverrouillé de l'application de paie.
• Un package déverrouillé peut dépendre d'un autre package déverrouillé, et ce package déverrouillé peut, à son tour, dépendre d'un package déverrouillé différent. Plusieurs niveaux de dépendances sont pris en charge.

Vous exprimez des dépendances dans la section packageDirectories du fichier sfdx-project.json En prenant en charge les dépendances, les packages déverrouillés favorisent le développement modulaire avec un cadre de dépendance riche. Reportez-vous au guide du développeur Salesforce DX pour plus d’informations sur le fichier de configuration de projet.