Apprentissage des méthodes de test, de création et de publication

Objectifs de formation

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

• Décrire comment les organisations test prennent en charge la réalisation de différents types de tests
  
• Décrire le rôle des sandbox dans le cadre des déploiements
  

Réalisation de tests et intégration continue à l’aide d’organisations test

La façon dont vous testez, créez et publiez vos modifications par le biais du développement de packages représente un tournant par rapport au cycle de vie actuel des applications.

Si vous employez actuellement le modèle de développement d’ensembles de modifications, vous transférez les modifications organisationnelles (deltas) entre les environnements de développement et de test jusqu’à ce que ces modifications soient publiées dans votre organisation de production. En fin de compte, la « source d’informations fiables » reste 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 des 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.

Vous pouvez utiliser Salesforce CLI durant l’intégralité du cycle de vie du développement de packages.

Lorsque vous êtes prêt à effectuer des tests manuels ou exploratoires de votre travail de développement, déployez vos métadonnées dans une organisation test distincte désignée à cet effet (1). Vous ne récupérerez jamais d’éléments à partir de cette organisation, car elle est uniquement utilisée à des fins de test ou de validation.

L’intégration continue (CI) consiste à automatiser des exécutions de tests cohérentes pour chaque ensemble de modifications fusionné au sein de votre application (2). Ce processus important garantit la qualité de l’application avant que des modifications corrompues ne puissent pénétrer dans votre référentiel source.

Les organisations test peuvent être facilement intégrées dans un processus CI. La CLI peut créer des organisations test, de sorte que les intégrer dans un flux CI est un jeu d’enfant. Vous pouvez remplir l’organisation avec la version appropriée du référentiel source et exécuter des tests portant sur une modification spécifique.

Contrairement aux Developer Sandbox, les organisations test peuvent être créées tout au long de la journée : elles ne sont pas soumises à la limite d’une seule actualisation par jour. Vous pouvez supprimer une organisation test et en créer une autre rapidement lorsque le besoin s’en fait sentir. Vous pouvez disposer de plusieurs organisations test ayant des visées différentes. Les organisations test vous offrent une grande flexibilité pour un coût limité.

Lorsque vous êtes prêt à effectuer des tests de version ou à mettre en place l’automatisation de la livraison continue, vous créez une version de package. Au lieu d’utiliser des ensembles de modifications pour transférer les modifications entre les environnements, vous créez et installez des versions de package (3) dans chaque environnement test. Une fois les tests terminés, vous installez une version de package dans votre organisation de production.

Livraison continue grâce aux sandbox

Dans le cadre de la livraison continue, vous souhaitez commencer à tester le même processus que celui que vous utilisez lorsque vous procédez à des déploiements dans votre organisation de production. Dans ce cas d’utilisation, vous souhaitez effectuer des tests relatifs au package que vous avez élaboré lors de la phase de création et l’installer dans une sandbox, qui est la meilleure représentation de l’organisation de production. Dans une sandbox, vous pouvez répliquer et tester les étapes que vous suivez pour publier dans l’organisation de production.

Déploiement limité à un ensemble de modifications

Bien que le développement de packages soit un excellent moyen de gérer le changement dans votre grand ensemble de métadonnées, nous vous offrons toujours la possibilité de choisir ce que vous souhaitez déployer en dehors d’un package. Utilisez la commande Salesforce CLI project deploy start pour gérer les cas d’utilisation de création et de déploiement.

Après avoir créé et testé votre application ou vos personnalisations, vous êtes prêt à créer l’artefact de déploiement. Vous pouvez déployer l’intégralité de la source et l’opération de déploiement se chargera de mettre à jour les fichiers qui ont été modifiés. Au fur et à mesure que vous poursuivez votre travail sur votre projet DX, vous pouvez continuer à déployer les modifications dans l’organisation à l’aide de Salesforce CLI pour tous les cas d’utilisation se rapportant aux tests de version et à la livraison continue. Vous pouvez essayer le processus de déploiement s’appuyant sur la CLI en suivant le module Développement d’applications 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
• Trailhead : Packages déverrouillés pour les clients
• Vidéo : Intégration continue et livraison continue avec Salesforce DX