Fonctionnement d'un système Team Foundation Build

Vous pouvez utiliser Team Foundation Build pour compiler, tester et déployer votre logiciel dans un système distribué et automatisé. Ce logiciel est conçu pour prendre en charge les efforts logiciels des petites « start-ups », en plus des entreprises au développement logiciel mature. Le système est conçu pour vous aider à monter en charge votre système de génération à mesure que votre équipe et votre base de code augmentent.

Dans cette rubrique

• Ordinateurs de build

  • Service Team Foundation Build

  • Utilisation d'ordinateurs virtuels comme ordinateurs de build

• Contrôleur de build

• Agent de build

• Exemples de topologie du système de génération

• Étapes suivantes

Ordinateurs de build

Pour utiliser Team Foundation Build, vous devez disposer d'au moins un ordinateur de build. Pour tout effort logiciel moyen ou grand, vous aurez probablement besoin de plusieurs ordinateurs de build. Des exemples de plusieurs configurations de système de génération sont proposés plus loin dans cette rubrique.

Un ordinateur de build est un ordinateur sur lequel vous avez installé et configuré le service Team Foundation Build. L'ordinateur peut être un ordinateur physique (par exemple, un ordinateur personnel qui est placé sous votre bureau ou une station de travail dans un laboratoire). Vous pouvez également tirer parti de la souplesse d'un ordinateur virtuel pour l'utiliser comme ordinateur de build.

Notes

Vous pouvez configurer un ordinateur de build ad hoc sur n'importe quel ordinateur dont vous disposez. Par exemple, un développeur individuel qui a un ordinateur supplémentaire disponible pourrait le configurer comme ordinateur de build pour utiliser les fonctions du service Team Foundation Build.

Même si vous configurez, modifiez et gérez directement un ordinateur de build sur l'ordinateur où le service Team Foundation Build est en cours d'exécution, la données de configuration elles-mêmes sont stockées dans la collection de projets d'équipe.

Service Team Foundation Build

Pour installer un ordinateur de build, vous installez, configurez et exécutez le service Team Foundation Build.

service Team Foundation Build est un service Windows répertorié à différents emplacements dans le système d'exploitation. Ces emplacements varient selon que le service Team Foundation Build s'exécute en tant que service Windows ou service interactif. (Pour plus d'informations sur la façon de définir la stratégie de sécurité, consultez Configurer un ordinateur de build.)

Lorsque le service Team Foundation Build s'exécute en tant que service Windows :

• Dans le nœud Services, le service Team Foundation Build est répertorié en tant que Hôte de service Visual Studio Team Foundation Build. Le nœud Services peut être affiché à l'un des emplacements suivants :

  • sur un système d'exploitation de serveur (par exemple, Windows Server 2008) dans le Gestionnaire de serveur ;

  • sur un système d'exploitation client (par exemple, Windows Vista) dans la Gestion de l'ordinateur ;

• Dans le Gestionnaire des tâches, le service Team Foundation Build est répertorié en tant que Hôte de service Visual Studio Team Foundation Build sous l'onglet Services.

Notes

Vous pouvez arrêter ou redémarrer le service de build à partir des emplacements mentionnés dans la liste ci-dessus. En arrêtant ou redémarrant le service, vous arrêtez ou redémarrez l'ordinateur de build. Toutefois, le moyen le plus commode pour gérer un ordinateur de build consiste à utiliser la Console Administration Team Foundation. Pour plus d'informations, consultez Gérer votre système de génération.

Lorsque le service Team Foundation Build s'exécute en tant que service interactif :

• dans le Gestionnaire des tâches, le service Team Foundation Build est répertorié en tant que TFSBuildServiceHost sous l'onglet Applications.

Utilisation d'ordinateurs virtuels comme ordinateurs de build

Vous pouvez déployer le service Team Foundation Build sur un ordinateur virtuel (par exemple, un ordinateur virtuel Hyper-V qui s'exécute sur un ordinateur physique exécutant Windows Server 2008). En adoptant cette stratégie, vous pouvez effectuer facilement les tâches suivantes :

• Régénérer le système à partir de tout état et à n'importe quel moment. Par exemple, si le système est endommagé, vous pouvez restaurer rapidement un instantané d'un environnement propre et régénérer le système.

• Prendre un instantané d'un ordinateur virtuel, l'exporter, puis l'archiver ou le partager avec un autre membre de votre équipe.

Le principal inconvénient de l'utilisation d'un ordinateur virtuel est qu'il fonctionne plus lentement qu'un ordinateur physique. Si vos builds requièrent une petite quantité de travail ou si vous exécutez rarement les builds (par exemple, la nuit), un ordinateur virtuel peut suffire comme ordinateur de build dans votre système.

Vous pouvez effectuer les tâches suivantes pour améliorer les performances du service Team Foundation Build lorsqu'il s'exécute sur un ordinateur virtuel :

• Exécutez vos ordinateurs virtuels sur une machine physique équipée d'un processeur multicœur. Si, par exemple, votre ordinateur physique dispose d'un processeur quadricœur, vous pouvez exécuter quatre ordinateurs virtuels en même temps, lesquels s'exécuteront de façon satisfaisante en tant qu'ordinateurs de build dans de nombreuses situations.

• Dédiez et montez un disque dur physique à chaque ordinateur virtuel.

Contrôleur de build

Chaque contrôleur de build est dédié à une seule collection de projets d'équipe. Le contrôleur accepte les demandes de build de tout projet d'équipe dans une collection de projets d'équipe spécifiée.

Chaque contrôleur de build regroupe et gère les services d'un ou plusieurs agents de build. Il distribue les opérations qui sollicitent le processeur de manière intensive (telles que la compilation de code ou l'exécution de tests) aux agents de build présents dans son pool.

Le contrôleur de build traite le flux de travail et, en général, effectue principalement le travail léger tel que la détermination du nom de la build, la création de l'étiquette dans le contrôle de version, l'enregistrement des remarques et le signalement de l'état de la build.

Étant donné qu'un contrôleur de build ne requiert généralement pas un temps processeur élevé, un ordinateur virtuel suffit souvent pour servir de plateforme pour un contrôleur de build. Toutefois, un contrôleur de build peut solliciter une quantité importante de mémoire dans certaines situations. Par conséquent, vous devez prendre soin de fournir suffisamment de mémoire à l'ordinateur physique ou virtuel sur lequel vous installez vos contrôleurs de build.

Agent de build

Chaque agent de build est dédié à un contrôleur de build unique et est contrôlé par ce dernier. L'agent de build effectue les opérations qui sollicitent le processeur et le disque dur de manière intensive. Ces opérations sont notamment l'obtention de fichiers du contrôle de version et la vérification de fichiers dans le contrôle de version, la configuration de l'espace de travail, la compilation de code et l'exécution de tests.

Lorsque vous assemblez un système de génération, vous pouvez commencer avec quelques agents. Vous pouvez ensuite monter en charge votre système de génération en ajoutant des agents de build supplémentaires lorsque vous ajoutez des membres de l'équipe, que votre base de code grandit et que le travail à effectuer par votre système de génération augmente.

Si vous configurez vos agents pour qu'ils aient des fonctions spécialisées, vous devez assigner des balises à ces agents. En adoptant cette stratégie, vous pouvez ensuite créer des définitions de build qui peuvent utiliser ces agents spécialisés. Par exemple, vous pouvez appliquer la balise BVT à un pool d'agents conçus pour exécuter vos tests de vérification de build (BVT). Vous pouvez ensuite définir une build nocturne pour utiliser uniquement ces agents de build.

Étant donné que les agents de build effectuent les opérations qui sollicitent le processeur de manière intensive, vous devez vérifier que le matériel de l'ordinateur de build est suffisamment puissant pour permettre à l'agent de build d'effectuer les tâches dans un délai acceptable.

Exemples de topologie du système de génération

Le service Team Foundation Build est conçu de façon à vous permettre de commencer avec un système de génération plus petit et moins complexe. À mesure que votre base de code se développe et que votre équipe s'accroît, vous pouvez développer votre système de façon incrémentielle avec une relative simplicité en ajoutant des ordinateurs de build au système dont vous disposez déjà.

Système à un seul ordinateur (partagé avec la couche Application)

La configuration suivante peut prendre en charge une très petite équipe, en particulier une équipe qui exécute des builds rarement et uniquement pendant les heures creuses. (Par exemple, vous n'exécutez qu'une seule build nocturne.)

Dans la plupart des cas, une topologie à ordinateur de build unique est insuffisante pour les raisons suivantes :

• L'agent de build impose des demandes importantes sur le processeur, ce qui pourrait nuire considérablement aux performances de votre 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 d'un ordinateur de build. Par exemple, un utilisateur malveillant pourrait construire une définition de build afin d'exécuter du code arbitraire pour prendre le contrôle du serveur et voler des données.

Système à un seul ordinateur (autonome)

La configuration suivante est un bon point de départ pour une petite équipe.

É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 l'ordinateur de build dédié. Toutefois, la configuration de l'illustration a l'avantage de rendre les modifications au système de génération moins perturbatrices, par exemple lorsque vous devez réparer ou remplacer l'ordinateur de build.

La présence du contrôleur de build 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 passer à une topologie plus évolutive pour les raisons suivantes :

• 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 d'un ordinateur de build. Par exemple, un utilisateur malveillant pourrait construire une définition de build afin d'exécuter du code arbitraire pour prendre le contrôle du serveur et voler des données.

Système à plusieurs ordinateurs

Les équipes de taille moyenne et de grande taille auront généralement besoin de plusieurs ordinateurs de build pour prendre en charge leurs efforts. Dans l'exemple suivant, deux ordinateurs de build sont déployés.

En utilisant plusieurs ordinateurs de build, vous pouvez dédier chaque ordinateur à un objectif différent, comme décrit dans l'exemple suivant :

• Un ordinateur de build peut être dédié aux agents de build qui traitent les builds d'intégration continues. 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. Vous pouvez utiliser les paramètres de processus de génération pour garantir que les builds s'exécutent rapidement. Ces paramètres peuvent indiquer de ne pas nettoyer l'espace de travail, d'exécuter uniquement les tests de priorité majeure et de définir une faible valeur pour le paramètre Durée d'exécution maximale.

• Un autre ordinateur de build peut être dédié aux builds planifiées et ad hoc dont le traitement requiert beaucoup de temps. Par exemple, vous pourriez configurer les définitions de build qui ciblent les agents de build sur cet ordinateur de sorte qu'elles nettoient l'espace de travail, effectuent tous les tests et exécutent l'analyse du code.

Système à plusieurs ordinateurs avec plusieurs contrôleurs

L'exemple de topologie suivant peut prendre en charge les efforts logiciels au niveau de l'entreprise.

Chaque collection de projets d'équipe doit avoir son propre contrôleur de build, comme indiqué dans l'illustration. Notez la façon dont cette topologie isole les ordinateurs 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.

Étapes suivantes

Maintenant que vous comprenez comment fonctionne un système Team Foundation Build, vous êtes prêt à passer aux étapes suivantes :

• Configurer votre système de génération

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