Découverte du développement orienté source

Objectifs de formation

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

• Décrire l’intérêt d’un projet Salesforce DX
  
• Présenter en quoi le modèle de développement de packages vous aide à gérer le suivi des modifications
  
• Expliquer le rôle des organisations test dans le processus de développement
  

Respect de l’étendue du projet

Comme nous l’avons vu dans l’unité précédente, c’est vous qui décidez des outils que vous utilisez. Vous pouvez utiliser votre éditeur de texte préféré avec Salesforce CLI ou le générateur de code. Vous sélectionnez également le VCS que vous souhaitez employer. Si vous utilisez le générateur de code, nous proposons plusieurs extensions pour faciliter le développement et la réalisation de tests.

Au fur et à mesure que votre entreprise se développe, vous pouvez rencontrer des défis liés à la coordination et au test des modifications apportées à vos projets. Le développement de packages répond directement à ces défis. Votre source est organisée en packages fondés sur un groupe de fonctionnalités ou de personnalisations que vous souhaitez proposer conjointement. Le projet Salesforce DX reprend cette approche fondée sur des packages que vous employez pour organiser votre source.

Présentation des projets Salesforce DX

Un projet Salesforce DX est une structure de répertoire locale contenant vos métadonnées au format source. Il vous permet de développer et de tester des packages avec les outils Salesforce DX.

Il contient des fichiers de configuration permettant de créer des organisations test. Il peut également contenir des données à charger dans des organisations à des fins de développement ou de test. On y trouve aussi des tests nécessaires à la validation de votre package.

Lorsque vous utilisez la CLI pour créer un projet Salesforce DX, la structure du répertoire du projet est créée pour vous. Lorsque vous créez un projet à partir de zéro, de nombreux éléments sont générés automatiquement. Nous créons un fichier de configuration de projet de base, ainsi que des exemples de fichiers de spécification et de répertoires test pour vos tests et exemples d’ensembles de données. Nous créons également un répertoire de « package » par défaut pour la source de votre package.

N’oubliez pas qu’un package est un groupe de code et de personnalisations associés. Vous pouvez tester un package indépendamment des autres composants de votre organisation. Vous pouvez également publier un package de manière indépendante. Les composants de métadonnées d’un package ne peuvent figurer que dans un seul package à la fois au sein de l’organisation installée.

Au minimum, le projet gère la source d’un package. Cela étant dit, si plusieurs packages sont créés et publiés conjointement, vous pouvez organiser ces packages en un seul projet DX. Chacun de vos packages est associé à un répertoire de package défini dans le fichier de configuration du projet.

Les organisation tests, un atout majeur pour le processus de développement

Les organisations test, créées à partir de votre source et de vos métadonnées, vous permettent de créer facilement votre application de manière cohérente, et ce, encore et encore. Vous travaillez uniquement avec la source et les métadonnées d’un projet spécifique. Il n’est pas nécessaire de copier des éléments dont vous n’avez pas besoin (et honnêtement, nous ne le recommandons pas). Comme les organisations test sont des environnements Salesforce temporaires, vous pouvez rapidement créer une organisation test pour chaque package ou projet de développement.

Une fois votre VCS configuré et votre source organisée en packages, vous êtes prêt à démarrer un nouveau projet de développement. Ouvrez votre IDE ou éditeur de texte préféré, puis ajoutez ou modifiez votre code source. Lorsque vous êtes prêt à examiner vos modifications dans une organisation, vous pouvez créer une organisation test.

Après l’avoir créée, il vous reste encore quelques tâches de configuration à effectuer. Vous déployez l’intégralité de la source du projet au sein de l’organisation test, configurez les autorisations et créez ou chargez toutes les données de test requises par votre package.

Bien qu’il soit possible d’employer un IDE ou un éditeur de texte pour développer de manière programmatique (en écrivant du code), vous pouvez utiliser l’organisation test pour développer de manière déclarative (par pointer-cliquer). Ce processus est semblable à ce que vous faites dans votre sandbox ou votre organisation de production. Ce qui est différent dans le modèle orienté source, c’est que vous synchronisez tout travail de développement effectué dans l’organisation test avec votre projet local. Cette synchronisation vous permet d’appliquer les modifications apportées aux pages de configuration en même temps que les modifications apportées au sein de votre IDE local.

Avant de valider des modifications au sein de votre système de contrôle de version, n’oubliez pas de réaliser des tests. Vous pouvez soit utiliser la même organisation test pour effectuer des tests, soit en créer une autre afin de réaliser spécifiquement des tests avant de valider votre source. Ce même processus de création d’organisations test à des fins de test est l’une des composantes clés des systèmes d’intégration continue automatisé.

Maintien de la synchronisation entre votre projet et votre organisation test

Avec Salesforce DX, vous pouvez synchroniser votre projet et votre organisation test en toute simplicité. Les notes autocollantes, c’est terminé ! Vous n’avez plus besoin de noter ce que vous avez modifié dans votre système de fichiers local, votre IDE ou votre éditeur, ni ce que vous avez modifié dans votre organisation.

Salesforce DX suit toutes les modifications que vous apportez localement dans le projet et toutes les modifications que vous avez apportées à votre organisation test.

Avant de déployer les modifications source dans l’organisation test, ou de récupérer les modifications et de les appliquer à votre projet local, vous pouvez consulter un aperçu des modifications que vous avez apportées. Cela est possible grâce à la puissance de Salesforce CLI.

$ sf project deploy preview --target-org my-scratch
No conflicts found.
No files will be deleted.
Will Deploy [2] files.
Type         Fullname        Path
──────────── ─────────────── ──────────────────────────────────────────────────────────────────────────────
ApexClass    WidgetClass     force-app/main/default/classes/WidgetClass.cls-meta.xml
CustomObject WidgetObject__c force-app/main/default/objects/WidgetObject__c/WidgetObject__c.object-meta.xml
No files were ignored. Update your .forceignore file if you want to ignore certain files.

Au sein d’une organisation de production, les fichiers sources peuvent être d’une taille très conséquente. Pensez à tous les objets personnalisés, étiquettes personnalisées et ressources statiques qui composent une organisation, pour ne nommer que quelques exemples.

Le format de projet DX décompose les fichiers sources volumineux pour les rendre plus digestes et plus faciles à gérer à l’aide d’un système de contrôle de version. Par exemple, Salesforce DX décompose les objets personnalisés et les traductions d’objets personnalisés en plusieurs fichiers et répertoires. Cette structure source facilite grandement la recherche des éléments que vous souhaitez modifier ou mettre à jour. Le fait de disposer de fichiers plus petits au sein du contrôle source réduit le nombre de conflits de fusion dans le cadre du développement en équipe. Dites adieu aux fusions hasardeuses !

Une fois que vous avez terminé le travail de développement, validez toujours vos modifications dans le référentiel VCS. Vous êtes maintenant prêt à tester, créer et publier vos projets avec Salesforce DX.

Ressources

• Guide du développeur : Référence de commande de la Salesforce CLI
• Guide du développeur : Guide du développeur Salesforce DX
• Guide du développeur : Extensions Salesforce pour VS Code
• Vidéo : Environnements Salesforce : premiers pas avec les organisations test