Pour afficher l’article en anglais, activez la case d’option Anglais. Vous pouvez aussi afficher la version anglaise dans une fenêtre contextuelle en faisant glisser le pointeur de la souris sur le texte.
Traduction
Anglais
Nous recommandons d’utiliser Visual Studio 2017

Faire évoluer votre système de build

Pour utiliser Team Foundation Build pour la génération et le test automatisés de votre application, vous devez d'abord installer un serveur de builds, ajouter un contrôleur de build et quelques agents de build, puis désigner un dossier cible. Si votre petite équipe de démarrage travaille sur un nouveau projet, vous pouvez probablement déployer tous ces composants du système de génération sur un seul ordinateur en quelques minutes. À mesure que votre équipe et que votre base de code se développent, vous pouvez développer de façon incrémentielle votre système de génération assez facilement.

Conseil Conseil

Si votre collection de projets d'équipe est hébergée sur Visual Studio Online, vous devriez pouvoir ignorer toutes ces étapes et utiliser le Contrôleur de build hébergé à la place, comme indiqué ci-dessous.

Voici quelques exemples qui illustrent comment démarrer avec un système de génération petit et simple, puis monter en charge à mesure que vos spécifications deviennent plus exigeantes.

Si votre collection de projets d'équipe est hébergée sur Visual Studio Online, vous devriez pouvoir utiliser le contrôleur de build hébergé au lieu de déployer vos propres serveurs de build.

Service Team Foundation, contrôleur de build hébergé

Consultez Utiliser un contrôleur de build hébergé avec une collection de projets d'équipe hébergée sur Visual Studio Online.

Si votre collection de projets d'équipe est hébergée sur Visual Studio Online et que votre équipe a besoin d'agents de build de plus grande échelle ou personnalisés, vous pouvez connecter votre serveur de builds sur site à Visual Studio Online.

Service Team Foundation, serveur de builds sur site

Si vous utilisez Team Foundation Server à titre de test ou travaillez avec une très petite équipe, la topologie suivante peut correspondre à votre besoin.

Système à un seul ordinateur sur une couche Application

Cette topologie peut fonctionner pour une équipe qui exécute rarement des builds et uniquement pendant les heures creuses, comme une équipe qui exécute une seule build nocturne. Toutefois, pour de nombreuses équipes, cela s'avère insuffisant, car :

  • L'agent de build impose des demandes importantes sur le processeur, ce qui pourrait nuire considérablement aux performances de la couche Application.

  • Le contrôleur de build peut exercer une pression sur la mémoire du système, surtout si le contrôleur gère de nombreux agents de build actifs en même temps.

  • L'installation du service Team Foundation Build augmente la surface d'attaque de l'ordinateur. Consultez Serveur de builds : connaître les risques de sécurité.

Si vous travaillez dans une petite équipe avec un serveur Team Foundation Server sur site, envisagez cette topologie :

Système à un seul ordinateur (autonome)

Étant donné que les agents de build effectuent les opérations qui sollicitent le processeur de manière intensive sur un ordinateur distinct, ils n'affectent pas les performances de la couche Application lorsque les builds sont exécutées.

Vous pourriez également exécuter le contrôleur de build sur le serveur de builds dédié. Toutefois, la topologie de l'illustration présente l'avantage de rendre les modifications au système de génération moins perturbatrices, par exemple lorsque vous devez réparer ou remplacer le serveur de builds.

À mesure que la taille de votre équipe et de votre base de code augmente, vous pouvez ajouter des ressources de façon incrémentielle pour répondre à vos besoins. Par exemple, vous pouvez ajouter un contrôleur supplémentaire et des agents de build.

Contrôleur sur AT avec plusieurs serveurs de builds

La présence du contrôleur de build A sur le même ordinateur que la couche Application n'est généralement pas un problème du point de vue du processeur. Toutefois, vous pouvez déplacer le contrôleur de build vers un autre serveur en raison des problèmes de sollicitation de la mémoire et de surface d'attaque mentionnés précédemment.

En utilisant plusieurs serveurs de build, vous pouvez dédier chaque serveur à un objectif différent, comme décrit dans les exemples suivants :

  • Un serveur de builds sur un ordinateur hautement performant consacré aux agents de build qui traitent des builds d'intégration continue ou d'archivage contrôlé. L'équipe a besoin que ces genres de builds (surtout les builds d'archivage contrôlé) s'exécutent rapidement afin que leur travail ne soit pas suspendu en l'attente d'une build.

  • Un serveur de builds dédié aux builds de test de vérification de build planifiées pour s'exécuter la nuit, qui ont besoin de beaucoup de temps pour exécuter des processus tels que de longues séries de tests et des analyses de code.

  • Un serveur de builds préparé et dédié à des tâches spécialisées telles que la génération et le test d'une application Windows Store.

Conseil Conseil

Dans les scénarios tels que ceux-là, vous pouvez appliquer des balises aux agents de build spécialisés, puis contraindre vos définitions de build à utiliser uniquement des agents de build avec le jeu approprié de balises. Consultez Assigner des balises pour représenter des capacités ou des fonctions de l'agent de build, Spécifier les agents de build qui traitent votre build pour un processus simple de build par défaut et Exécuter les activités sur l'agent de build d'un processus de génération personnalisé avancé.

L'exemple de topologie de système de génération suivant peut prendre en charge les efforts logiciels au niveau de l'entreprise.

Système à plusieurs ordinateurs avec plusieurs contrôleurs

Chaque collection de projets d'équipe doit avoir son propre contrôleur de build, comme indiqué ci-dessus. Notez la façon dont cette topologie isole les serveurs de build. Les membres de l'équipe qui travaillent sur la collection de projets d'équipe A peuvent utiliser uniquement les agents de build contrôlés par le contrôleur de build A. Cette contrainte peut être utile dans les situations où vous devez contrôler étroitement l'accès à une propriété intellectuelle plus réactive.

Déployer et utiliser un serveur de builds

Pour utiliser Team Foundation Build avec un serveur Team Foundation Server sur site, vous devez déployer au moins un serveur de builds. Vous pouvez également connecter un ou plusieurs serveurs de builds sur site à Visual Studio Online.

Conseil Conseil

À mesure que votre système monte en puissance, vous pouvez remplacer un serveur de builds existant lorsque vous déployez un nouveau serveur de builds. Par exemple, vous pouvez souhaiter héberger la même configuration et le même ensemble de contrôleurs de build et d'agents de build sur un nouvel ordinateur plus puissant. Consultez Configurer le service Team Foundation Build.

Déployer et configurer un contrôleur de build

Utilisez un contrôleur de build unique pour regrouper un ou plusieurs agents de build. Vous pouvez héberger un contrôleur de build sur un serveur de builds.

Déployer et configurer des agents de build

Utilisez un agent de build pour effectuer les opérations de votre génération qui sollicitent le processeur de manière intensive, notamment l'obtention de fichiers du contrôle de version, la configuration de l'espace de travail, la compilation de code et l'exécution de tests.

Configurer des dossiers cibles

Vous pouvez préparer et indiquer ensuite un ou plusieurs dossiers cibles afin que votre système de génération puisse fournir des fichiers binaires, des résultats de tests et des fichiers journaux à votre équipe.

Gérer votre système de génération

Après avoir déployé votre serveur de builds, vous pouvez le gérer à partir de la Console Administration Team Foundation. Vous pouvez gérer le contrôleur de build et les agents de build à partir de la console Administration Team Foundation ou à partir de Visual Studio.

Utiliser Team Foundation Build

Lorsque votre système de génération est en place, votre équipe est prête à créer un processus de génération simple (par exemple, une build d'intégration continue) et à tirer parti de la génération et du test automatisés de votre application.

Afficher: