Déploiement d’une build spécifique

par Jason Lee

Cette rubrique explique comment déployer des packages web et des scripts de base de données à partir d’une build précédente spécifique vers une nouvelle destination, comme un environnement intermédiaire ou de production.

Cette rubrique fait partie d’une série de tutoriels basés sur les exigences de déploiement d’entreprise d’une société fictive nommée Fabrikam, Inc. Cette série de tutoriels utilise un exemple de solution, la solution Gestionnaire de contacts, pour représenter une application web avec un niveau de complexité réaliste, notamment une application ASP.NET MVC 3, un service Windows Communication Foundation (WCF) et un projet de base de données.

La méthode de déploiement au cœur de ces didacticiels est basée sur l’approche de fichier projet fractionné décrite dans Présentation du fichier projet, dans laquelle le processus de génération et de déploiement est contrôlé par deux fichiers projet : l’un contenant des instructions de génération qui s’appliquent à chaque environnement de destination et l’autre contenant des paramètres de build et de déploiement spécifiques à l’environnement. Au moment de la génération, le fichier projet spécifique à l’environnement est fusionné dans le fichier projet indépendant de l’environnement pour former un ensemble complet d’instructions de génération.

Vue d’ensemble de la tâche

Jusqu’à présent, les rubriques de cet ensemble de tutoriels se concentraient sur la création, l’empaquetage et le déploiement d’applications web et de bases de données dans le cadre d’un processus automatisé ou à une seule étape. Toutefois, dans certains scénarios courants, vous devez sélectionner les ressources que vous déployez dans une liste de builds dans un dossier de suppression. En d’autres termes, la dernière build peut ne pas être celle que vous souhaitez déployer.

Considérez le scénario d’intégration continue (CI) décrit dans la rubrique précédente, Création d’une définition de build qui prend en charge le déploiement. Vous avez créé une définition de build dans Team Foundation Server (TFS) 2010. Chaque fois qu’un développeur vérifie du code dans TFS, Team Build génère votre code, crée des packages web et des scripts de base de données dans le cadre du processus de génération, exécute des tests unitaires et déploie vos ressources dans un environnement de test. Selon la stratégie de rétention que vous avez configurée lors de la création de la définition de build, TFS conserve un certain nombre de builds précédentes.

=======

À présent, supposons que vous avez effectué des tests de vérification et de validation sur l’une de ces builds dans votre environnement de test, et que vous êtes prêt à déployer votre application dans un environnement intermédiaire. En attendant, les développeurs ont peut-être archivé un nouveau code. Vous ne souhaitez pas regénérer la solution et la déployer dans l’environnement intermédiaire, et vous ne souhaitez pas déployer la dernière build dans l’environnement intermédiaire. Au lieu de cela, vous souhaitez déployer la build spécifique que vous avez vérifiée et validée sur les serveurs de test.

Pour ce faire, vous devez indiquer au Microsoft Build Engine (MSBuild) où trouver les packages web et les scripts de base de données générés par une build spécifique.

Substitution de la propriété OutputRoot

Dans l’exemple de solution, le fichier Publish.proj déclare une propriété nommée OutputRoot. Comme son nom l’indique, il s’agit du dossier racine qui contient tout ce que le processus de génération génère. Dans le fichier Publish.proj , vous pouvez voir que la propriété OutputRoot fait référence à l’emplacement racine de toutes les ressources de déploiement.

<PropertyGroup>
  <!--This is where the .deploymanifest file will be written to during a build-->    
  <_DbDeployManifestPath>
    $(OutputRoot)ContactManager.Database.deploymanifest
  </_DbDeployManifestPath>    
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Mvc Web project -->
  <_ContactManagerDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Mvc_Package\
  </_ContactManagerDest>
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Service Web project -->
   <_ContactManagerSvcDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Service_Package\
  </_ContactManagerSvcDest>
  
  <!-- ... -->
</PropertyGroup>

Si vous souhaitez que votre fichier projet déploie des packages web et des scripts de base de données à partir d’un autre emplacement, comme les sorties d’une build TFS précédente, vous devez simplement remplacer la propriété OutputRoot . Vous devez définir la valeur de la propriété sur le dossier de build approprié sur le serveur Team Build. Si vous exécutiez MSBuild à partir de la ligne de commande, vous pouvez spécifier une valeur pour OutputRoot en tant qu’argument de ligne de commande :

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\

Toutefois, dans la pratique , vous souhaitez également ignorer la cible de build: il n’y a aucun intérêt à créer votre solution si vous ne prévoyez pas d’utiliser les sorties de build. Pour ce faire, spécifiez les cibles que vous souhaitez exécuter à partir de la ligne de commande :

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
  /target:GatherPackagesForPublishing;PublishDBPackages;PublishWebPackages

Toutefois, dans la plupart des cas, vous souhaiterez générer votre logique de déploiement dans une définition de build TFS. Cela permet aux utilisateurs disposant de l’autorisation Créations de file d’attente de déclencher le déploiement à partir de n’importe quelle installation Visual Studio avec une connexion au serveur TFS.

Création d’une définition de build pour déployer des builds spécifiques

La procédure suivante décrit comment créer une définition de build qui permet aux utilisateurs de déclencher des déploiements dans un environnement intermédiaire avec une seule commande.

Dans ce cas, vous ne souhaitez pas que la définition de build génère quoi que ce soit , vous voulez simplement qu’elle exécute la logique de déploiement dans votre fichier projet personnalisé. Le fichier Publish.proj inclut une logique conditionnelle qui ignore la cible de build si le fichier est en cours d’exécution dans Team Build. Pour ce faire, il évalue la propriété BuildingInTeamBuild intégrée, qui est automatiquement définie sur true si vous exécutez votre fichier projet dans Team Build. Par conséquent, vous pouvez ignorer le processus de génération et simplement exécuter le fichier projet pour déployer une build existante.

Pour créer une définition de build pour déclencher le déploiement manuellement

1. Dans Visual Studio 2010, dans la fenêtre Team Explorer, développez le nœud de votre projet d’équipe, cliquez avec le bouton droit sur Builds, puis cliquez sur Nouvelle définition de build.

   

2. Sous l’onglet Général , donnez un nom à la définition de build (par exemple, DeployToStaging) et une description facultative.

3. Sous l’onglet Déclencheur , sélectionnez Manuel – Les archivages ne déclenchent pas de nouvelle build.

4. Sous l’onglet Valeurs par défaut de la génération, dans la zone Copier la sortie de build dans le dossier de dépôt suivant , tapez le chemin d’accès UNC (Universal Naming Convention) de votre dossier de dépôt (par exemple, \TFSBUILD\Drops).

   

5. Sous l’onglet Processus , dans la liste déroulante Générer un fichier de processus , laissez DefaultTemplate.xaml sélectionné. Il s’agit de l’un des modèles de processus de génération par défaut qui sont ajoutés à tous les nouveaux projets d’équipe.

6. Dans le tableau Paramètres du processus de génération, cliquez sur la ligne Éléments à générer , puis cliquez sur le bouton de sélection.

   

7. Dans la boîte de dialogue Éléments à générer , cliquez sur Ajouter.

8. Dans la liste déroulante Éléments de type , sélectionnez Fichiers projet MSBuild.

9. Accédez à l’emplacement du fichier projet personnalisé avec lequel vous contrôlez le processus de déploiement, sélectionnez le fichier, puis cliquez sur OK.

   

10. Dans la boîte de dialogue Éléments à générer , cliquez sur OK.

11. Dans la table Paramètres du processus de génération, développez la section Avancé .

12. Dans la ligne Arguments MSBuild , spécifiez l’emplacement de votre fichier projet spécifique à l’environnement et ajoutez un espace réservé pour l’emplacement de votre dossier de build :

    /p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
    OutputRoot=PLACEHOLDER
    

    

    Notes

    Vous devez remplacer la valeur OutputRoot chaque fois que vous mettrez en file d’attente une build. Cela est abordé dans la procédure suivante.

13. Cliquez sur Enregistrer.

Lorsque vous déclenchez une build, vous devez mettre à jour la propriété OutputRoot pour qu’elle pointe vers la build que vous souhaitez déployer.

Pour déployer une build spécifique à partir d’une définition de build

1. Dans la fenêtre Team Explorer, cliquez avec le bouton droit sur la définition de build, puis cliquez sur Mettre en file d’attente la nouvelle build.

   

2. Dans la boîte de dialogue Build de file d’attente , sous l’onglet Paramètres , développez la section Avancé .

3. Dans la ligne Arguments MSBuild , remplacez la valeur de la propriété OutputRoot par l’emplacement de votre dossier de build. Par exemple :

   /p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
      OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
   

   

   Notes

   Veillez à inclure une barre oblique de fin à la fin du chemin d’accès à votre dossier de build.

4. Cliquez sur File d’attente.

Lorsque vous placez la build en file d’attente, le fichier projet déploie les scripts de base de données et les packages web à partir du dossier de dépôt de build que vous avez spécifié dans la propriété OutputRoot .

Conclusion

Cette rubrique a décrit comment publier des ressources de déploiement, telles que des packages web et des scripts de base de données, à partir d’une build précédente spécifique à l’aide du modèle de déploiement de fichier projet fractionné. Il a expliqué comment remplacer la propriété OutputRoot et comment incorporer la logique de déploiement dans une définition de build TFS.

En savoir plus

Pour plus d’informations sur la création de définitions de build, consultez Créer une définition de build de base et Définir votre processus de génération. Pour plus d’aide sur la mise en file d’attente des builds, consultez Mettre en file d’attente une build.