Test et déploiement des modifications

• Créer un fichier manifeste (package.xml) qui répertorie les composants à déployer
• Expliquer les commandes utilisées pour déployer des modifications dans votre organisation
• Décrire comment accélérer les déploiements grâce au déploiement rapide

Extraction des modifications à partir du référentiel

Juan sait que la source d’informations fiables (c’est-à-dire, toutes les modifications relatives à cette version) figure désormais dans leur référentiel GitHub.

1. Dans VS Code, cliquez sur l’icône de contrôle source (1). 
2. Cliquez sur l’icône More Actions (Autres actions) (2), puis sélectionnez Pull from (Extraire de) (3).
3. Sélectionnez origin (origine).
4. Le référentiel contient le nouvel objet personnalisé, le champ personnalisé et les déclencheurs. Toutes les modifications d’Ella et de Juan sont présentes ici.

Autorisation de la sandbox Developer Pro

Si vous suivez les étapes de votre côté, inscrivez-vous à une organisation Developer Edition ou à un Trailhead Playground à utiliser à la place de la sandbox Developer Pro.

1. Dans VS Code, connectez-vous à la sandbox Developer Pro. Sélectionnez SFDX :. autoriser une organisation.
2. Sélectionnez Sandbox pour l’URL de connexion (test.salesforce.com).
3. Saisissez un alias pour la sandbox, par exemple dev_pro_sandbox.
4. Connectez-vous à l’aide de vos nom d’utilisateur et mot de passe sandbox.

Construction de l’artefact de version

La première tâche de Juan consiste à créer l’artefact de version afin qu’il puisse déployer les modifications dans la sandbox Developer Pro. Juan décide de créer un fichier manifeste, couramment appelé package.xml, qui répertorie les composants de métadonnées qu’il souhaite déployer.  

1. Dans une fenêtre de commande, assurez-vous que vous vous trouvez dans le répertoire du projet Salesforce DX.
2. Sur la ligne de commande, consultez l’aide de la commande project generate manifest.

   sf project generate manifest --help

   L’indicateur --help indique à Juan le format de la commande. Juan souhaite déployer uniquement les nouveaux composants de métadonnées. Il détermine donc qu’il a besoin de l’indicateur --metadata.
3. Exécutez la commande project generate manifest et indiquez les composants à déployer, tels que le nouvel objet personnalisé Language Course Instructor (Formateur du cours de langue) et les autres modifications dans sa liste de modifications :

   sf project generate manifest --metadata CustomObject:Language_Course_Instructor__c --metadata CustomField:Language_Course__c.Course_Instructor__c --metadata ApexTrigger:LanguageCourseTrigger --metadata ApexClass:TestLanguageCourseTrigger

   La commande génère le fichier manifeste appelé package.xml dans le répertoire actuel.
4. Testez le fichier package.xml dans la sandbox Developer Pro pour vous assurer qu’il déploie tous les composants.
   

   sf project deploy start --manifest package.xml --target-org dev-pro-sandbox

Prenons un moment pour examiner le fichier package.xml.  Si vous le souhaitez, vous pouvez ouvrir celui que vous venez de générer dans un éditeur de texte.  Le fichier énumère simplement les composants de métadonnées à déployer : il ne contient pas le code Apex réel ou la structure complète de l’objet personnalisé.  Lorsque vous effectuez un déploiement à l’aide de ce fichier manifeste, la commande de déploiement utilise les fichiers sources qu’elle trouve dans votre projet local.  Si vous exécutez la commande à partir d’une autre branche du VCS ou si vous modifiez les fichiers sources locaux relatifs à ces composants, ces fichiers sont déployés à la place. En résumé, soyez attentif à quels fichiers sources vous déployez concrètement lorsque vous utilisez un fichier manifeste.   

Vous pouvez également utiliser un fichier manifeste pour supprimer des composants lors d’un déploiement. Utilisez l’indicateur --type de la commande project generate manifest pour générer un fichier manifeste de modifications destructives qui répertorie les composants à supprimer. Spécifiez ensuite ce fichier avec l’un des indicateurs de suppression de project deploy start|validate, tel que --post-destructive-changes. 

Si vous suivez les étapes de votre côté, arrêtez-vous ici. Les étapes suivantes nécessitent la classe de test TestLanguageCourseTrigger, qui n’entre pas dans le cadre de ce module.

Test de l’artefact de version dans la sandbox de test (Partial)

Juan utilise à nouveau une fenêtre de commande ou un terminal pour exécuter une commande Salesforce CLI afin de déployer les modifications dans la sandbox de test. Juan déploie ses modifications en utilisant la même commande que précédemment : project deploy start.

1. Autorisez la sandbox Partial.
2. Assurez-vous que vous êtes dans le répertoire du projet Salesforce DX.
3. Sur la ligne de commande, consultez l’aide de la commande de déploiement.

   sf project deploy start --help 

   L’indicateur --help indique à Juan le format de la commande, et les indicateurs à inclure, en particulier --manifest pour procéder au déploiement en utilisant le fichier manifeste package.xml.
4. Exécutez la commande de déploiement qui reproduit ce que vous allez déployer en production :

   sf project deploy start --manifest package.xml --target-org partial-sandbox --test-level RunSpecifiedTests --tests TestLanguageCourseTrigger

5. Exécutez vos tests d’interface utilisateur, tels que les tests Selenium, si nécessaire.
6. Ouvrez la sandbox :

   sf org open --target-org partial-sandbox

7. Effectuez les tests d’acceptation utilisateur

À ce stade du processus, Juan ne se soucie que des tests liés à l’application ou aux modifications en cours de déploiement. Il exécute uniquement les tests pour le code présent dans l’artefact de version.

Si les tests de Juan sont concluants, il passe à la phase de test de version, où il effectue des tests de régression dans la sandbox de préproduction.

Test de l’artefact de version dans la sandbox de préproduction (Full)

Si Juan n’apporte aucune modification sur la base des tests d’intégration, l’étape suivante consiste à mettre en préproduction les modifications dans une sandbox Full. Juan suit un processus similaire pour déployer les modifications dans la sandbox Full. Cette phase comprend des tests de régression et reproduit la manière dont Juan publiera les modifications en production.

Comme Juan ne trouve aucune erreur pendant la phase de test, il utilise le même fichier package.xml et s’assure qu’il effectue le déploiement à partir de la même branche que lors du test. S’il avait trouvé des erreurs pendant la phase de test, il les aurait corrigées et il aurait réessayé.

Il exécute d’abord une analyse de régression en effectuant un déploiement validé sur l’organisation qui exécute tous les tests. Un déploiement validé vous permet de vérifier les résultats des tests qui seraient exécutés dans un déploiement, mais ne valide aucune modification. La validation garantit également que vous n’avez pas oublié un composant de métadonnées dont dépend un autre composant et que vous n’avez pas de métadonnées non valides. Après avoir exécuté tous les tests de régression, il exécute un déploiement rapide pour reproduire exactement les étapes qu’il suivra pour le déploiement en production. Il effectue toutes ces étapes en utilisant Salesforce CLI.

En validant avec succès les composants dans l’environnement de préproduction, Juan raccourcit sa fenêtre de maintenance (c’est-à-dire, la période pendant laquelle l’accès des utilisateurs au système est bloqué lorsque les personnalisations sont déployées en production).

1. Autorisez la sandbox Full.
2. Exécutez tous les tests locaux (tests de régression) pour valider le déploiement sans enregistrer les composants dans l’organisation cible. 

   sf project deploy validate --manifest package.xml --target-org full-sandbox --test-level RunLocalTests

   Cette commande renvoie un ID de tâche que vous devrez indiquer lors du déploiement rapide. Une validation réussie signifie que tous les tests Apex ont été concluants et que les tests couvrent au moins 75 % du code en cours de déploiement.
3. Ensuite, effectuez le déploiement rapide sur la sandbox Full à l’aide de l’ID de tâche renvoyé à l’étape précédente. Ce déploiement rapide reproduit ce qui se passe plus tard en production. 

   sf project deploy quick --job-id <jobID> --target-org full-sandbox 

Mise en production

Il s’agit de la dernière ligne droite pour Juan et son équipe. Maintenant que tous leurs tests ont réussi dans la sandbox Full, ils sont prêts à réaliser le déploiement en production. L’équipe commerciale est très enthousiaste à l’idée de voir sa vision se concrétiser.

Juan vérifie la liste des exécutions de déploiement et constate qu’il n’a aucune tâche préalable au déploiement à accomplir. Tout est prêt. Après avoir exécuté le déploiement de validation, il dispose de 10 jours pour effectuer le déploiement rapide en production, à condition qu’il n’effectue pas un autre déploiement ou n’apporte pas de modifications majeures à l’organisation. Juan configure le déploiement de validation pour l’organisation de production afin de garantir qu’il n’y aura aucun problème causé par des différences avec la sandbox de préproduction. Juan exécute le déploiement de validation pendant les heures ouvrables, donc si un problème se produit, il est disponible pour procéder à son dépannage. Lorsque la validation est réussie, et pour minimiser l’impact sur les clients, il effectue un déploiement en production le soir même, par le biais du déploiement rapide.

1. Autorisez l’organisation de production.
2. Commencez par valider et configurer le déploiement rapide en exécutant la commande project deploy validate :

   sf project deploy validate --manifest package.xml --target-org production-org --test-level RunLocalTests

   Cette commande renvoie un ID de tâche que vous devrez indiquer lors du déploiement rapide.
3. Exécutez le déploiement rapide :

   sf project deploy quick --job-id <jobID> --target-org production-org 

4. Ouvrez l’organisation de production pour vous assurer que vos modifications s’y trouvent.

Réalisation des tâches post-déploiement répertoriées dans la liste des exécutions de déploiement

Juan examine à nouveau la liste des exécutions de déploiement pour déterminer les tâches post-déploiement à effectuer dans l’organisation de production.

Encore un déploiement réussi !

Calvin effectue une vérification rapide de l’intégrité de l’organisation de production. Il ajoute un formateur à l’un des cours et vérifie que l’e-mail de notification arrive bien dans sa boîte de réception.

Maintenant que toutes les modifications figurent dans le système de contrôle source, l’équipe peut fournir à Calvin une liste définitive des modifications à documenter dans les notes de publication.

Calvin informe l’équipe commerciale que la nouvelle fonctionnalité de notification est prête. Il félicite Ella et Juan pour le déploiement réussi d’une fonctionnalité clé qui aidera l’équipe commerciale de Zephyrus disposer des informations les plus récentes concernant les cours. Il est ravi que les modifications soient désormais stockées dans un référentiel, et voit les avantages que celui-ci offre au fur et à mesure que l’équipe prend en charge davantage de travail.