dimanche 17 janvier 2010

TeamCity - Intégration continue (IC)

La suite des articles sur l’industrialisation de développement.

Cet article est consacré au serveur d’intégration continue TeamCity. Ca fait déjà presque 2 ans que j’utilise ce serveur. Très stable, facile à mettre en place et facile à utiliser.

Quelques liens utiles:

  1. Télécharger TeamCity: ici
  2. Documentation et video tour des fonctionnalités : ici
  3. Blog de TeamCity : ici

Cet outil est développé par JetBrains, un éditeur de logiciel très connu dans le monde Java pour son IDE Intellij Idea et dans le monde .NET pour son plugin Resharper.

Ecran principal de TeamCity donne une image instantanée des états des différents builds qui sont présents sur le serveur :

Pour utiliser TeamCity (ou n’importe quel autre serveur d’intégration continue) vous aurez besoin de deux choses : le système de contrôle des versions (CVS, SVN, et à partir de la version 5.0 TeamCity supporte Git et Mercurial– les vcs distribués très à la mode en ce moment) et un outil des builds automatiques (Ant, Maven, MsBuild, etc).

Une particularité de l’architecture TeamCity est l’utilisation des agents – machines physiques qui se sont regroupés ensemble pour permettre l’exécution de plusieurs builds en même temps. Cette fonctionnalité est disponible uniquement dans la version payante.

TeamCity supporte 2 plateformes Java et .NET. Cet argument peut être très intéressants car TeamCity permet dans ce cas là de capitaliser les connaissances sur le processus d’intégration continue pour différents projets. Les meilleures pratiques et astuces du monde d’IC de Java peuvent être réutilisées pour .NET et vice versa.

La fonctionnalité très utile pour les chefs de projets et responsables techniques de projets. Les différentes statistiques sur la santé du processus d’intégration(combien des builds « cassés », les tests unitaires qui provoquent plus d’erreurs, nombre des test unitaires, le temps de « fixage » des bugs, etc ). Les stats montrent l’évolution du projet dans différents contextes : les moments critiques (où il y avait plus d’erreur), la réactivité de l’équipe pour corriger les erreurs, etc.

Aucun commentaire: