I. Introduction

Le but de ce tutoriel est de mettre en place un environnement complet d'intégration continue, de A à Z, gratuitement, et en moins de 30 minutes (hors temps de téléchargement, bien entendu ;-) ).

I-A. Intégration continue

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

I-B. TeamCity

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 a mettre en œuvre avec un peu d'expérience, il est souvent difficile de " vendre " la demi-journée nécessaire a l'installation et a 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 a mettre les mains dans le moteur.

I-C. Visual SVN

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.

II. Téléchargements et pré-requis

Comme je l'ai dit, on va essayer de rester dans la limite des 30 minutes, mais vu la taille de certains installeurs, on va commencer par les télécharger.

On va donc récupérer, dans l'ordre :

Je ne vais pas vous faire l'offense de rappeler la procédure d'installation de Visual Studio ici, on va admettre qu'il est déjà installé.

III. Installation de Visual SVN, et création de ma solution Visual Studio

III-A. Installation de Visual SVN

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 ou on nomme notre serveur.

Image non disponible

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.

III-B. Création du projet Visual Studio

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 10 minutes que j'ai commencé à mettre en place l'environnement.

IV. TeamCity

IV-A. Installation

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.

Image non disponible

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

Image non disponible

IV-B. Configuration de notre premier build

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.

Image non disponible

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.

Image non disponible

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.

Image non disponible

Une fois ces actions effectuées, on va cliquer sur save, pour passer a 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).

Image non disponible

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 a ceci :

Image non disponible

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 a respecter...) :

 
Sélectionnez

#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.

Image non disponible

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

Image non disponible

En tant que développeur responsable, je vais prendre la responsabilité de fixer ce bug, 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…

Image non disponible

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.
La, je vois mon interface se mettre à jour...et repasser au vert (ouf !)

Image non disponible

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 5 fois par minute.

IV-C. Mise en place du tray notifier

Après avoir bien configuré notre serveur, on va changer de casquette, pour se mettre a la place de notre vénéré chef de projet ;).
Plutôt que de passer sur TeamCity toute 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 a 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

Image non disponible

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.

Image non disponible
Image non disponible

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.

Image non disponible

Comme je n'ai pas encore configuré 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.

Image non disponible

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

Image non disponible

V. En conclusion

Normalement, votre serveur est configuré, la demi-heure est passée…mais il reste encore pas mal de choses à voir (je reviendrai dessus dans un prochain tutorial).
Bien que je reste un inconditionnel de Cruise control (contrôle plus fin, plus de possibilités d'extensions, pas de limite aux cibles de build…), j'ai été assez épaté par la facilité de configuration et le fini de TeamCity. Ca n'est évidemment pas le couteau suisse du développeur, mais on se retrouve avec une interface très sympathique, et suffisamment de matière pour mettre en place un process de build de base.

VI. Remerciements

Merci à Maximilian pour sa relecture.