Création d’une définition de build qui prend 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 dans 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 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 Contact Manager, pour représenter une application web avec un niveau de complexité réaliste, y compris une application MVC 3 ASP.NET, 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 build.
Vue d’ensemble des tâches
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 souhaitez générer, comme les fichiers de solution Visual Studio ou les fichiers projet Microsoft Build Engine personnalisés (MSBuild).
- Critères qui déterminent le moment où une build doit avoir lieu, comme les déclencheurs manuels, l’intégration continue (CI) ou les case activée-ins fermés.
- Emplacement auquel Team Build doit envoyer les sorties de build, y compris les artefacts de déploiement tels que les packages web et les scripts de base de données.
- Durée pendant laquelle chaque build doit être conservée.
- Divers autres paramètres du processus de génération.
Notes
Pour plus d’informations sur les définitions de build, consultez Définir votre processus de build.
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 build, ces actions doivent 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 de la solution. Team Build exécute également tous les tests unitaires associés à la solution.
- En cas d’échec de la génération de solution, Team Build ne doit pas prendre d’autres mesures. Les échecs de test unitaire doivent être traités comme une défaillance de build.
- Si la génération de 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 (Web Deploy) internet Information Services (IIS) 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 Contact Manager inclut un fichier projet MSBuild personnalisé, Publish.proj, que vous pouvez exécuter à partir de MSBuild ou 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 vos 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 s’exécute dans Team Build, en laissant uniquement les tâches de déploiement à exécuter. En effet, lorsque vous automatisez le déploiement de cette manière, vous souhaitez généralement vous assurer que la solution est générée avec succès et réussit tous 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.
Notes
Cette procédure, dans laquelle un processus automatisé unique génère, teste et déploie une solution, est probablement la plus adaptée au déploiement dans des environnements de test. Pour les environnements de préproduction et de production, vous êtes beaucoup plus susceptible de vouloir déployer du contenu d’une build précédente que vous avez déjà vérifié et validé dans un environnement de test. Cette approche est décrite dans la rubrique suivante, Déploiement d’une build spécifique.
Qui effectue cette procédure ?
En règle générale, un administrateur TFS effectue cette procédure. Dans certains cas, un responsable d’équipe de développement peut prendre la responsabilité de la collection de projets d’équipe dans TFS. Pour créer une définition de build, vous devez être membre du groupe Administrateurs de build de collection de projets pour 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 décrit 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
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.
Sous l’onglet Général , donnez à la définition de build un nom (par exemple, DeployToTest) et une description facultative.
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 la déployer dans l’environnement de test chaque fois qu’un développeur vérifie le nouveau code, sélectionnez Intégration continue.
Sous l’onglet Générer par défaut , 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).
Notes
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 dans un environnement intermédiaire ou de production, c’est là que vous les trouverez.
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.
Dans la table 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 .
Dans la boîte de dialogue Éléments à générer , cliquez sur Ajouter.
Accédez à l’emplacement de votre fichier solution, puis cliquez sur OK.
Dans la boîte de dialogue Éléments à générer , cliquez sur Ajouter.
Dans la liste déroulante Éléments de type , sélectionnez Fichiers projet MSBuild.
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.
La boîte de dialogue Éléments à générer doit maintenant afficher deux éléments. Cliquez sur OK.
Sous l’onglet Processus , dans le tableau Paramètres du processus de génération, développez la section Avancé .
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
Dans cet exemple :
- Les arguments de package DeployOnBuild=true et DeployTarget= sont requis lorsque vous générez la solution Contact Manager. 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 Création et empaquetage de projets d’application web.
- 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.
Sous l’onglet Stratégie de rétention , configurez le nombre de builds de chaque type que vous souhaitez conserver en fonction des besoins.
Cliquez sur Enregistrer.
Mettre une build en file d'attente
À 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 :
- Vérifiez du contenu dans le projet d’équipe pour déclencher une génération automatique.
- Mettre en file d’attente une build manuellement.
Pour mettre en file d’attente une build manuellement
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.
Dans la boîte de dialogue Générer la file d’attente , passez en revue les propriétés de build, puis cliquez sur File d’attente.
Pour passer en revue la progression et le résultat d’une build, qu’elle ait été déclenchée manuellement ou automatiquement, double-cliquez sur la définition de build dans la fenêtre Team Explorer. Un onglet Générer Explorer s’ouvre.
À partir de là, vous pouvez résoudre les problèmes des builds ayant échoué. Si vous double-cliquez sur une build individuelle, vous pouvez afficher des informations récapitulatives et cliquer sur les fichiers journaux détaillés.
Vous pouvez utiliser ces informations pour résoudre les échecs de builds et résoudre les problèmes avant d’essayer une autre génération.
Notes
Les builds qui exécutent la logique de déploiement sont susceptibles d’échouer tant que vous n’avez pas accordé au serveur de build les autorisations requises dans l’environnement de destination. Pour plus d’informations, consultez Configuration des autorisations pour le déploiement de build d’équipe.
Surveiller le processus de génération
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 la barre des tâches une fois qu’une build est terminée. Pour plus d’informations, consultez Exécuter et surveiller les builds.
Conclusion
Cette rubrique décrit comment créer une définition de build dans TFS. La définition de build étant configurée pour CI, le processus de génération s’exécute chaque fois qu’un développeur vérifie le contenu dans le 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 de 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 team Build, explique comment identifier et configurer les autorisations requises pour le déploiement automatisé à partir d’un serveur Team Build.
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 build. Pour plus d’informations sur la mise en file d’attente des builds, consultez Mise en file d’attente d’une build.