JetBrains TeamCity 4

Cet article parle de la nouvelle version (4.0) de TeamCity (connue sous le nom de code Calcutta), sortie lors de la dernière semaine du mois de novembre 2008.

L'article présentera succinctement les grands principes de l'intégration continue, ainsi que la société JetBrains et en particulier son outil TeamCity. Nous ferons par la suite un tour rapide sur la nouvelle mouture de TeamCity, puis la testerons à la fois dans un environnement Java et dans un environnement .Net.

Cet article est rédigé à quatre mains, d'un côté par Romain Linsolas (romaintaz) dont le but sera de tester TeamCity pour des projets Java, et d'autre part Philippe Vialatte (pvialatte) qui s'occupera de la partie .Net. C'est pour cette raison que les parties principales de cet article, à savoir le test de TeamCity ainsi que les avis, sont dupliquées.

Avant toute chose, voyons rapidement quelles expériences nous avons, tous les deux, avec les outils d'intégration continue.

I-C-1. Romain▲

I-C-2. Philippe▲

Avant de parler de l'outil JetBrain TeamCity, je vous propose un petit rappel sur ce qu'est l'intégration continue et ses intérêts.

L'intégration continue (« I.C. ») est le nom donné initialement par la communauté de l'Extreme Programming (« XP ») pour désigner la pratique de génie logiciel visant à accélérer la livraison des logiciels en réduisant le temps d'intégration.

Pour que l'intégration continue puisse se faire correctement, il faut tout d'abord partager les sources du projet via un serveur de Gestion de Contrôle des Sources (ou « SCM » pour Source Control Management) tel que CVS ou Subversion. Il faut également que les équipes de développements postent (committent) régulièrement les modifications apportées au code, de préférence plusieurs fois par jour. Enfin, il est nécessaire de disposer de tests unitaires qui seront exécutés par l'outil JUnit ou TestNG par exemple.

La présence des tests n'est en réalité pas obligatoire, mais elle est très fortement conseillée. Ils ont en effet pour tâche principale de vérifier que le code ne subit pas de régression, et que les fonctions implémentées réalisent correctement leurs tâches. Plusieurs types de tests existent (tests unitaires, fonctionnels, graphiques, de déploiement, etc.), chaque type ayant un rôle précis dans la vérification de l'application et de son code. Les tests étant un (très) vaste sujet, nous ne nous y étendrons pas davantage dans cet article.

Des outils vont alors se charger de vérifier régulièrement les modifications sur le SCM afin d'assurer la non-régression de l'application, en compilant l'ensemble du projet et en en exécutant les tests unitaires.

Globalement, les principaux intérêts de l'IC sont les suivants :

• vérification fréquente du code, et de sa bonne compilation ;
• réalisation des tests unitaires et/ou fonctionnels, voire tests d'intégration ;
• mise à disposition éventuelle d'une version testable comportant les dernières modifications du code (on pourra ainsi faire déployer son WAR sur un serveur Tomcat tous les jours) ;
• possibilité de créer des rapports périodiques exprimant la qualité du code, la couverture des tests, etc. Si le projet est configuré pour Maven, alors on pourra créer le site du projet qui contiendra l'ensemble de ces rapports.

Les deux premiers avantages de cette liste montrent que l'IC permet de détecter quasi immédiatement la présence d'un problème dans le code… et donc d'y apporter une solution instantanément !

II-B-1. De l'intérêt des outils▲

II-B-2. Les outils existants▲

JetBrains est une société tchèque (le centre de R&D se situant en Russie), bien connue dans le monde Java en particulier en tant qu'éditrice de l'outil de développement (« IDE ») IntelliJ IDEA, dont la version 8 vient juste de sortir. JetBrains est également la société éditrice de l'IDE RubyMine pour le Ruby and Rails.
Les pratiquants de .Net connaissent surtout JetBrains pour leur add-on Resharper, qui est tout simplement le meilleur add-on existant pour Visual Studio .Net.
Enfin, l'un des autres produits majeurs au sein de leur catalogue est TeamCity, leur outil adressant la problématique de l'intégration continue, et qui est le sujet de notre article.

III-B-1. Introduction et historique▲

III-B-2. Licences▲

III-B-3. Environnements supportés▲

Comme cela a été dit précédemment, l'intégration continue ne saurait fonctionner sans un système de gestion de sources, « SCM ». JetBrains TeamCity supporte les systèmes suivants:

• Borland StarTeam 6 et au delà^1 ;
• CVS^2 ;
• IBM Rational ClearCase, modes Base et UCM^1 ;
• Microsoft Visual SourceSafe 6 et 2005^1 ;
• Perforce^1 ;
• Subversion^2 ;
• Team Foundation Server 2005 et 2008¹.

¹ L'application client doit être installée séparément pour être utilisable par TeamCity.
² L'application client est intégrée directement dans TeamCity et ne nécessite donc pas d'installation extérieure.

D'un point global, l'image ci-dessous schématise l'ensemble des environnements supportés par TeamCity, qu'il s'agisse de SCM, d'IDE, de plateforme de développement, ou encore de navigateurs Internet :

III-B-4. Nouveautés de la version 4.0▲

TeamCity demande tout d'abord une JRE (Java Runtime Environment) dont la version est au moins égale à 5.0. L'outil tourne sur un serveur J2EE, de type Tomcat, la version 6 étant recommandée, mais fonctionne quand même sur une version 5. Enfin, TeamCity peut être hébergé sur un environnement Windows XP (ce qui sera notre cas), Linux ou MacOS X, le système Solaris 10 étant a priori utilisable. Cette page regroupe l'ensemble des informations relatives à la configuration nécessaire pour faire tourner TeamCity.

Nous choisissons de télécharger le package compressé TAR.GZ, qui correspondant à une installation manuelle de l'outil. Il existe cependant une version sous forme d'exécutable pour Windows, peut être plus facile à utiliser.

La procédure complète d'installation se trouve ici.

Nous opterons pour la solution de facilité, à savoir que nous utiliserons la configuration par défaut, à l'exception toutefois de l'utilisation de la base de données (MySQL). Le serveur sera donc accessible via l'URL par défaut, à savoir http://localhost:8111.

La première chose que l'on a à faire, une fois le serveur démarré, c'est d'accepter les conditions d'utilisation du logiciel, puis de créer le compte d'administrateur. Nous vous passons les détails, mais tout est expliqué ici. C'est agréable d'avoir cette création sous forme graphique, et non sous la forme d'un fichier XML (ou autre) à configurer !

La page d'accueil de TeamCity est pour l'instant vide, mais propose déjà quelques options, dont la création du premier projet !

Avant de créer un projet, voyons rapidement les pages annexes, en particulier la page d'administration ainsi que celle des options du compte courant.

La page de paramétrage propose le réglage des options générales, du type nom, adresse email, mot de passe, etc.

On peut aussi régler la notification par mail de façon très fine :

C'est également ici que l'on retrouve les outils s'interfaçant avec TeamCity, dont un notificateur Windows, un flux RSS ou encore des plugins pour les IDE ItelliJ IDEA, Eclipse ou Visual Studio. Même si nous n'utilisons pas NetBeans, il est regrettable qu'il n'existe pas de plugins TeamCity pour cette plateforme pourtant populaire !

Dans la page d'administration, on retrouve :

• la gestion des projets (création, édition, suppression) ;
• la configuration des SCM (gestionnaires de contrôles de sources) ;
• la gestion des historiques (combien de temps les données sont conservées par exemple) ;
• la configuration du serveur ;
• la gestion des utilisateurs ;
• la gestion des licences.

Nous l'avons vu dans le chapitre précédent, TeamCity offre plusieurs types de plugins offrant une interface avec l'outil de JetBrains. Je vais donc regarder de plus près le plugin pour Eclipse. Pour fonctionner, il est nécessaire que le plugin Subclipse (gestionnaire de Subversion) soit installé.

L'installation se fait relativement simplement, puisque le serveur TeamCity héberge le plugin, et il ne suffit que de donner une URL locale à Eclipse pour que l'installation se fasse.

Une fois l'installation terminée, un nouveau menu est disponible, logiquement appelé « TeamCity » :

Il suffit de configurer le plugin pour se connecter avec son compte sur le serveur TeamCity :

Dès lors, je peux contrôler un certain nombre de choses sur TeamCity directement via Eclipse, en particulier voir l'état actuel du serveur (quels builds sont en cours, quels sont les statuts des différents projets, etc.).

Passons maintenant à l'étape suivante, celle consistant à créer un nouveau projet. Comme on peut s'y attendre, la page d'accueil propose la création d'un nouveau projet. La première étape consiste à lui trouver un nom, et si possible une courte description.

TeamCity me propose maintenant de lui ajouter une configuration de build :

Ici, rien de très particulier, mais j'apprécie de pouvoir définir les conditions qui définissent un échec de build :

• le code de sortie est différent de 0 ;
• au moins un test a échoué ;
• une erreur a été logguée ;
• le build prend trop de temps (la durée étant bien entendu réglable).

La deuxième étape nous demande de spécifier la façon dont TeamCity va réaliser les checkouts du code.

C'est naturellement ici que je définis la configuration de mon SCM, à savoir les informations de connexion au serveur Subversion.

Chose extrêmement appréciable : un petit bouton en bas permet de tester la validité des informations de connexion. Voici le genre d'options qui permettent de gagner du temps (ou de ne pas en perdre !) et dont TeamCity regorge…

Dernière étape, la création du « builder », c'est-à-dire la définition de la construction du projet.

Dans mon cas, j'opte pour un projet Maven2, mais je constate que le choix est très large :

Voilà, je sauvegarde ma configuration de build, et mon projet est enfin prêt à être exécuté.

En réalité, il existe d'autres éléments de configuration pour un type de build :

Rapidement, ces autres éléments permettent de définir :

• les « triggers », c'est-à-dire les évènements qui déclenchent l'exécution d'un build : modifications des sources sur le SCM, tâches planifiées, etc. ;
• les dépendances ;
• les variables d'environnement et propriétés systèmes ;
• les prérequis pour les agents (par exemple le système d'exploitation, la version du framework .Net installé, etc.).

Grâce au bouton « Run » disponible depuis pas mal d'endroits de l'interface, il est possible de lancer notre projet. Il est possible, en cliquant sur l'agent réalisant le build, de suivre l'avancée de la construction de notre projet :

Travaillant souvent sur des projets multimodules sous Maven2, je m'aperçois que TeamCity n'offre pas une indication précise du module sur lequel il est actuellement en train de travailler, contrairement à ce que propose Hudson par exemple. C'est quelque chose que j'aurais apprécié d'avoir, même si cela n'est pas vital…

Voici, sur la page principale, la vision de l'exécution réussie de mon projet :

En cliquant sur le projet, on voit les détails de l'exécution du projet :

Cette fois-ci, je décide de modifier des tests unitaires, afin d'en rendre certains faux. Le build apparaît bien en échec, et les détails nous montrent clairement les tests qui sont en échec :

Comme on peut s'y attendre, je reçois un email de TeamCity me signalant cette erreur. Le contenu de cet email ressemble par défaut à quelque chose comme :

Build DVP Test::Build principal #6 failed (compilation failed)
Agent: Default agent
Build results: http://localhost:8111/viewLog.html?buildId=6&buildTypeId=bt2

Compilation errors
==================
Compilation failure
C:\(...)\org\apache\commons\lang\builder\MultiLineToStringStyleTest.java:[83,8] cannot find symbol
symbol  : method assertNotEquals(java.lang.String,java.lang.String)
location: class org.apache.commons.lang.builder.MultiLineToStringStyleTest
C:\(...)\org\apache\commons\lang\builder\MultiLineToStringStyleTest.java:[83,8] cannot find symbol
symbol  : method assertNotEquals(java.lang.String,java.lang.String)
location: class org.apache.commons.lang.builder.MultiLineToStringStyleTest

Changes included (1 change)
====================================================
Change 7 by romaintaz (1 file):
Fail test.

see more information about changed files: http://localhost:8111/viewLog.html?tab=buildChangesDiv&buildId=6&buildTypeId=bt2


============================================================================
Configure email notifications: http://localhost:8111/profile.html?init=1#notifications

Pour chaque test en erreur, on peut soit en voir les détails, soit ouvrir le test en question dans l'IDE. Effectivement, en cliquant sur l'option « Open in IDE », Eclipse m'ouvre automatiquement le fichier où se trouve le test échoué. À nouveau, une option vraiment appréciable ! J'adore !

Avoir une vision à un instant donné de l'état de son projet est quelque chose d'important. Mais plus important encore est d'en voir l'évolution au cours du temps. Je jette donc maintenant un œil attentif sur les fonctionnalités d'historique ainsi que sur les statistiques proposées par TeamCity.

Dans la vue des détails d'un build exécuté, une option « All history » permet de visualiser l'ensemble de l'historique sur le projet :

L'onglet statistiques offre une vue rapide du pourcentage de succès des builds, des durées de construction et d'attente, ainsi que pourcentage de réussite des tests unitaires.

À noter que les graphiques sont interactifs. Ainsi, en déplaçant le curseur sur l'un des points du graphique des tests unitaires, on peut en voir les détails :

L'onglet « Problematic Tests » liste les tests le plus souvent en échec. Il s'agit là d'une fonctionnalité appréciable, visant à cibler précisément les parties de son code qui pourraient être les plus problématiques, ou les plus sujettes aux (mauvais) changements.

Un autre graphique intéressant est le temps moyen nécessaire pour corriger un build cassé. Cela se présente sous la forme d'un graphique de type nuage de points :

Enfin je finirais ce chapitre sur les statistiques avec la possibilité de connaître l'historique de la charge des différents agents. Cela peut s'avérer pratique pour savoir si la répartition des builds entre chaque agent est bien réalisée, ou si le nombre d'agents est suffisant pour gérer tout le parc de projets de son entreprise. En voici l'illustration (j'ai pris cette image depuis le site officiel, car la capture est plus parlante) :

V-E-1. Recherche de duplicats▲

Je décide maintenant de tester les capacités de TeamCity concernant la recherche de duplication de code. Pour ce faire, je crée une nouvelle configuration de build en copiant celle créée précédemment. Je n'ai alors besoin que de configurer la partie concernant le Build Runner :

Quelques options sont là pour définir les critères de recherche de duplications :

Le projet se présente alors comme un projet « normal ». Je l'exécute donc comme je l'avais fait pour mon premier projet. Une fois son exécution terminée, le rapport du build me propose un nouvel onglet, justement appelé « Duplicates ». Cet onglet permet d'accéder aux rapports créés par TeamCity, qui semble très complet :

V-E-2. Inspection▲

Je teste maintenant un autre type de Build Runner, le « Inspections ». Il s'agit d'une fonctionnalité partant à la recherche des erreurs de codage, potentiellement source de bugs. Cela s'apparente à la tâche réalisée par des outils tels que Checkstyle ou PMD. Comme dans le chapitre précédent, je choisis de prendre mon premier projet comme origine, et je change la configuration du Runner.

Une fois ce nouveau projet créé puis exécuté, comme l'on peut s'y attendre, les résultats sont accessibles via l'onglet « Code Inspection ». L'interface graphique offre la possibilité de filtrer les erreurs par package ou encore par type d'erreur :

Lorsqu'un développeur commite du code sur le SCM, il est possible que ce code comporte des erreurs. Dans ce cas, et jusqu'à ce que l'erreur soit corrigée, le code contenu par le SCM est erroné, et cela peu avoir des impacts sur le reste de l'équipe.
Voici le scénario classique :

On le voit, le SCM contient une version erronée du code, jusqu'à ce que celui-ci soit corrigé.
Pour résoudre ce problème TeamCity propose la fonctionnalité des « commits prétestés », ou encore de « commits retardés », comme le montre le schéma suivant :

TeamCity agit comme une sorte de proxy vis-à-vis du commit, en testant au préalable le code avec la nouvelle modification. Si ce code ne casse pas le build de l'application, alors la modification est effectivement commitée dans le SCM. Si au contraire le build échoue, alors le développeur auteur de cette modification est averti, et peut immédiatement modifier son code afin de le corriger. Ainsi, le reste de l'équipe n'est pas impacté par cette erreur.

Voici les étapes exactes réalisées par le serveur TeamCity lors ce processus de commits prétestés :

Lors de mes tests sur Eclipse, afin de profiter de ce principe, il fallait que mon projet soit hébergé sur un serveur Subversion pour que cette fonctionnalité puisse être utilisable. Pour disposer de cette fonctionnalité pour des projets CVS, il m'aurait fallu utiliser l'IDE de JetBrains, IntelliJ IDEA.

On va d'abord créer le projet. Pour cela, on va donner un nom et une description, et sélectionner un contrôleur de code source.

La création du contrôleur de code source est assez simple.
Il suffit en fait de cliquer sur Create VCS root, de nommer le contrôleur de code source, de sélectionner le type (Clearcase, CVS, Perforce, StarTeam, Subversion, TFS ou SourceSafe), puis, en fonction du type de contrôleur, de rentrer les informations de configuration. On va aussi définir les intervalles entre deux vérifications de mise à jour.

Une fois la source sélectionnée, on va créer une configuration de build, que l'on va appeler test. La ou les choses vont changer par rapport au projet Java est que l'on va sélectionner sln2008 comme Build Runner.
Le fait de sélectionner un Build Runner .net va modifier les options de tests, et on va désormais pouvoir sélectionner des projets de tests, soit au format NUnit, soit au format MSTest.

Le fait de configurer notre cible de compilation permet dès à présent de voir sur le serveur le résultat de la compilation du projet.

Pour commencer, on va installer le plugin pour Visual Studio. Pour cela, il suffit de se rendre dans « My Settings & Tools », puis de cliquer sur « plugin for visual studio ».

Une fois le plugin téléchargé, on va l'installer. Pour cela, il suffit de lancer l'exécutable, d'accepter les conditions générales, et de cliquer sur « install ».

L'installation effectuée, on va aller voir dans Visual studio comment s'intègre le plugin.
Après le lancement de l'IDE, on s'aperçoit qu'un nouveau menu « TeamCity » est apparu. L'un des seuls choix étant de se connecter au serveur, on va cliquer sur Login, et se connecter au serveur local.

Une fois connecté, je vais faire une modification mineure dans mon projet, puis une qui va entraîner une erreur de compilation.

On voit bien la liste des compilations, avec les options de masquer les compilations lancées par un de mes commits, ou celles qui ont réussi. En cliquant sur l'un des éléments de la liste, on visualise en plus la liste des tests qui ont été exécutés, avec de la même façon un pictogramme indiquant la réussite ou l'échec du test, ainsi que l'option de masquer les tests réussis, ou d'ouvrir le détail des tests ou de la compilation sur le serveur.

Ma solution étant toujours dans un état où elle ne compile pas, je vais corriger localement mon projet, et vérifier qu'il compile avant de faire un commit. Toujours dans le menu TeamCity, je vais maintenant sélectionner « Remote Run », pour faire un commit prétesté.

L'add-in va lancer la compilation sur l'agent, vérifier que la compilation réussit, et va enfin faire un commit automatiquement. Au retour dans mon interface d'administration, je vois que le projet a aussi été compilé sur le serveur.

TeamCity permet d'accéder à un historique complet des compilations effectuées sur le serveur. Pour cela, il suffit de se rendre sur la page du projet, puis de cliquer sur la cible de compilation.
On arrive alors sur la fenêtre suivante :

Les onglets les plus intéressants dans cette fenêtre sont les onglets « Overview » (onglet par défaut), « Statistics » (qui affiche les statistiques de réussite / échec des compilations), et settings, qui permet de visualiser et de modifier les paramètres de la cible de compilation.

VI-C-1. Onglet Overview▲

C'est le premier onglet sur lequel on arrive lorsque l'on accède au projet. On peut voir ici les dernières compilations (ou tentatives), ainsi que, pour chaque tentative, les informations suivantes :

• le numéro de tentative ;
• le type de compilation (personnelle ou non), et une information sur la réussite de l'évènement (icône rouge ou verte) ;
• le résultat de la compilation (success/failure) ;
• les artefacts de compilation, qui sont des objets produits par la compilation (install.zip, exécutables…). Le répertoire dans lequel les artefacts sont stockés est géré dans les paramètres du projet (Artifact paths) ;
• les changements depuis la dernière tentative de compilation ;
• la date et l'heure de débit de la compilation ;
• la durée de la compilation ;
• l'agent responsable de la compilation ;
• des tags, éditables après compilation pour ajouter de l'information ;
• une fonctionnalité pour « punaiser » une compilation donnée dans l'historique, pour éviter qu'elle ne soit supprimée lors d'une vidange de l'historique.

Certains de ces éléments ont des menus rattachés, qui permettent des actions spécifiques.

La colonne « Results » permet d'accéder au log et aux paramètres du build donné, ce qui permet de donner une idée plus précise des raisons de l'échec d'une compilation

La colonne « Changes » permet de visualiser les fichiers qui ont été modifiés entre deux builds, et la modification apportée.

Enfin, la colonne « Tags » permet de créer ou de modifier un tag pour une compilation donnée. Par exemple, on pourra tagger une compilation après livraison dans un environnement spécifique, ou après une deadline ou une étape importante.

VI-C-2. Onglet Statistiques▲

La version testée étant la version Entreprise, on va tester la création de profils d'utilisateurs. Cette fonctionnalité permet de définir des profils différents par projet. Par exemple, sur un projet donné, je peux être Administrateur, sur un autre, juste avoir le droit de voir les résultats de compilation.

Je dois avouer que je suis un fervent défenseur d'Hudson, que j'apprécie pour sa simplicité et ses fonctionnalités avancées. Je ne regrette toutefois pas de m'être lancé dans ce test de TeamCity, car j'ai découvert un outil extrêmement complet, tout à fait mature, et vraiment agréable à utiliser.

Je vous encourage vraiment à essayer TeamCity, car il apporte un plus non négligeable par rapport aux autres solutions d'intégration continue existantes. Si le prix de la version Entreprise risque d'en rebuter certains, la gratuité de la version Professionnelle permettra à une majorité de personnes de se faire un avis personnel sur l'outil de JetBrains. Il est cependant vrai que la version Entreprise se destine avant tout aux grandes structures, pour lesquelles l'investissement correspondant à cette licence sera très vite rentabilisé, compte tenu des multiples intérêts de cet outil !

Ne connaissant pas vraiment les versions précédentes de TeamCity, je ne pourrais juger de l'intérêt de procéder à la migration d'anciennes installations (3.x avant tout) vers la version 4.0 de TeamCity, car les nouveautés ne semblent pas révolutionner l'outil, mais plutôt le consolider. À noter toutefois que cette migration, pour les possesseurs des versions Entreprise de TeamCity 3.x vers TeamCity 4, est gratuite !

Teamcity est un serveur d'intégration mature, simple à utiliser et à configurer. Dans ma société où, dernièrement, ont été qualifiés Maven d'un côté, TFS de l'autre pour l'intégration continue, le choix ayant déjà été fait, TeamCity ne sera pas utilisé. Chez mes clients, par contre, je vais probablement commencer à installer du TeamCity en lieu et place de Cruise Control.Net, ce qui devrait diminuer le temps d'adaptation des équipes à la partie administration en phase de restitution de connaissance.
L'un dans l'autre, les améliorations de la V4 sont plus, à mon avis, la cerise sur le gâteau. En conclusion, si vous n'avez rien en place dans votre société, essayez TeamCity deux semaines, je pense que vous serez conquis.