JetBrains TeamCity 4


précédentsommairesuivant

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 projet 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 fichier .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 / echec 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" permets 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 permets 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ée 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.

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.