JetBrains TeamCity 4


précédentsommairesuivant

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 multi-modules 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é. A 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 oeil 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

A 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 les 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 sujets 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.


précédentsommairesuivant

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.