Personnalisation du workflow Lab Management

Publication: juillet 2016

Vous pouvez utiliser le modèle lab par défaut (LabDefaultTemplate) avec les environnements lab pour automatiser la génération de votre application, le déploiement de la nouvelle build sur un environnement lab et l'exécution de tests sur la nouvelle build. Pour plus d'informations sur l'utilisation du modèle lab par défaut, voir Créer un flux de travail de génération, de déploiement et de test pour un environnement SCVMM et Créer un flux de travail de génération, de déploiement et de test pour un environnement standard. Toutefois, il se peut que chaque processus de génération, de déploiement et de test soit légèrement différent en raison de spécifications distinctes. Par exemple, un flux de travail nécessite que des binaires de test soient copiés depuis l'emplacement de build classique, tandis qu'un autre flux de travail exige que les binaires de test soient copiés depuis un emplacement temporaire. Ou un flux de travail peut nécessiter que l'environnement lab soit enregistré dans une bibliothèque SCVMM afin que les testeurs puissent le déployer, tandis qu'un autre flux de travail n'enregistre pas du tout l'environnement lab. Étant donné que le modèle lab par défaut est basé sur Windows Workflow 4.0, il est complètement extensible et personnalisable. Vous pouvez donc personnaliser LabDefaultTemplate en fonction de vos besoins. Cette rubrique décrit les étapes générales pour la personnalisation d'un modèle lab par défaut.

Spécifications

• Visual Studio Enterprise, Visual Studio Test Professional

Voici quelques scénarios ou la personnalisation du modèle lab par défaut est utile :

• Personnalisation afin de spécifier un emplacement pour les binaires de test autre que l'emplacement cible de build

• Personnalisation afin de prendre en charge des programmes d'installation d'applications qui nécessitent un redémarrage de l'ordinateur après déploiement

• Personnalisation afin de lire des fichiers du contrôle de code source

• Personnalisation afin d'accéder à un emplacement cible de build à l'aide du compte de l'agent de build

• Personnalisation afin d'accéder à d'autres emplacements à l'aide du compte de service lab

Concepts de base de la personnalisation de flux de travail

Il existe trois concepts clés impliqués dans la personnalisation du flux de travail :

• Modèle Le modèle définit la séquence des activités ou étapes qui font partie du flux de travail. Le modèle est basé sur Windows Workflow Foundation 4.0 et il est stocké en tant que fichier .xaml dans le contrôle de code source. Pour charger le modèle dans l'éditeur de flux de travail, double-cliquez sur le fichier .xaml. Dans l'éditeur, vous pourrez visualiser les différentes activités et séquences qui déterminent le flux de travail. Vous pouvez ensuite utiliser des variables avec des portées différentes, une logique conditionnelle, des boucles, et ainsi de suite, pour programmer le modèle, comme vous le feriez avec n'importe quel autre langage de programmation. Windows Workflow Foundation vous permet de personnaliser le modèle lab par défaut en fonction de vos besoins.

• Activités L'activité est la composante d'un flux de travail, et le modèle lab par défaut utilise un grand nombre d'activités. D'autres activités se trouvent dans la Boîte à outils sous le titre Activités Team Foundation Lab Management. Pour utiliser une activité dans le flux de travail, faites-la glisser depuis la boîte à outils dans l'éditeur de flux de travail de Visual Studio vers l'emplacement approprié dans le modèle. Vous pouvez déterminer les paramètres d'entrée et de sortie en examinant les propriétés de l'activité. Pour plus d'informations sur chaque activité Lab Management, voir Activités de flux de travail Lab Management. Si les activités qui sont comprises avec le produit ne suffisent pas pour répondre à vos besoins, vous pouvez en ajouter de nouvelles.

• Arguments Vous pouvez créer de nouveaux arguments d'entrée pour les entrées d'utilisateurs requises, et transmettre ces valeurs aux activités. Choisissez l'onglet Arguments au bas de la fenêtre de l'Éditeur de flux de travail pour visualiser les arguments existants. Si vous créez de nouveaux arguments, ils apparaissent dans la section Paramètres du processus de génération de l'onglet Processus dans la définition de build.

Pensez à ces concepts lorsque vous examinez les deux exemples suivants illustrant des situations où la personnalisation est nécessaire. Le premier exemple explique comment modifier l'argument d'entrée d'une activité existante dans le modèle, et le deuxième exemple décrit comment ajouter de nouvelles activités à partir de la boîte à outils. Ces exemples doivent vous fournir suffisamment de contexte pour personnaliser le modèle lab par défaut en fonction de vos besoins.

Avant de commencer la personnalisation

Vous devez exécuter certaines étapes générales avant de commencer à personnaliser le modèle lab par défaut. Le schéma suivant illustre ces étapes.

Pour préparer la personnalisation

1. Dans Team Explorer, double-cliquez sur le nœud Contrôle de code source pour votre projet d'équipe.

2. Dans l'Explorateur du contrôle de code source, développez l'arborescence Contrôle de code source, puis recherchez le dossier $/<Nom_Projet>/ModèlesProcessusGénération.

3. Mappez ce dossier à un dossier local, par exemple, C:\Sources.

4. Cliquez avec le bouton droit sur le fichier LabDefaultTemplate.11.xaml, puis choisissez Obtenir la dernière version.

5. Effectuez une copie du fichier LabDefaultTemplate.11.xaml et renommez-la, par exemple, LabDefaultTemplate_customize.11.xaml

6. Ajoutez ce nouveau fichier au contrôle de code source.

7. Double-cliquez sur ce nouveau fichier. Le fichier s'ouvre dans l'éditeur de flux de travail Visual Studio.

Vous allez ensuite personnaliser la copie du modèle lab par défaut que vous venez de créer.

Personnalisation afin de spécifier un emplacement pour les binaires de test autre que l'emplacement cible de build

Le modèle de flux de travail par défaut, LabDefaultTemplate, suppose que l'emplacement des binaires de test est identique à l'emplacement cible des builds. Toutefois, dans votre situation, le code de test ne sera peut-être pas généré en même temps que le code du produit Si cela se produit, vous souhaiterez peut-être personnaliser le modèle afin que les binaires de test soient extraits à partir d'un autre emplacement. Cette personnalisation implique trois étapes, comme indiqué dans l'illustration suivante.

Définition d'un argument d'entrée de flux de travail pour spécifier le chemin des binaires de test

Pour définir un argument d'entrée

1. Au bas de la fenêtre de l'éditeur de flux de travail, cliquez sur l'onglet Arguments.

2. Choisissez Créer un argument. Dans la zone de texte, tapez le nom de l'argument, par exemple, TestBinariesLocation. Dans la liste déroulante Direction, choisissez In. Dans la liste déroulante Type d'argument, choisissez Chaîne.

Passage d'une valeur d'argument à l'activité ExecuteRemoteTestRun

Cette activité crée une série de tests à distance, attend la fin de l'exécution de la série de tests, puis met à jour les informations de build avec les statistiques de la série de tests.

Pour passer la valeur d'argument

1. Dans l'éditeur de flux de travail, accédez par défilement à l'activité Exécution de tests. Bien que le nom d'affichage de l'activité soit Exécution de tests, le type d'activité est ExecuteRemoteTestRun.

2. Cliquez avec le bouton droit sur l'activité, puis choisissez Propriétés. La fenêtre Propriétés s'ouvre dans le coin inférieur droit et affiche les arguments d'entrée et de sortie de cette activité. L'un des arguments d'entrée de cette activité, TestDirectory, permet de définir le chemin de l'emplacement des binaires de test.

3. Dans la fenêtre Propriétés, cliquez sur TestDirectory. À la fin de la ligne, cliquez sur le bouton de sélection (…).

4. Dans l'Éditeur d'expression, tapez TestBinariesLocation, puis choisissez OK.

5. Dans le menu Fichier, choisissez Enregistrer LabDefaultTemplate_customize.11.xaml

6. Dans la barre de menus de l'Explorateur du contrôle de code source, choisissez l'icône Archiver.

Vous pouvez maintenant utiliser le fichier .xaml personnalisé pour créer des définitions de build. Le nouvel argument d'entrée TestBinariesLocation apparaîtra dans la section Divers de l'onglet Processus dans votre définition de build, et vous pourrez assigner une valeur à partir de là.

Personnalisation afin de prendre en charge des programmes d'installation d'applications qui nécessitent un redémarrage de l'ordinateur après déploiement

Le modèle lab par défaut ne redémarre pas l'environnement lab après le déploiement de l'application. Vous souhaiterez peut-être personnaliser le modèle pour permettre la prise en charge d'applications qui peuvent nécessiter un redémarrage après déploiement. Si vous avez déployé l'application manuellement dans un environnement lab, vous redémarrerez uniquement l'ordinateur virtuel où l'application a été installée. Visual Studio Lab Management ne prend pas en charge les opérations sur les ordinateurs virtuels d'un environnement. Par conséquent, le redémarrage d'un ordinateur implique le redémarrage de tous les ordinateurs de l'environnement lab.

Le redémarrage des ordinateurs virtuels après le déploiement de la nouvelle build implique d'ajouter trois activités au modèle LabDefaultTemplate :

1. Arrêt de l'environnement

2. Démarrage de l'environnement

3. Attente du démarrage des ordinateurs virtuels avant de continuer avec le reste du flux de travail

Arrêt de l'environnement

Vous pouvez ajouter une activité d'arrêt d'environnement au modèle de flux de travail par défaut en faisant glisser l'activité StopLabEnvironment de la boîte à outils vers le modèle de flux de travail et en initialisant les variables d'activité.

Pour arrêter l'environnement

1. Dans l'éditeur de flux de travail, accédez par défilement à une activité dont le nom d'affichage est Déploiement de l'application terminé.

2. Dans le menu Affichage, sélectionnez Boîte à outils. La boîte à outils s'ouvre sur le côté gauche et affiche une liste Activités Team Foundation Build. Faites défiler cette liste d'activités jusqu'à la liste Activités Team Foundation Lab Management.

3. Dans la boîte à outils, choisissez l'activité StopLabEnvironment. Faites-la glisser dans l'éditeur de flux de travail et placez-la avant l'activité Déploiement de l'application terminé.

4. Cliquez avec le bouton droit sur l'activité, puis cliquez sur Propriétés. La fenêtre Propriétés affiche les arguments d'entrée et de sortie pour cette activité. Vous noterez que le flux de travail comporte déjà une variable appelée LabEnvironmentUri, qui fait référence à l'URI d'environnement.

5. Choisissez l'onglet Variables. La liste des variables s'affiche.

6. Sur la ligne LabEnvironmentUri, sous la colonne Par défaut, double-cliquez sur Entrer une expression VB. Dans la zone de texte, tapez LabEnvironmentUri. L'éditeur affiche toutes les utilisations existantes du paramètre et vous pouvez sélectionner la valeur dans cette liste au lieu de la taper.

Démarrage de l'environnement

Vous pouvez ajouter une activité de démarrage d'environnement au modèle lab par défaut en faisant glisser l'activité StartLabEnvironment de la boîte à outils vers le modèle de flux de travail et en initialisant les variables d'activité.

Pour démarrer l'environnement

1. Dans la boîte à outils, choisissez l'activité StartLabEnvironment. Faites-la glisser dans l'éditeur de flux de travail et placez-la avant l'activité Déploiement de l'application terminé mais après l'activité StopLabEnvironment.

2. Cliquez avec le bouton droit sur l'activité, puis cliquez sur Propriétés. La fenêtre Propriétés affiche les arguments d'entrée et de sortie pour cette activité. Là encore, vous noterez que le flux de travail comporte déjà une variable appelée LabEnvironmentUri, qui fait référence à l'URI d'environnement.

   Choisissez l'onglet Variables. La liste des variables s'affiche.

   Sur la ligne LabEnvironmentUri, sous la colonne Par défaut, double-cliquez sur Entrer une expression VB. Dans la zone de texte, tapez LabEnvironmentUri. L'éditeur affiche toutes les utilisations existantes du paramètre et vous pouvez sélectionner la valeur dans cette liste au lieu de la taper.

Attente du redémarrage des ordinateurs avant de continuer avec le reste du flux de travail

Vous pouvez ajouter un délai d'attente à observer avant le démarrage des ordinateurs virtuels en faisant glisser l'activité Attente de la boîte à outils vers le modèle de flux de travail et en initialisant les variables d'activité. Cette activité se trouve sous l'onglet Primitives de la boîte à outils.

Pour observer un délai d'attente avant le démarrage des ordinateurs virtuels

1. Dans la boîte à outils, choisissez l'onglet Primitives.

2. Cliquez sur l'activité Attente. Faites-la glisser dans l'éditeur de flux de travail et placez-la avant l'activité Déploiement de l'application terminé mais après l'activité StartLabEnvironment.

3. Cliquez avec le bouton droit sur l'activité, puis cliquez sur Propriétés. La fenêtre Propriétés affiche les arguments d'entrée et de sortie pour cette activité. Vous noterez que le flux de travail comporte déjà une variable appelée Durée, qui fait référence au délai d'attente.

4. Dans la fenêtre Propriétés, choisissez Durée, puis le bouton de sélection (…).

5. Dans l'Éditeur d'expression, tapez le délai d'attente (par exemple, 10 minutes) au format TimeSpan.FromMinutes(10).

Après avoir modifié ce modèle, archivez-le dans le contrôle de code source et utilisez-le pour créer une nouvelle définition de build en vue de déployer des applications qui nécessitent un redémarrage après installation.

Personnalisation afin de lire des fichiers du contrôle de code source

Si vous créez des activités personnalisées et que vous les utilisez dans votre modèle de flux de travail, vérifiez que l'agent de build, qui communique à l'aide du compte de service lab, peut accéder à ces activités. Étant donné que ces activités doivent être archivées dans le système de contrôle de code source en tant qu'assemblys personnalisés, vous devez vous assurer que ce compte de service lab dispose des autorisations nécessaires pour lire le chemin d'accès dans lequel les assemblys personnalisés sont archivés. Pour plus d'informations sur le compte de service lab, voir Comment : configurer le compte de service lab. Vous pouvez accorder des autorisations au compte de service lab à l'aide de la commande tf permissions. Par exemple, pour accorder des autorisations d'accès en lecture au compte de service lab mydomain\labAccount sur le chemin $/MyProject/CustomAssemblies, vous devez exécuter une commande semblable à la suivante : C:\Program Files\Microsoft Visual Studio 12.0\Common7\IDE>tf permission /user:mydomain\labAccount /collection:http://aseemb-tfs11:8080/tfs/Collection0 /allow:read $/MyProject/CustomAssemblies

Personnalisation afin d'accéder à un emplacement cible de build à l'aide du compte de l'agent de build

L'agent de build qui exécute un flux de travail accède à l'emplacement cible de build à l'aide du compte de service lab. Si vous souhaitez que l'agent de build utilise plutôt le compte de l'agent de build, vous pouvez personnaliser le modèle lab par défaut. Dans le modèle, recherchez l'activité RunDeploymentScript, qui exécute les scripts de déploiement. Cette activité expose la propriété SharedLocationForNetUse, qui définit l'emplacement accessible au moyen du compte de service lab. <mtlwa:RunDeploymentScript DisplayName="Running Deployment Script" ScriptDetails="[scriptDetails]" ThrowOnError="True" SharedLocationForNetUse="[BuildLocation]" />Pour accéder à l'emplacement cible à l'aide du compte de l'agent de build au lieu du compte de service lab, supprimez la propriété du modèle ou affectez la valeur null ({x:Null}) à cette propriété, comme illustré dans l'exemple suivant : mtlwa:RunDeploymentScript DisplayName="Running Deployment Script" ScriptDetails="[scriptDetails]" ThrowOnError="True" SharedLocationForNetUse="{x:Null}" />

Personnalisation afin d'accéder à d'autres emplacements à l'aide du compte de service lab

Si l'agent de build qui s'exécute sous le compte de service lab a besoin de lire d'autres emplacements que l'emplacement cible de build, vous pouvez modifier la propriété SharedLocationForNetUse et remplacer sa valeur par défaut, [BuildLocation], par l'emplacement souhaité. Par exemple, pour permettre à l'agent de build qui s'exécute sous le compte de service lab d'accéder au répertoire \\contoso\scripts, la propriété doit être définie comme suit : <mtlwa:RunDeploymentScript DisplayName="Running Deployment Script" ScriptDetails="[scriptDetails]" ThrowOnError="True" SharedLocationForNetUse="\\contoso\scripts" />

Voir aussi

Activités de flux de travail Lab Management
Utilisation d'un environnement lab pour le cycle de vie de votre application
Définir votre processus de build
Créer ou modifier une définition de build
A Developer's Introduction to Windows Workflow Foundation (WF) in .NET 4