Personnalisation du workflow Lab Management

  • Article

Le flux de travail de bout en bout de Visual Studio Lab Management vous permet d'automatiser la génération de votre application, le déploiement de la nouvelle build sur un environnement virtuel et l'exécution de tests sur la nouvelle build. Le modèle LabDefaultTemplate est fourni comme modèle de flux de travail par défaut que vous pouvez utiliser immédiatement. Pour plus d'informations sur l'utilisation du modèle LabDefaultTemplate, consultez Comment : déployer une application dans un environnement virtuel. Il se peut toutefois 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 bien, un flux de travail nécessite que l'environnement soit enregistré dans la bibliothèque à partir de laquelle chaque testeur va effectuer le déploiement, tandis qu'un autre flux de travail n'enregistre pas du tout l'environnement. Étant donné que le modèle de flux de travail par défaut est basé sur Windows Workflow 4.0, il est complètement extensible et personnalisable, et vous pouvez personnaliser LabDefaultTemplate en fonction de vos besoins.

Cette rubrique décrit les étapes générales de la personnalisation du modèle de flux de travail et présente cinq exemples de scénarios où la personnalisation s'avère très utile :

  • Spécifier un emplacement pour les binaires de test autre que l'emplacement de build.

  • Prendre en charge des déploiements d'applications qui nécessitent un redémarrage après installation.

  • Lire les fichiers du contrôle de code source.

  • Accéder à un emplacement cible de build à l'aide du compte de l'agent de build.

  • 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é constitue le bloc de construction 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, consultez Activités Lab Management Team Foundation. 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. Cliquez sur 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 LabDefaultTemplate en fonction de vos spécifications.

Avant de commencer la personnalisation

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

Emplacement du dossier pour les modèles de workflow par défaut

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 du contrôle de code source et recherchez le dossier $/<Nom_Projet>/BuildProcessTemplates.

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

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

  5. Effectuez une copie du fichier LabDefaultTemplate.xaml et renommez-la, par exemple, LabDefaultTemplate_customize.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 de flux de travail 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.

Glissement d'une activité Lab Management à partir de la boîte à outils

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. Cliquez sur Créer un argument. Dans la zone de texte, tapez le nom de l'argument, par exemple, TestBinariesLocation. Dans la liste déroulante Direction, cliquez sur In. Dans la liste déroulante Type d'argument, cliquez sur 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 cliquez sur 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 cliquez sur OK.

  5. Dans le menu Fichier, cliquez sur Enregistrer LabDefaultTemplate_customize.xaml

  6. Dans la barre de menus de l'Explorateur du contrôle de code source, cliquez sur 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 de flux de travail par défaut, LabDefaultTemplate, ne redémarre pas l'environnement virtuel après que l'application a été déployée. 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 virtuel, vous redémarrez uniquement l'ordinateur virtuel où l'application a été installée. Visual Studio Lab Management ne permet pas d'effectuer individuellement des opérations sur chaque ordinateur virtuel d'un environnement. Par conséquent, le redémarrage d'un ordinateur implique le redémarrage de tous les ordinateurs de l'environnement virtuel.

Avertissement

Vérifiez que vos scripts de déploiement ne redémarrent jamais l'ordinateur virtuel. Si cela se produit, l'agent de build qui exécute le script de déploiement perd la connexion avec le contrôleur de build et le flux de travail peut s'arrêter.

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, cliquez sur 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, cliquez sur 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. Cliquez sur 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 de flux de travail 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, cliquez sur 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.

    Cliquez sur 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, cliquez sur 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, cliquez sur Durée, puis sur 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 le 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, consultez Comment : configurer le compte de service pour l'intégration des tests et des workflows. 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 $/MonProjet/CustomAssemblies, vous devez exécuter une commande semblable à la suivante : C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE>tf permission /user:mydomain\labAccount /collection:http://aseemb-tfs10: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 le flux de travail lab 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 de flux de travail. 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

Tâches

Créer une définition de build de base

Référence

A Developer's Introduction to Windows Workflow Foundation (WF) in .NET 4

Concepts

Utilisation d'un lab virtuel pour le cycle de vie de votre application

Autres ressources

Activités Lab Management Team Foundation

Définir votre processus de build

Historique des modifications

Date

Historique

Motif

Octobre 2010

Ajout de deux illustrations récapitulant plusieurs étapes de personnalisation du flux de travail.

Améliorations apportées aux informations.