Suivez votre progression
Accueil Trailhead
Accueil Trailhead

Utiliser le développement de packages pour des versions plus flexibles

Objectifs de formation

Une fois cette unité terminée, vous pourrez :
  • identifier les principales différences entre le développement de packages et le développement d’ensembles de modifications ;
  • décrire ce qu’est une version de package et comment cela vous permet de gérer les modifications au sein de votre organisation ;
  • résumer pourquoi il n’est pas nécessaire de suivre les modifications de configuration manuellement en cas d’utilisation du modèle de développement de packages.

Cette unité explique pourquoi Calvin et ses collègues ont décidé de s’éloigner des modèles de développement d’ensembles de modifications pour passer au développement de packages. D’autres équipes peuvent être convaincues par différents aspects du développement de packages. En parcourant cette unité, réfléchissez aux choix que vous feriez pour votre équipe et à l’aspect du développement de package que vous trouvez le plus intéressant. Avancez en traitant les modules énumérés à la fin de ce module pour découvrir le processus et prendre la décision la plus éclairée possible à propos de ce qui fonctionnera pour vous.

Les défis de la gestion des modifications liés aux ensembles de modifications

Au fil du temps, le nombre de projets et de contributeurs associés à chaque version de l’organisation de Zephyrus est en perpétuelle croissance. C’est une excellente nouvelle pour les utilisateurs. L’application cohérente des étapes ALM par l’entreprise permet de réduire les délais de traitement des demandes d’amélioration tout en minimisant les perturbations.

Mais la coordination de ces modifications devient un véritable casse-tête pour Calvin, particulièrement lorsque ces modifications proviennent de différentes équipes et n’ont aucun lien entre elles. Les versions continuent d’augmenter en taille et en complexité. Il s’inquiète que les fonctionnalités sur lesquelles s’appuie le personnel de Zephyrus pourraient s’effondrer face à la difficulté d’agrégation et de test des modifications pour tous les projets d’une version.

Avec autant de modifications à coordonner et à suivre dans chaque version, Calvin préfèrerait passer ce temps à apporter des modifications. Il estime également que les équipes personnalisant Salesforce chez Zephyrus pourraient être plus productives si elles passaient moins de temps à coordonner leurs modifications avec celles d’autres projets.

Conteneur unique ou plusieurs conteneurs ?

Calvin demande conseil aux autres membres de Trailblazer Community de Salesforce pour la gestion de très nombreux projets dans chaque version. Ils lui parlent d’un nouveau modèle de développement Salesforce qui offre plus de flexibilité pour la gestion des versions : le développement de packages.

Le développement de packages consiste à gérer différentes personnalisations sous forme packages distincts, et non comme une seule grosse version de modifications apportées à l’organisation. N’oubliez pas que, dans le développement d’ensembles de modifications, vous gérez un ensemble de modifications provenant de plusieurs projets comme si ces modifications étaient regroupées dans un seul conteneur. Lorsque les versions deviennent tellement complexes qu’il est logique de gérer l’organisation sous forme de plusieurs conteneurs, il est temps de passer au modèle de développement de packages. Si votre équipe prépare déjà des artefacts de version modulaires sur d’autres plates-formes, elle retrouvera certaines similitudes dans le développement de packages.

Par exemple, un package chez Zephyrus peut contenir l’une des personnalisations suivantes :

  • applications Force.com personnalisées programmées en interne ;
  • extensions de Sales Cloud, Service Cloud, etc. ;
  • extensions d’une application AppExchange ;
  • mises à jour vers des bibliothèques et fonctionnalités partagées.

Lorsque vous travaillez avec un modèle de développement de packages, vous préparez un artefact de version que vous pouvez tester et publier indépendamment des artefacts d’autres projets. En lieu et place d’un ensemble de modifications liées à la production, votre équipe crée un package contenant toutes les métadonnées pertinentes. Les métadonnées dans le package incluent les composants modifiés et non modifiés.

Organiser les mises à jour des métadonnées par packages vous permet également de créer un meilleur modèle mental de la structure des métadonnées au sein de votre organisation. Si vous souhaitez gérer votre organisation sous forme de plusieurs conteneurs, chaque package représente l’un de ces conteneurs.

Une version de package est un instantané fixe du contenu d’un package et des métadonnées associées. La version du package vous permet de gérer ce qui est différent chaque fois que vous publiez ou déployez un ensemble spécifique de modifications ajoutées à un package. Si vous introduisez des modifications de métadonnées dans un package déjà déployé, vous effectuez une mise à niveau de la version actuelle du package vers la version la plus récente.

Calvin est heureux des gains de productivité potentiels liés au passage au développement de packages. Il présente cet argument à Ernesto, le PDG, et les directeurs d’autres services qui créent des personnalisations Salesforce. Il se concentre sur trois points principaux :

  • créer un journal d’audit clair présentant les changements des métadonnées de l’organisation au fil du temps ;
  • améliorer la productivité en libérant le temps actuellement consacré au suivi des modifications de la configuration ;
  • obtenir une plus grande flexibilité dans les versions, car chaque package peut être développé, testé et publié indépendamment des packages d’autres projets.

Retrouvez la vérité dans les métadonnées de la source

Dans le développement de packages, votre source de vérité est constituée des métadonnées de votre projet de package. Cela facilite l’intégration à un VCS, ce qui peut permettre à votre équipe de gérer les modifications apportées au projet.

Dans le développement d’ensembles de modifications, la source de vérité est une combinaison des métadonnées déjà présentes dans l’environnement et de la dernière version de l’ensemble de modifications. À lui seul, un ensemble de modifications ne peut pas constituer une image complète car il ne contient que ce qui a été modifié, comme une fusion.

Dites adieu au suivi manuel des modifications de la configuration

Les organisations tests sont des environnements de développement de packages. Les organisations tests jouent un rôle essentiel dans la réduction significative des modifications que Calvin et son équipe doivent suivre pour chaque version.

Les organisations tests sont des organisations vides (sans métadonnées ni données), faciles à créer et à supprimer selon les besoins. Vous pouvez configurer des organisations tests pour qu’elles correspondent à différentes éditions de Salesforce, avec des fonctionnalités et des préférences différentes. De plus, vous pouvez réutiliser et partager le fichier de définition d’une organisation test avec d’autres membres de l’équipe, car il fait partie du projet intégré au VCS. Ainsi, il est beaucoup plus simple pour chaque membre de l’équipe de travailler sur une même configuration organisationnelle, tout en disposant de son propre environnement de développement.

Lorsque vous utilisez des organisations tests pour le développement, vous commencez par déplacer la source depuis votre projet vers le VCS, pour synchroniser l’organisation test avec les mêmes métadonnées. Si vous envisagez d’utiliser la configuration pour le développement, les modifications que vous apportez sont automatiquement suivies. Vous pouvez retrouver les modifications que vous avez apportées pour les inclure dans votre projet et utiliser votre VCS pour valider toutes les modifications.

Conseil

Conseil

Comment Calvin sait-il quels composants sont pris en charge dans le suivi de source ? Le rapport Couverture des métadonnées vous indique si les types de métadonnées sont pris en charge dans le suivi de source, 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.

Chaque package suit son propre chemin

Avec le développement de packages, vous pouvez gérer des calendriers de publication distincts pour chaque package. Vous utilisez des packages pour segmenter la propriété des métadonnées de l’organisation. Chaque projet possède donc son propre package, ainsi que tous les packages dépendants. Vous pouvez gérer la mise à niveau de segments individuels indépendamment pour chaque version de package ultérieure, ce qui vous permet de gérer des calendriers de publication distincts.

Qu’est-ce qu’une dépendance de package ? Un composant de métadonnées ne peut figurer que dans un seul package à la fois. Si plusieurs packages ont besoin du même composant, vous pouvez concevoir une stratégie de packages modulaire pour ce composant. Un package contenant un ou plusieurs composants de métadonnées partagés par plusieurs packages est une dépendance de package.

Chaque package (et toutes ses dépendances) peut être testé séparément de toutes les autres métadonnées de l’organisation. L’isolation de métadonnées dans des packages vous offre alors la possibilité de mettre à jour ces ensembles de métadonnées (packages) indépendamment. Cela vous apporte également la souplesse de publier les packages séparément.

Et maintenant ?

Chacun des trois modèles de développement dispose de son propre module dans Trailhead. En traitant chaque module, vous découvrirez comment créer des personnalisations pour Salesforce en partant de ce modèle de développement.