Création d’une définition de build prenant en charge le déploiement

par Jason Lee

Si vous souhaitez effectuer n’importe quel type de build dans Team Foundation Server (TFS) 2010, vous devez créer une définition de build au sein de votre projet d’équipe. Cette rubrique explique comment créer une définition de build dans TFS et comment contrôler le déploiement web dans le cadre du processus de génération dans Team Build.

Cette rubrique fait partie d’une série de didacticiels 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ée 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 , un contenant des instructions de génération qui s’appliquent à chaque environnement de destination et un qui contient 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

Une définition de build est le mécanisme qui contrôle comment et quand les builds se produisent pour les projets d’équipe dans TFS. Chaque définition de build spécifie :

• Les éléments que vous voulez générer, tels que les fichiers de solution Visual Studio ou les fichiers projet personnalisés Microsoft Build Engine (MSBuild).
• Critères qui déterminent quand une build doit avoir lieu, comme les déclencheurs manuels, l'intégration continue (CI) ou les validations contrôlées.
• Emplacement auquel Team Build doit envoyer des sorties de build, y compris des artefacts de déploiement tels que des packages web et des scripts de base de données.
• Temps pendant lequel chaque build doit être conservé.
• Différents autres paramètres du processus de génération.

Cette rubrique vous montre comment créer une définition de build qui utilise CI, afin qu’une build soit déclenchée lorsqu’un développeur vérifie le nouveau contenu. Si la build réussit, le service de génération exécute un fichier projet personnalisé pour déployer la solution dans un environnement de test.

Lorsque vous déclenchez une compilation, ces actions devront se produire :

• Tout d’abord, Team Build doit générer la solution. Dans le cadre de ce processus, Team Build appelle le pipeline de publication web (WPP) pour générer des packages de déploiement web pour chacun des projets d’application web dans la solution. Team Build exécute également tous les tests unitaires associés à la solution.
• Si la génération de la solution échoue, Team Build ne doit pas entreprendre d’action supplémentaire. Les échecs de test unitaire doivent être traités comme une défaillance de build.
• Si la build de la solution réussit, Team Build doit exécuter le fichier projet personnalisé qui contrôle le déploiement de la solution. Dans le cadre de ce processus, Team Build appelle l’outil de déploiement web IIS (Internet Information Services) (Web Deploy) pour installer les applications web empaquetées sur les serveurs web de destination et appelle l’utilitaire VSDBCMD.exe pour exécuter des scripts de création de base de données sur les serveurs de base de données de destination.

Cela illustre le processus :

L’exemple de solution Gestionnaire de contacts inclut un fichier projet MSBuild personnalisé, Publish.proj, que vous pouvez exécuter à partir de MSBuild ou de Team Build. Comme décrit dans Présentation du processus de génération, ce fichier projet définit la logique qui déploie vos packages web et bases de données dans un environnement cible. Le fichier inclut une logique qui omet le processus de génération et d’empaquetage s’il est en cours d’exécution dans Team Build, en laissant uniquement les tâches de déploiement à exécuter. Cela est dû au fait que lorsque vous automatisez le déploiement de cette façon, vous souhaiterez généralement vous assurer que la solution s’génère correctement et réussit les tests unitaires avant le début du processus de déploiement.

La section suivante explique comment implémenter ce processus en créant une définition de build.

Qui effectue cette procédure ?

En règle générale, un administrateur TFS effectue cette procédure. Dans certains cas, un responsable de l’équipe de développement peut assumer la responsabilité de la collection de projets d’équipe dans TFS. Pour créer une nouvelle définition de build, vous devez être membre du groupe Administrateurs de Build de Collection de Projets de la collection de projets d'équipe qui contient votre solution.

Créer une définition de build pour l’intégration continue et le déploiement

La procédure suivante explique comment créer une définition de build déclenchée par CI. Si la build réussit, la solution est déployée à l’aide de la logique dans un fichier projet MSBuild personnalisé.

Pour créer une définition de build pour l’intégration continue et le déploiement

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 à la définition de build un nom (par exemple , DeployToTest) et une description facultative.

3. Sous l’onglet Déclencheur , sélectionnez les critères sur lesquels vous souhaitez déclencher une nouvelle build. Par exemple, si vous souhaitez générer la solution et déployer dans l’environnement de test chaque fois qu’un développeur vérifie dans le nouveau code, sélectionnez Intégration continue.

4. Sous l’onglet Valeurs par défaut de build, dans la case Copier le résultat de la build vers 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).

   

   Note

   Cet emplacement de suppression stocke plusieurs builds, en fonction de la stratégie de rétention que vous configurez. Lorsque vous souhaitez publier des artefacts de déploiement à partir d’une build spécifique vers un environnement de préproduction ou de production, c’est là que vous les trouverez.

5. Sous l’onglet Processus , dans la liste déroulante Générer le 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 la table des paramètres du processus de génération , cliquez dans 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. Accédez à l’emplacement de votre fichier solution, puis cliquez sur OK.

   

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

10. Dans la liste déroulante Éléments de type , sélectionnez les fichiers projet MSBuild.

11. 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.

    

12. La boîte de dialogue Éléments à générer doit maintenant afficher deux éléments. Cliquez sur OK.

    

13. Sous l’onglet Processus, dans la table des paramètres du processus de génération, déployez la section Avancé.

14. Dans la ligne Arguments MSBuild , ajoutez tous les arguments de ligne de commande MSBuild requis par l’un de vos éléments à générer. Dans le scénario de solution du Gestionnaire de contacts, ces arguments sont requis :

    /p:DeployOnBuild=true;DeployTarget=Package;
       TargetEnvPropsFile=EnvConfig\Env-Dev.proj
    

    

15. Dans cet exemple :

    1. Les arguments DeployOnBuild=true et DeployTarget=package sont requis lorsque vous générez la solution Gestionnaire de contacts. Cela indique à MSBuild de créer des packages de déploiement web après avoir généré chaque projet d’application web, comme décrit dans Building and Packaging Web Application Projects.
    2. L’argument TargetEnvPropsFile est requis lorsque vous générez le fichier Publish.proj . Cette propriété indique l’emplacement du fichier de configuration spécifique à l’environnement, comme décrit dans Présentation du processus de génération.

16. Sous l’onglet Stratégie de rétention , configurez le nombre de builds de chaque type que vous souhaitez conserver en fonction des besoins.

17. Cliquez sur Enregistrer.

Mettre en file d’attente une build

À ce stade, vous avez créé au moins une nouvelle définition de build. Le processus de génération que vous avez défini s’exécute désormais en fonction des déclencheurs que vous avez spécifiés dans la définition de build.

Si vous avez configuré votre définition de build pour utiliser CI, vous pouvez tester votre définition de build de deux manières :

• Archivez du contenu dans le projet d’équipe pour déclencher une build automatique.
• Mettre manuellement en file d’attente une build.

Pour mettre en file d’attente manuellement une build

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

   

2. Dans la boîte de dialogue Construire la file d'attente, vérifiez les propriétés de la compilation, puis cliquez sur File d’attente.

   

Pour passer en revue la progression et le résultat d’une build, qu’elle soit déclenchée manuellement ou automatiquement, double-cliquez sur la définition de build dans la fenêtre Team Explorer . Cela ouvre un onglet Explorateur de builds .

À partir de là, vous pouvez corriger les échecs de compilation. Si vous double-cliquez sur une build individuelle, vous pouvez afficher des informations récapitulatives et accéder aux fichiers journaux détaillés.

Vous pouvez utiliser ces informations pour diagnostiquer les échecs de compilation et rectifier les problèmes avant d'essayer une autre compilation.

Surveiller le processus de compilation

TFS fournit un large éventail de fonctionnalités pour vous aider à surveiller le processus de génération. Par exemple, TFS peut vous envoyer un e-mail ou afficher des alertes dans votre zone de notification de barre des tâches lorsqu’une build est terminée. Pour plus d’informations, consultez Exécuter et surveiller les builds.

Conclusion

Cette rubrique a décrit comment créer une définition de build dans TFS. La définition de build est configurée pour CI. Par conséquent, le processus de génération s’exécute chaque fois qu’un développeur vérifie le contenu du projet d’équipe. La définition de build exécute un fichier projet MSBuild personnalisé pour déployer des packages web et des scripts de base de données dans un environnement serveur cible.

Pour qu’un déploiement automatisé réussisse dans le cadre d’un processus de génération, vous devez accorder les autorisations appropriées au compte de service de build sur les serveurs web cibles et le serveur de base de données cible. La dernière rubrique de ce tutoriel, Configuration des autorisations pour le déploiement de build d’équipe, explique comment identifier et configurer les autorisations requises pour le déploiement automatisé à partir d’un serveur Team Build.

Lectures complémentaires

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’informations sur la mise en file d’attente des builds, consultez File d’attente d’une build.