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

Intégration Continue avec Visual Studio et Team Foundation Server - Partie I, Présentation de MsTest et de Static Code Analysis


précédentsommairesuivant

I. Contexte

Cela fait quatre ans que je mets en place de l'intégration continue sur mes différents projets, et ce exclusivement en utilisant les outils Microsoft.

J'ai donc voulu faire cet article pour m'adresse à la fois aux personnes connaissant déjà l'intégration continue, et aux novices.
C'est pourquoi nous commencerons par présenter ce qu'est l'intégration continue et les raisons poussant une équipe de développement à la mettre en place.
Mais l'objectif principal est de présenter les outils fournis par Microsoft aux développeurs pour mettre en place de l'intégration continue. Ces outils sont apparus sur le marché en 2005, principalement dans les versions « Team » de Visual Studio 2005, mais la plupart sont maintenant proposés dans les différentes versions de Visual Studio 2008.

C'est donc avec MsTest et Static Code Analysis que nous commencerons la présentation.

De nombreux liens vers la MSDN seront également donnés de façon à permettre au lecteur d'approfondir davantage les sujets traités. Notez que ces liens seront toujours donnés vers la MSDN online. Tous ces liens seront regroupés dans l'appendice (voir Bibliographie) et seront aussi donnés vers une installation locale de la MSDN (en supposant une utilisation de la MSDN fournie avec Visual Studio 2008 SP1).

II. L'intégration continue - En quelques mots

II-A. Pourquoi mettre en place de l'intégration continue ?

II-A-1. J'ai déjà un serveur de source. N'est-ce pas suffisant ?

Tout le monde (ou presque) est convaincu de l'utilité de la mise en place d'un serveur de source (Source Control) sur un projet. En effet, il permet à la fois de garder un historique des différentes modifications sur les fichiers sources, mais en plus de faciliter le partage des sources entre plusieurs développeurs d'une même équipe.

Si ces fonctionnalités de base (1) sont probablement suffisantes pour beaucoup de développeurs, elles ne devraient pas être satisfaisantes pour un client, un chef de projet, un ingénieur qualité… En effet, quelle garantie ont-ils que ces fichiers sources stockés dans le Source Control sont valides et cohérents ?

II-A-2. Je veux des sources cohérentes

Lorsqu'une équipe de quelques personnes travaille ensemble sur un même projet, les développeurs se retrouvent régulièrement à travailler ensemble sur les mêmes fichiers.

L'utilisation du Source Control « garantit » que les modifications de chaque développeur sont bien sauvegardées, à condition de procéder à des opérations de merge (c'est-à-dire des opérations de fusion) régulièrement entre les différentes versions des fichiers.

Cela ne veut malheureusement pas dire que les sources sont cohérentes : le travail en équipe peut régulièrement produire des sources ne compilant pas. Ce problème est le plus souvent causé par des conflits rencontrés lors de la fusion des sources - autrement dit deux développeurs ont travaillé sur les mêmes sources et il est difficile de savoir qui a raison -, mais pas uniquement.

Imaginons le cas de conflit suivant lorsque deux développeurs travaillent sur le même fichier :

Deux développeurs provoquent une erreur de compilation
Deux développeurs provoquent une erreur de compilation


Dans un tel processus, il est évident que Jean devra être très vigilant lors de son dernier « Commit ». En effet, il ne rencontrera aucune erreur ou difficulté lors de la fusion des sources, et pourtant, il risque de sauvegarder dans le système de gestion des sources un code ne compilant pas.

On peut même imaginer un cas beaucoup plus réaliste où :

  • un projet contient des dizaines de fichiers ;
  • chaque développeur peut travailler sur plusieurs fichiers en même temps ;
  • certaines opérations de fusion présentent beaucoup de modifications et de conflits, et sont donc difficiles à réaliser ;
  • certains fichiers ne peuvent pas être fusionnés comme des fichiers binaires ou des fichiers XML non formatés par exemple ;
  • un projet comporte du code généré par certains outils de compilation, et ne doivent donc pas être fusionnés.

Bref, on voit aisément les risques qui peuvent exister de produire des sources ne compilant pas.

Et bien évidemment, même si les sources compilent, ceci ne garantit en rien qu'elles soient correctes vis-à-vis des attentes du client. Et c'est cette cohérence qui nous intéresse par-dessus tout. Et c'est là que l'intégration continue entre en jeu.

II-B. Qu'est-ce que l'intégration continue ?

 

II-B-1. Définition

Comme son nom l'indique, « l'intégration continue » permet d'intégrer en permanence (de façon rapide et « continue ») les sources des différents développeurs afin de valider leur intégrité et leur conformité par rapport aux demandes clients.

Cette validation implique donc d'avoir un processus qui va à intervalle régulier :

  • récupérer les sources des tous les développeurs ;
  • compiler ces sources ;
  • valider éventuellement la conformité de ces sources via par exemple :

    • exécution d'une analyse de code,
    • exécution de tests de validation ;
  • déployer les sources pour que le produit puisse être soit téléchargé, soit testé par une équipe dédiée.

Ce processus d'intégration continue est appelé « build ».

II-B-2. Choix de l'intervalle

Ce build sera donc lancé à intervalle régulier, et ce, automatiquement. Cet intervalle sera choisi selon les besoins du projet. Typiquement, un build sera programmé toutes les nuits (2) , toutes les heures ou à chaque remontée de code dans le système de gestion des sources.

Typiquement le choix de cet intervalle est fait selon la criticité du projet ou selon la criticité d'un moment particulier de la vie d'un projet. L'intégration sera typiquement faite beaucoup plus souvent à l'approche d'une livraison que lors d'une journée de développement normal.

II-B-3. Politique de contrôle

Cette intégration continue peut s'accompagner d'une politique de contrôle des sources plus ou moins fortes afin de réduire les check-in douteux. On peut citer quelques exemples d'obligations :

  • commenter le check-in (explication des modifications réalisées et de la motivation de ces modifications : demande client, correction de bug…)
  • une ou plusieurs personnes doivent revoir le code, typiquement ;
  • revue de la qualité du code ;
  • revue des performances ;
  • revue de la sécurité ;
  • les tests doivent être lancés, et doivent tous passer ;
  • une analyse statique du code (3) doit être lancée et toutes les erreurs / avertissements doivent être corrigées.

Notez que Visual Studio propose par défaut les trois dernières règles décrites ci-dessus. Il propose de plus un modèle objet ouvert et simple afin que tout développeur puisse développer ses propres règles de validation. (4) La création de telles règles est plus complexe et ne sera pas détaillée ci-après.

II-C. Que sont les BVT ?

Nous disions lors de la présentation de l'intégration continue qu'il était important de pouvoir valider la conformité des sources. Dans le monde Microsoft, on parle de BVT, ou de Build Validation Tests.

Visual Studio nous propose plusieurs types de tests possibles, mais qui ne seront pas disponibles dans toutes les versions.

Pour rappel, Visual Studio est disponible dans les versions suivantes :

  • Version Express (gratuites - plusieurs versions disponibles selon les besoins) ;
  • Visual Studio Professional ;
  • Visual Studio Team Edition For Software Developpers ;
  • Visual Studio Team Edition For Software Architects ;
  • Visual Studio Team Edition For Software Testers ;
  • Visual Studio Team Edition For Database Professionals (5) ;
  • Visual Studio Team Suite (6).

Dans Visual Studio 2005 et 2008, quatre types de tests sont proposés. Le tableau ci-dessous présente la disponibilité de ces types de tests selon les versions de Visual Studio.

Différentes versions de Visual Studio - Différents outils de test

Type de test

Versions de Visual Studio

 
Commentaires


 
Pro.

Team Edition For Software

Team Suite

Dev.

Test.

Unit Tests

possible

possible

possible

possible

Tests unitaires, similaires à ceux produits par les outils xUnit (NUnit, JUnit…)

Web Tests

   

possible

possible

Successeur de Microsoft ACT : permet d'enregistrer des tests à partir d'une application web

Load Tests

   

possible

possible

Permet de créer des tests de montée en charge en simulant la présence de plusieurs clients

Ordered Tests

 

possible

possible

possible

Liste ordonnée de tests permettant de lancer les tests dans un ordre bien déterminé


Les autres versions de Visual Studio - non reprises dans ce tableau - ne nous offrent pas la possibilité d'écrire des tests. Notez cependant que les tests unitaires ne sont disponibles dans la version « Professional » que depuis Visual Studio 2008. La version 2005 les avait réservés aux versions « Team ».

Notez que Visual Studio 2010 (version « For Testers ») proposera aussi d'autres types de tests. On peut citer la possibilité d'enregistrer des tests sur une application Winform ou WPF, à l'instar des WebTest pour une application Web. On pourra alors demander de générer une classe C# contenant le code C# de ce test, qui pourra alors être exécuté et réexécuté comme tout autre test.

Seuls les « Unit Tests » seront décrits dans ce document.


précédentsommairesuivant
Le fonctionnement d'un Source Control est évidemment plus complet et plus complexe que les deux fonctionnalités suscitées.
Raison pour laquelle de nombreux projets des communautés proposent parmi leurs téléchargements non seulement les versions stables, mais également les « nightly builds » : versions intermédiaires, quotidiennes, qui ont été produites par le système d'intégration continue, et qui risquent d'être instables.
Nous parlerons plus en détail de l'analyse statique de code lors de la présentation des outils de l'environnement Microsoft
Afin de développer ses propres règles de validation, il est nécessaire d'utiliser le « Visual Studio SDK »
Notez que cette version sera supprimée dans les versions 2010 de Visual Studio. Ses fonctionnalités seront déplacées dans la version « For Software Testers » . Toute personne ayant d'ailleurs acheté une version « For Software Developpers », peut également installer la version « For Database Professional »
La « Team Suite » est la version intégrale, regroupant les différentes « Team Edition »

Copyright © 2009 Pierre-Emmanuel Dautreppe . Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC.