Augmentation de la productivité grâce à des outils intégrés

Objectifs de formation

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

Décrire les manières dont l’interface de ligne de commande (CLI) de Salesforce peut améliorer la productivité
Décrire le rôle des systèmes de contrôle de version, des organisations test et des organisations sandbox dans le modèle de développement de packages
Identifier les situations dans lesquelles il est approprié d’utiliser des organisations test plutôt que des sandbox

Outils existants, nouveaux outils, vos outils

Nous reconnaissons qu’il existe de nombreux logiciels open source innovants. L’un de nos principes directeurs est donc de soutenir des normes ouvertes en ce qui concerne les outils de développement. Nous souhaitons fournir une infrastructure qui vous permet d’utiliser la chaîne d’outils que vous connaissez. Nous voulons également vous proposer un ensemble d’outils que vous pouvez utiliser si vous n’en disposez encore d’aucun.

Interface de ligne de commande Salesforce

L’un des outils que nous proposons est l’interface de ligne de commande (CLI) Salesforce, à la fois flexible et puissante. Vous pouvez utiliser la CLI pour gérer le processus de développement de package à partir de la ligne de commande.

Salesforce CLI combine de nombreuses fonctionnalités provenant de plusieurs API Salesforce, telles que l’API de métadonnées, l’API Tooling et l’API de données (SOAP). Grâce à la nouvelle CLI améliorée, l’ensemble de vos tâches de développement associées à toutes les API importantes sont disponibles au même endroit. Vous pouvez programmer l’ensemble des éléments nécessaires pour gérer le cycle de vie complet du développement, de la création d’organisations à l’importation et à l’exportation de données. Pensez à tous les scripts pratiques que vous pouvez créer pour faciliter les tâches de développement répétitives !

En plus, ils se chargent également de faire la vaisselle ! (Bon, pas vraiment, mais cela serait formidable, non ?)

écran d’ordinateur sur lequel figure des commandes CLI

Salesforce CLI est un outil d’amélioration de la productivité garantissant l’égalité des chances :

Les développeurs peuvent l’utiliser pour gérer leurs projets DX, créer des organisations test, déployer des métadonnées sur des organisations test et en récupérer depuis celles-ci, ainsi que pour exécuter des tests unitaires.
Les spécialistes DevOps peuvent l’utiliser dans le cadre de scripts d’automatisation de génération aux fins suivantes : créer et accéder à des environnements, déployer la source, installer des packages et exécuter des tests.

Générateur de code

Avec le générateur de code, vous bénéficiez d’un puissant environnement de développement intégré créé spécifiquement pour le développement Salesforce. Les extensions incluses fournissent les éléments suivants :

Une fonctionnalité permettant d’interagir avec Salesforce CLI
Une fonctionnalité permettant de créer des projets pour le développement de votre package
Un accès au serveur de langage Apex pour la coloration syntaxique et la saisie automatique de code
Une prise en charge des paquets de composants Lightning
Une prise en charge des débogueurs Apex et Replay
Une IA générative permettant d’écrire, de tester, de déboguer et de refactoriser du code

Il est également pré-intégré à Git, mais peut fonctionner avec d’autres systèmes de contrôle de version.

Vous préférez travailler dans un environnement de développement local, tel que Visual Studio Code ? Cela ne pose aucun problème : Salesforce propose également les mêmes extensions pour VS Code.

Système de contrôle de version

Les systèmes de contrôle de version (VCS) jouent un rôle essentiel dans le développement orienté source. Vous avez besoin d’un VCS pour gérer votre source et la décliner en différentes versions afin de pouvoir tirer pleinement profit des nouveaux outils et du développement de packages.

Alors, comment vous y prendre si vous n’utilisez pas encore de VCS ?

Vous débutez probablement aussi dans la création de packages. Examinons donc le cas de base. Commencez par planifier la création d’un seul package pour comprendre le processus. Vous disposez d’un projet DX relatif au développement de ce package avec un référentiel VCS correspondant à ce projet de package. Vous serez bientôt plus à l’aise avec le cycle de vie du développement de packages et la structure des projets DX. Ensuite, vous pourrez envisager de nouvelles façons de concevoir vos projets de packages et de les organiser dans un ou plusieurs référentiels VCS.

Organisations tests

Conçues pour être éphémères et faciles à recréer, les organisations test sont des environnements Salesforce dédiés et configurables que vous pouvez rapidement mettre en place à de nombreuses fins différentes.

Vous en avez assez que tout le monde apporte des modifications à votre sandbox ? Les organisations test permettent d’éviter cet inconvénient dans le cadre du processus de développement. Les organisations test peuvent être votre propre environnement de développement personnel, mais vous pouvez également créer des organisations test headless pour mener des tests automatisés. Vous pouvez créer une organisation test lorsque vous souhaitez accomplir ce qui suit :

Démarrer un nouveau projet.
Démarrer une nouvelle branche de fonctionnalité.
Tester une nouvelle fonctionnalité.
Démarrer des tests automatisés.
Effectuer des tâches de développement directement dans une organisation.
Partir de zéro avec une toute nouvelle organisation.

Vous pouvez configurer l’organisation test avec différentes éditions Salesforce et avec uniquement les fonctionnalités et préférences souhaitées. Vous pouvez également partager le fichier de configuration de l’organisation test avec d’autres membres de l’équipe. De cette façon, vous disposez tous de la même organisation de base dans laquelle réaliser votre développement.

Différence entre une organisation test et une sandbox

Maintenant que vous comprenez les cas d’utilisation des organisations test, prenons un peu de recul et discutons de ce que les organisations test ne sont pas.

Les organisations test n’ont pas la capacité de contenir l’entièreté des métadonnées figurant dans votre organisation de production. En outre, elles n’ont pas été créées dans l’optique de remplacer les sandbox. Lorsque vous commencez à analyser les éléments de métadonnées que vous souhaitez déployer dans une organisation test, demandez-vous si toutes ces sources sont requises pour votre projet spécifique.

Par exemple :

Toutes les personnalisations sont-elles liées à une seule application ou à l’extension du CRM ?
Les personnalisations représentent-elles un grand nombre d’applications ou de projets différents ?

Si vous avez répondu « oui » à la deuxième question, réfléchissez à la manière dont vous pouvez diviser ces différents éléments en packages. Dans un tel cas de figure, il vous faudrait créer une organisation test distincte pour tester chacun de ces modules individuels. Ultérieurement au cours du cycle de vie de développement, vous auriez à déployer des packages distincts dans une sandbox dans le cadre des tests finaux et de la préproduction.

Les sandbox, des outils restant importants

Même si nous pensons que les organisations test vont révolutionner votre manière de travailler et augmenter votre productivité, les sandbox demeurent une composante importante du cycle de vie du développement de packages. Vous les utiliserez toujours comme cibles/destinations pour tester l’installation de la version du package que vous aurez créée. Une fois cette dernière installée, vous continuerez à les utiliser pour les tests d’acceptation utilisateur, comme environnement de préproduction et dans le cadre des tests de livraison continue.

Employez vos organisations tests pour les cas d’utilisation relatifs au développement orienté source, et servez-vous de vos sandbox pour réaliser vos tests de publication et de déploiement.

Besoin d'aide ?

En savoir plus