Intégration continue : compilation automatique avec TFS (18/05/2015)

J'ai l'impression en lisant de nombreux blogs, commentaires de professionnels de l'informatique reconnus que l'usage d'un serveur de Build fait partie des bases, mais j'ai rarement vu d'équipes de développement en utiliser pour de vrai. Pourtant ce n'est pas si compliqué à mettre en place, nous allons voir ça ensemble.

Les exemples que je donne ici sont basés sur mon expérience personnelle, mais pourront être adaptés et améliorés pour être utilisés sur vos projets. Tous les logiciels utilisés dans cet article sont gratuits, vous pouvez vous lancer sans problème.

Mise en place du serveur

Nos codes sources sont hébergés sur Visual Studio Online : une version en ligne de TFS (utilisable gratuitement jusqu'à 5 utilisateurs), mais ceci fonctionne avec toutes les versions de TFS.

Le service offre 60 minutes de compilation par mois. Je pensais que ça serait suffisant, mais après avoir vu qu'une compilation d'un simple projet prenait 1 à 2 minutes, je me suis rendu compte que non. Heureusement, on peut installer un serveur en local pour se charger de la compilation.

J'ai donc récupéré un vieil ordinateur, qui va servir de serveur de build. La première chose à faire est d'installer TFS sur ce serveur ; la version express de TFS suffira.

Une fois installé, un assistant se lance pour vous proposer de configurer le contrôleur de sources ou le service de Build. C'est la seconde option que nous allons lancer. (Si vous quittez l'assistant, vous pourrez toujours le relancer depuis la console d'administration de TFS).

Rien de bien compliqué dans l'assistant, il va falloir définir :

• l'adresse du serveur TFS - l'autre, celui qui héberge les sources.
• les services de build - restez avec les paramètres par défaut si vous ne savez pas quoi choisir
• le compte utilisateur qui sera utilisé par le service

Une fois l'assistant terminé, il va falloir installer les compilateurs ; le plus simple étant d'installer Visual Studio (là aussi, une version Express suffit). Et c'est bon, votre serveur et prêt à compiler !

Définitions de build

Maintenant que le serveur est prêt, il va falloir lui dire comment compiler notre projet. Vous pouvez quitter votre serveur de build et retourner sur votre Visual Studio habituel, pour créer une définition de Build.

Dans Team Explorer, lorsque votre projet est sélectionné, vous avez plusieurs options, dont "Build". Cliquez dessus.

Vous pouvez ici cliquer sur le bouton pour créer une nouvelle définition de build. Un onglet s'ouvre dans Visual Studio, avec plusieurs sections :

• General : Ici vous mettez le nom et la description. Vous pouvez aussi choisir de désactiver la définition de build ici
• Trigger : Vous choisissez à quel moment la compilation doit se lancer. Ici ce qui nous intéresse est le mode "Continuous integration", qui compile à chaque fois qu'un développeur archive.
  Vous pouvez aussi choisir de lancer une compilation à une heure précise chaque jour, ou garder un déclenchement manuel.
• Source settings : permet de définir les dossiers de travail. Sélectionnez le dossier contenant le code source.
  Si vous utilisez Git, vous devez choisir la ou les branches à utiliser.
• Build Defaults : Vous pouvez choisir ici le contrôleur de Build - normalement votre serveur de build doit apparaitre dans la liste.
  Si vous utilisez Visual Studio Online, la liste propose aussi "Hosted Build Controller" ; il s'agit du service hébergé que j'ai mentionné plus haut.
  Vous pouvez aussi choisir où déposer le résultat de la compilation. Ici on n'en a pas besoin, donc on choisit la première option, qui ne la garde pas.
• Process : C'est ici que se situe le plus gros de la configuration, on va définir comment se déroule la compilation.
  • On va commencer avec un template par défaut, cliquez sur "Show details" à droite, et sélectionnez TfvcTemplate.12.xaml ou GitTemplate.12.xaml - en fonction du contrôleur de source que vous utilisez.
    
  • En dessous, vous avez une liste de paramètres. Sélectionnez le fichier .sln à compiler. Vous pouvez regarder les autres paramètres, et les adapter selon vos besoins.
    
    Pour les autres paramètres, je ne les détaillerai pas ici, mais je vous conseille la lecture de cette page msdn.
• Retention Policy : Cette dernière section définit le nombre de build à garder en mémoire.

Vous pouvez sauvegarder, et à partir de maintenant, votre projet sera compilé à chaque fois qu'un développeur archivera du code sur TFS. La définition de build que vous venez de créer est stockée directement sur TFS, et est directement accessible à tous les développeurs depuis Visual Studio ou l'interface web de TFS.

Vous avez aussi la possibilité de lancer une compilation manuellement, en faisant un clic droit sur la définition de Build (dans Visual Studio ou l'interface web), et Queue new build.

Notifications

L'intérêt d'avoir une compilation automatique à chaque check-in est d'être au courant le plus vite possible en cas d'erreur ; il va donc falloir être notifié en cas d'erreur. Pour cela, plusieurs options sont possibles :

• Avec Visual Studio s'installe une application "Build notification", qui permet de voir l'état des Builds et d'être notifié à chaque changement. Vous pouvez la trouver dans le menu démarrer, en cherchant dans le dossier "Visual Studio Tools".
• Dans l'interface web de TFS, dans les paramètres du projet se trouve un onglet "Alert", qui permet de recevoir un e-mail à chaque fois que la build rate.
  
• Il existe un système de notification beaucoup plus efficace pour mettre la honte au développeur fautif devant toute l'équipe : la sirène de la honte. Je vous conseille la lecture de l'article de Patrice Lamarche à ce sujet.

Voilà, ce n'est qu'un aperçu des possibilités d'un serveur de build, je vous laisse découvrir ça, et on se retrouve très bientôt avec un nouvel article, qui vous expliquera comment déployer automatiquement un projet web.