IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

JetBrains TeamCity 4

La toute nouvelle version 4.0 de l'outil d'intégration continue TeamCity de JetBrains est testée par deux rédacteurs du site www.developpez.com, Romain Linsolas pour la partie Java, Philippe Vialatte pour la partie .Net. Voici leur expérience avec cet outil. ♪

Article lu   fois.

Les deux auteurs

Profil Pro

Profil Pro

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Préambule

I-A. Introduction

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.

I-B. Note sur les auteurs de l'article

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.

I-C. Contextes

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

I-C-1. Romain

Je me suis converti à l'intégration continue voilà déjà plus de deux ans.

C'est tout d'abord avec Cruise Control que j'ai fait mes premiers pas. Si l'outil était intéressant, il n'en restait pas moins assez rebutant, à cause de son interface graphique peu agréable, mais également de sa configuration peu intuitive.

Au cours d'une autre mission, j'ai eu affaire à Luntbuild, à qui je n'ai trouvé aucun attrait !

Je me suis alors tourné vers l'outil Hudson, qui reste pour moi aujourd'hui la référence en matière d'outil gratuit et open source pour l'intégration continue. J'ai par ailleurs rédigé un article complet sur cet outil.

J'ai souvent entendu parler du produit TeamCity de JetBrains, sans jamais n'avoir eu le temps de franchir le pas. C'est aujourd'hui chose faite, en profitant de la sortie de la toute dernière version - la 4.0 - de cet outil.

I-C-2. Philippe

Tout comme Romain, j'ai commencé à pratiquer l'intégration continue assez récemment, courant 2006, mais dans des environnements .Net plutôt que Java.

Dans un premier temps, j'ai utilisé CruiseControl.net, le portage en .net de Cruise control, que j'utilise encore fréquemment aujourd'hui. Tout comme la version java, la configuration reste assez technique, mais est grandement simplifiée par l'utilisation de CcnetConfig, une interface de configuration pour CCnet.

J'ai aussi eu l'occasion de travailler un peu avec Team Foundation Server, mais pour des raisons de coût de licence, l'expérience a été suspendue.

En début d'année, je suis tombé par hasard sur la version 3 de Teamcity, que j'utilise de façon personnelle de manière épisodique. Cette « rencontre » avait d'ailleurs donné lieu à un article.

Avec la sortie de la version 4.0, un de mes objectifs est de voir si cette version est celle qui me fera convertir tous mes projets de Cruise Control à TeamCity.

II. L'intégration continue

II-A. Principes

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. Outils pour l'intégration continue

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

On l'a vu dans le chapitre précédent, l'intégration continue est avant tout une question de méthodes, de processus. Toutefois, il ne peut y avoir d'intégration continue au sein d'un projet sans un outil adéquat. Ces outils vont avoir pour but essentiel d'automatiser les processus répétitifs tels que la construction du projet, l'exécution des tests unitaires, etc. Bien évidemment, leurs tâches ne se limitent pas à cela, puisque l'on retrouve souvent les fonctionnalités comme :

  • des systèmes évolués d'alertes (par mail, messageries instantanées…) lorsqu'un problème est rencontré ;
  • la construction de projets en parallèle ;
  • la surveillance des gestionnaires de builds pour lancer les builds ;
  • l'historique des builds ;
  • la sécurité ;
  • la création de nombreux rapports ;
  • l'intégration avec des outils externes (outils de gestions de bugs, IDE, etc.) ;
  • etc.

II-B-2. Les outils existants

Il existe aujourd'hui de nombreux outils d'intégration continue. Nous n'allons pas aller dans le détail de chacun d'eux, mais voici une liste (loin d'être exhaustive) des principaux outils existants dans ce domaine :

Une page faisant un comparatif assez complet entre la plupart des outils d'intégration continue existants est disponible ici.

III. JetBrains TeamCity

III-A. JetBrains

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

III-B-1. Introduction et historique

Comme nous l'avons dit, TeamCity est l'outil d'intégration continue de JetBrains

Le tableau ci-dessous montre l'évolution des versions de l'outil TeamCity au cours du temps, et met en lumière le fait qu'il s'agit d'un produit relativement récent, puisque la première version officielle n'a que deux ans.

Date

Version

Novembre 2008

TeamCity 4.0

Décembre 2007

TeamCity 3.1

Avril 2007

TeamCity 2.0

Octobre 2006

TeamCity 1.0

III-B-2. Licences

TeamCity est un logiciel commercial. Il existe aujourd'hui quatre types de licence que voici :

Licence

Prix

Commentaires

Enterprise Server License

1800 euros

Édition complète de TeamCity (avec une limitation à 3 agents).

Professional Server License

Gratuit

Édition basique de TeamCity (limitations à 3 agents, 20 configurations de builds et 20 utilisateurs).

Build Agent License

270 euros par agent

Permet de disposer de plus d'agents de build.

Open Source License

Gratuit

Correspond à la licence Entreprise, mais n'est proposée qu'aux projets open source, et pour une durée d'un an éventuellement renouvelable.

Les possesseurs de la version Entreprise de TeamCity 3.x peuvent migrer vers la version Entreprise de TeamCity 4.0 gratuitement ! C'est assez appréciable…

La gratuité de la version professionnelle est vraiment une bonne chose, car cela permet aux petites structures de disposer à peu de frais d'un excellent outil d'intégration continue. Les grandes structures pourront, quant à elles, tester - et valider - le choix de TeamCity en évaluant la version Professionnelle, avant de s'orienter vers la version Entreprise, qui s'avère bien plus adaptée à gérer un grand nombre de projets sur lesquels peuvent travailler plusieurs dizaines, voire centaines de personnes.
La version Entreprise, en plus de ne pas être limitée en nombre d'utilisateurs et de configurations de build (qui sont tous deux limités à 20 sur la version Professionnelle), permet de définir des rôles propres à chaque projet, et gère les authentifications NT et LDAP.

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 ;
  • CVS2 ;
  • IBM Rational ClearCase, modes Base et UCM1 ;
  • Microsoft Visual SourceSafe 6 et 20051 ;
  • Perforce1 ;
  • Subversion2 ;
  • Team Foundation Server 2005 et 20081.

1 L'application client doit être installée séparément pour être utilisable par TeamCity.
2 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 :

Image non disponible

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

Les principales nouveautés apportées par la version 4.0 de TeamCity sont les suivantes :

  • builds « composites », avec possibilité de répartir un même build entre plusieurs agents ;
  • builds historiques, à savoir la construction d'un projet basé sur les sources utilisées par un build antérieur ;
  • réordonnancement de l'exécution des tests, afin de faire jouer ceux qui sont le plus sujets à l'échec en premier ;
  • nouvelles statistiques ;
  • possibilité de commenter les builds terminés ;
  • amélioration du plugin Eclipse ;
  • meilleur support des projets .Net ;
  • améliorations de l'interface graphique ;
  • etc.

Voir ici la roadmap de la version 4.0 de TeamCity.

IV. Installation et configuration de TeamCity

Étant donné que l'installation et la configuration de TeamCity sont indépendantes de la plateforme de test (Java ou .Net), nous traiterons cette partie à part.

IV-A. Installation

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.

IV-B. Premiers pas

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 !

Image non disponible

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

Image non disponible

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.

Image non disponible

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

Image non disponible

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 !

Image non disponible

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.

V. Tour de TeamCity 4.0 (Java)

Je vais maintenant parler de ma première expérience personnelle avec l'outil TeamCity.

Mon environnement de test se base sur les éléments suivants :

  • TeamCity 4.0 (build 7888) ;
  • Java 1.5.0_11 ;
  • Subversion ;
  • Eclipse 3.4.0 ;
  • MySQL 5.0.45.

J'ai décidé de prendre pour mes tests les sources du projet commons-lang d'Apache, dans sa version 2.4. L'avantage de ce projet c'est qu'il dispose d'un grand nombre de tests unitaires…

V-A. Configuration

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 » :

Image non disponible

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

Image non disponible

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

V-B. Création d'un projet

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.

Image non disponible

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

Image non disponible

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.

Image non disponible

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…

Image non disponible

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

Image non disponible

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

Image non disponible

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 :

Image non disponible

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

V-C. Exécution d'un projet

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 :

Image non disponible

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 :

Image non disponible

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

Image non disponible

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 :

Image non disponible

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)
Sélectionnez
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 !

V-D. Historique et statistiques

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 :

Image non disponible

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.

Image non disponible

À 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 :

Image non disponible

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.

Image non disponible

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 :

Image non disponible

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) :

Image non disponible

V-E. Autres types de Runners

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 :

Image non disponible

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

Image non disponible

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 :

Image non disponible

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 :

Image non disponible

V-F. Commits prétestés

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 :

Image non disponible

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 :

Image non disponible

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 :

Image non disponible

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.

VI. Tour de TeamCity 4.0 (.Net)

Comme la partie Administration et l'installation ont déjà été traitées, je vais aborder directement la création de projets pour un projet .Net. Tout comme Romain, je vais utiliser Subversion, fourni avec TeamCity.

VI-A. Création d'un projet .Net

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.

Image non disponible

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.

Image non disponible

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.

Image non disponible

Il est à noter que l'on peut choisir, non pas d'utiliser les fichiers .sln de la solution, mais un fichier de script NAnt, ce qui permet aux heureux utilisateurs de CruiseControl.Net de réutiliser lâchement leurs anciens scripts de build tels quels. Et un argument en plus pour la migration, un !

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.

Image non disponible

VI-B. Intégration avec visual studio

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

Image non disponible

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

Image non disponible

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.

Image non disponible

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

Image non disponible

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

Image non disponible

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.

VI-C. Historique des compilations

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 :

Image non disponible

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.

Image non disponible

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.

Image non disponible

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.

Image non disponible

VI-C-2. Onglet Statistiques

L'onglet statistiques permet de visualiser plusieurs types de statistiques, en fonction de la compilation effectuée, et des données disponibles.

On peut obtenir toutes les statistiques suivantes :

Nom du rapport

Description

ArtifactsSize

Taille de tous les artefacts générés

BuildCheckoutTime

Durée de l'étape de récupération du code source

BuildDuration

Durée de la compilation, sans la récupération du code source

CodeCoverage

Couverture du code en %

CodeCoverageB

Couverture du code en %, au niveau des blocs de code

CodeCoverageC

Couverture du code en %, au niveau des classes

CodeCoverageL

Couverture du code en %, au niveau des lignes de code

CodeCoverageM

Couverture du code en %, au niveau des méthodes

DuplicatorStats

Nombre de duplicats dans le code

FailedTestCount

Nombre de tests échoués

IgnoredTestCount

Nombre de tests ignorés

InspectionStatsE

Nombre d'erreurs d'inspection du code

InspectionStatsW

Nombre d'avertissements d'inspection du code

PassedTestCount

Nombre de tests réussis

TestCount

Nombre total de tests

TestDuration

Durée totale des tests

TimeSpentInQueue

Durée pendant laquelle le build est resté dans la file d'attente

Les graphes doivent être configurés au niveau du fichier de configuration du projet, ou au niveau du fichier de configuration du build, en fonction du résultat demandé. La procédure de modification de ces fichiers est très bien expliquée sur le site de TeamCity.

VI-D. Création de profils d'utilisateurs

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.

Rôle

Droits

System Administrator

Les administrateurs ont les droits d'administrateurs projets sur tous les projets, et peuvent, de plus, créer et gérer les comptes utilisateurs, les configurations de compilations, et, en général, effectuer toutes les manipulations sur le serveur.

Project Administrator

L'administrateur de projet peut configurer les paramètres généraux du projet, les configurations de compilation, et peut assigner des rôles aux utilisateurs du projet. Il a, de plus, les droits de développeur et de gestionnaire d'agents.

Project Developer

Les développeurs peuvent faire des commit, démarrer / arrêter des compilations, réorganiser la queue de compilation, ajouter des descriptions aux compilations, voir les détails de l'agent, et prendre la responsabilité pour une compilation échouée

Agent Manager

Il est responsable de la gestion des agents de compilation, des règles de compilation, et de l'activation ou de la désactivation des agents.

Project Viewer

Ce rôle est disponible pour les personnes qui ont juste le droit de voir les résultats de compilation.

VII. Nos avis

VII-A. Romain

J'aime

Je n'aime pas

L'interface graphique, et l'aspect visuel général.

Limitations du plugin Eclipse.

L'intégration de TeamCity dans les systèmes externes (Windows tray, plugins pour IDE).

Pas de plugin pour NetBeans.

Les commits prétestés.

Pas de grandes améliorations entre les versions 3.1 et 4.0.

TeamCity regorge de statistiques et d'options !

J'aurais aimé voir plus précisément l'avancée du travail d'un build en cours (en particulier sur la construction de projets multimodules Maven2).

La gratuité de la version Professionnelle, bien que réservée à de petites structures.

Le prix de la version Entreprise, compte tenu de ce qu'elle offre par rapport à la version Professionnelle.

Les différents Runners (construction de projet, recherche de duplicats, inspection).

 

L'installation et la configuration aisées.

 

VII-B. Philippe

J'aime

Je n'aime pas

La facilité de configuration des builds, et d'utilisation en général

Que ce soit un programme Java ;)…Je n'ai rien contre le Java, au contraire, mais cela peut être un frein pour une société qui ne travaille qu'en .net

La possibilité de tester les builds sur le serveur Avant de faire un check-in

L'impossibilité de faire des commits prétestés avec un autre SCM que SVN (et TFS pour Visual Studio). Pour moi, si cette fonctionnalité avait été étendue à plus de SCM, cela aurait été un point de décision pour beaucoup de clients…

Les rapports fournis de base avec TeamCity (évolution des bugs, duplicats, couverture de code)

Le coût de la version Entreprise, par rapport à la version Professionnelle, que je trouve un peu élevé pour le peu de fonctionnalités ajoutées

L'intégration avec Visual Studio

 

VIII. Conclusion

VIII-A. Romain

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 !

VIII-B. Philippe

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.

IX. Remerciements

Pour la rédaction de cet article, nous tenons à remercier particulièrement :

  • Ricky81 pour tout son travail relationnel avec JetBrains mais également pour ses excellents conseils (comme d'habitude !) ;
  • toute l'équipe de JetBrains pour avoir développé cet excellent outil ;

X. Références

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.