Scrum, XP et TFS 2010

Team Foundation Build est le service de gestion et planification des builds de la suite Team System. Nous allons commencer par configurer ce service pour notre collection de projet puis nous créerons notre première build d’équipe.

Structure du service

Afin de mieux comprendre la structure du service voici un schéma l’illustrant :

On remarque qu’un serveur de build permet de gérer plusieurs contrôleurs et ce afin de pouvoir répartir la charge entre plusieurs serveurs assumant chacun le rôle de contrôleur.

Chaque Contrôleur de build est dédié à une et une seule collection de projets.

Ils permettent eux de gérer plusieurs agents de Build dans le but de simplifier au maximum les différents types de builds que l’on souhaite mettre en place et de coller au plus près à la structure de vos projets.

Les agents de builds effectuent directement les tâches suivantes :

• Récupérer et valider le code depuis le gestionnaire de sources
• Compile le code
• Exécute les tests

La structure de notre service de builds pourra donc être très simple comme très complexe en fonction de vos besoins.

Ainsi on peut imaginer attribuer un Build Agent par Collection de projets puis dans chaque contrôleur, créer un Build agent pour les builds complètes programmées chaque soir, un autre pour des builds spécifiques ou par module, et une dernière pour l’intégration continue (à chaque check-in).

Toutes les possibilités sont exposées sur le site msdn :

http://msdn.microsoft.com/en-us/library/dd793166(VS.100).aspx

Configuration du service

Ouvrez une session sur le serveur avec un compte membre des Administrateurs de la machine.

Depuis la console MMC Team Foundation Server Administration Console, ouvrez le detail du serveur de Build en cliquant sur Team Foundation Build.

Par défaut aucun service n’est configuré. Pour configurer le Service de Build :

• Cliquez sur Configure sous le nom de votre serveur

Dans la fenêtre de configuration :

• Cliquez sur Browse afin de sélectionner votre collection de projet
• Choisissez le compte TFSService afin d’exécuter le service de Build
• Saisissez le mot de passe du compte TFSService
• Cliquez sur Start

Configuration du Contrôleur

Une fois le service de build installé et lancé, cliquez sur New Controller.

Un contrôleur par défaut est créé, nous devons le configurer, cliquez sur Properties

• Spécifiez un nom plus parlant que Default controller
• Entrez une description si nécessaire
• Passez le statut d’Unreachable à Enabled
• Cliquez sur OK

Le contrôleur est alors configuré correctement mais n’est pas encore lancé, cliquez sur Start pour le démarrer.

Configuration de l’agent

Une fois le contrôleur correctement configuré et prêt, cliquez sur New Agent

Dans les propriétés du nouvel agent :

• Saisissez un nom et une description claire pour l’agent
• Sélectionnez le Contrôleur que l’on à créé pour la collection
• Changez le statut à Enabled
• Cliquez sur OK

Une fois toutes ces étapes complétées, vous devriez obtenir l’affichage suivant :

Virtualisation des contrôleurs

Si vous disposez d’un serveur puissant doté d’Hyper-V, vous pourrez créer une machine virtuelle par contrôleur. L’exécution de contrôleurs de build, et de leurs agents dans une machine virtuelle freine sensiblement les performances, mais offre une sécurité supplémentaire grâce à Hyper-V et sa gestion avancée des points de sauvegardes qui permettent un retour en arrière en cas de problème.

Microsoft préconise dans ce cas d’attribuer au moins un cœur du processeur ainsi qu’un disque dur physique par contrôleur afin de ne pas trop altérer les performances des agents.

Création d’une Build programmée

Pour cet exemple, nous allons programmer une compilation de l’intégralité du projet qui interviendra tous les jours ouvrés de la semaine à 1h du matin afin que les développeurs disposent d’une version à jour chaque matin à leur arrivée.

Ouvrez Visual Studio, puis dans le Team Explorer déroulez votre projet puis effectuez un clic droit sur le dossier des builds et enfin cliquez sur New Build Definition.

• Dans l’onglet Général, vous devez saisir un nom et une description pour la Build qui vous permettrons de l’identifier par la suite.

• Dans l’onglet Trigger, vous pouvez configurer les conditions dans lesquelles la compilation devra s’exécuter. Les possibilités sont les suivantes :
  • Manual : Déclenché par l’utilisateur
  • Continuous integration : Déclenché à chaque dépôt sur le contrôleur de code source
  • Rolling builds : Déclenchement après un intervalle de temps spécifique
  • Gated check-in : compile et teste l’intégrité du code avant de valider chaque dépôt de code
  • Schedule : Déclenché selon un planning déterminé

  C’est donc ce dernier que l’on va utiliser en programmant une nouvelle compilation tous les jours ouvrables à 1h du matin :

• Dans l’onglet Workspace, il s’agit de déterminer l’espace de travail sur lequel porte la compilation, par défaut il s’agit du dossier de travail de votre projet. Dans notre cas nous laisserons donc la valeur par défaut.

• Dans l’onglet Build Defaults, sélectionnez le contrôleur créé précédemment et saisissez un chemin réseau pointant sur un partage du serveur créé à cet effet :Important : Pensez à donner les droits en Lecture, Ecriture et Modification sur le partage au compte de service utilisé par Team Foundation Service (TFSService).

• Dans l’onglet Process, il est possible de définir un fichier template de Build codé avec le language XAML afin de personnaliser le processus de compilation.Nous nous contenterons pour l’instant de garder le template par défaut.

• L’onglet Retention Policy permet de configurer le nombre de builds conservés en historique pour chaque résultat possible (stoppé manuellement, échoué, partiellement réussi et réussi).
  

  Onglet Retention policy

Sauvegarder la Build Definition. Elle apparaît maintenant dans Team Explorer et sera exécutée en temps et en heure.