Mise en place d'un serveur d'Intégration continue avec TeamCity et Visual SVN Server

L'intégration continue est une technique consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression de l'application en cours de développement.

Pour appliquer cette technique, il faut d'abord que :

• le code source soit partagé (en utilisant des logiciels de gestion de versions tels que Visual sourcesafe ou Subversion) ;
• les développeurs intègrent régulièrement (au moins une fois par jour) leurs modifications ;
• des tests soient développés pour valider l'application ;
• enfin, il faut qu'un outil d'intégration continue lance des actions de compilation, lance les tests, et génère un rapport sur la réussite ou non de ces actions.

Les principaux avantages d'une telle technique de développement sont les suivants :

• les problèmes d'intégration sont détectés et réparés de façon continue, évitant les problèmes de dernière minute ;
• la compilation du code source n'est plus dépendante de la machine d'un développeur ;
• les unités modifiées sont testées immédiatement ;
• une version est toujours disponible pour test, démonstration ou distribution.

TeamCity est un système d'intégration continue dont le principal mérite est la facilité de mise en œuvre, d'être très graphique, et de contenir quelques très bonnes idées.

Depuis bientôt deux ans, j'utilise quotidiennement CruiseControl.net (ou presque…), et, même si c'est un système facile à mettre en œuvre avec un peu d'expérience, il est souvent difficile de « vendre » la demi-journée nécessaire à l'installation et à la configuration du serveur.

TeamCity conjugue les avantages d'être gratuit dans sa version professionnelle (jusqu'à 20 cibles de build, on verra plus tard à quoi cela correspond), et plus simple à mettre en œuvre que CruiseControl. De plus, il permet de mettre en place beaucoup de choses sans avoir à mettre les mains dans le moteur.

Visual SVN est un serveur subversion, qui tourne sous Windows. Je l'ai choisi pour ce tutoriel, car il est facile à mettre en place, et gratuit dans le cas de projets open source.

Pour ne pas faire d'aller-retour entre les serveurs, je vais commencer par le contrôleur de code source.

L'installeur se présente sous la forme d'un msi, et l'écran le plus compliqué est celui où on nomme notre serveur.

En fin d'installation, Visual SVN Server se lance.

Pour le tutoriel, je vais créer un nouveau repository, testTeamCity.

La création du repository est simplissime, il suffit de faire un clic droit sur Repositories, et de nommer le repository.

De la même façon, je vais créer un utilisateur pvialatte dans le groupe des utilisateurs.

Avec TortoiseSVN, je vais me connecter à mon repository testTeamCity, et faire un checkout dans le répertoire D:\Projets\testTeamCity.

Comme j'ai créé une structure par défaut, dans mon répertoire testTeamCity, je vais trouver les répertoires branches, tag et trunk.

Dans Visual Studio, je vais créer une nouvelle solution, dans le répertoire trunk. Une fois ma solution créée (un projet winform de base), j'utilise tortoise pour faire un checkin dans subversion.

Le compteur tourne, cela fait dix minutes que j'ai commencé à mettre en place l'environnement.

Si ce n'est pas encore fait, il faut se rendre sur le site de Jetbrains pour y télécharger TeamCity.

Une fois l'installeur téléchargé, il faut lancer l'installation (suivant, suivant…).
En fin d'installation, l'installeur propose de lancer les services de TeamCity, et de lancer le site web.

Le reste de la configuration se fait dans le serveur web de TeamCity (dans mon cas, http://localhost:80)
Après avoir accepté les conditions générales, il nous faut créer un compte administrateur.

Une fois notre compte administrateur créé, on arrive sur la page d'administration centrale.

On clique donc sur Create Project, on indique un nom et une description pour notre projet.
Une fois ces actions effectuées, le serveur nous redirige vers la page de configuration de notre projet.

Notre action suivante va être de créer une configuration de build. Pour cela, on va donner un nom à notre configuration, et indiquer un certain nombre d'actions.

Une fois cette configuration de build effectuée, il nous faut choisir le contrôleur de code source à utiliser.
Dans notre cas, nous allons choisir Subversion, avec comme URL https://localhost:8443/svn/testTeamCity/, et le username et password que nous venons de créer. On peut aussi changer l'intervalle entre deux vérifications de modifications (60 secondes par défaut).
Le bouton de test de la connexion permet de vérifier (en Ajax, en plus…) que notre connexion est fonctionnelle.

Une fois ces actions effectuées, on va cliquer sur save, pour passer à la sélection du système de build.

Pour notre premier build, on va effectuer la compilation de la solution au format Visual Studio 2008.
Une fois de plus, la configuration côté TeamCity est limpide. Il suffit, sur cet écran, de renseigner le chemin de la solution (dans notre cas, trunk\testTeamCity.sln), la cible que l'on va exécuter, et la configuration de build associée.

Comme j'ai ajouté une assembly de test dans ma solution, j'ajoute le chemin dans lequel on pourra la trouver, ici, Test\bin\Release\Test.dll.

Il faut ensuite définir les modalités selon lesquelles on va lancer un nouveau build.
Comme nous mettons en place un système d'intégration continue, on va lancer un nouveau build dès que l'utilisateur commite des fichiers.

On va donc aller dans la rubrique build triggering, et simplement cocher la checkbox « Enable triggering when files are checked into VCS », et sélectionner un intervalle de 60 secondes (la valeur par défaut).

Une fois ces actions complétées, nous pouvons nous rendre sur la page d'accueil de notre projet.
Si tout s'est bien passé, vous devriez avoir passé environ une vingtaine de minutes, et la page d'accueil de votre projet devrait ressembler à ceci :

Pour vérifier que tout fonctionne bien, nous allons faire une modification dans notre projet.
Dans mon cas, je vais ajouter un test… qui va faire échouer la compilation, et faire un check-in. Pour les curieux, je vais décommenter ces lignes dans le fichier d'exemple de Nunit (oui, pas très courageux, mais j'ai un horaire à respecter…) :

#region Invalid Code Tests
// This method contains assertions that should not compile
// You can check by uncommenting it.
public void WillNotCompile()
{
Assert.That(42, Is.Not);
Assert.That(42, Is.All);
Assert.That(42, Is.Null.Not);
Assert.That(42, Is.Not.Null.GreaterThan(10));
Assert.That(42, Is.GreaterThan(10).LessThan(99));

object[] c = new object[0];
Assert.That(c, Is.Null.All);
Assert.That(c, Is.Not.All);
Assert.That(c, Is.All.Not);
}
#endregion

Après une soixantaine de secondes (en fait, comme je suis impatient, je vais cliquer sur Run…), l'affichage de la page va être modifié, mon build ne compilant plus.

Poussé par la curiosité, je vais cliquer sur la ligne correspondant à mon dernier build, et arriver sur une page de détails.

En tant que développeur responsable, je vais prendre la responsabilité de fixer ce bogue, en cliquant sur « Take responsibility ».
Après avoir rentré un message expliquant pourquoi cela ne fonctionne pas, tous les autres développeurs peuvent désormais voir que c'est moi qui suis responsable de l'erreur de compilation, et que je vais la réparer.
L'affichage va être mis à jour, pour indiquer que c'est effectivement de ma faute si « l'usine logicielle » de ma société est en panne…

Je vais donc me dépêcher de réparer mes erreurs avant que mon chef de projet ne passe sur le serveur (ah, il a reçu un mail parce que j'ai cassé le build ? raison de plus pour se dépêcher ;) ). Je retourne sous Visual Studio, je fais passer mon test, je commite et je retourne sous TeamCity.
Là, je vois mon interface se mettre à jour…et repasser au vert (ouf !)

Comme j'avais promis de tout voir en 30 minutes, et qu'il devrait vous en rester quelques-unes, on va juste voir comment faire pour ne pas avoir à ouvrir TeamCity cinq fois par minute.

Après avoir bien configuré notre serveur, on va changer de casquette, pour se mettre à la place de notre vénéré chef de projet ;).
Plutôt que de passer sur TeamCity toutes les deux minutes pour voir si des modifications ont eu lieu, ou, à l'inverse, de passer une seule fois par semaine, le tray notifier permet à chaque membre du projet d'être informé en continu et en temps réel de la santé et du statut du serveur.
Pour l'installer, il faut se rendre dans « My Settings & Tools », puis télécharger le window tray notifier

Une fois cet exécutable téléchargé et installé (une fois de plus, next, next, next, install, launch…), l'application demande l'URL de notre serveur TeamCity (chez moi, http://localhost), puis mon login et mon password.

Le tray notifier s'affiche ensuite sous la forme d'une icône dans la barre Windows. Lorsque l'on clique sur cette icône, une fenêtre de Visualisation de statut s'ouvre.

Comme je n'ai pas encore effectué de configuration de build à suivre, l'application me propose de mettre à jour mes paramètres… ce que je vais faire en cliquant sur Edit Settings.
Une page d'édition des paramètres du tray notifier s'ouvre alors.

Il me suffit alors de sélectionner mon projet, la cible d'intégration, et les cas dans lesquels déclencher une notification… pour être notifié « en live » de l'état de mon serveur de build