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

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 ?

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 :

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.

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

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.

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.