Vers la production agile : Construire une usine logicielle .NET efficace

Publié par Philippe Miossec, le 17/04/2012, dans Intégration, Test, Tutoriel

co-auteurs de l’article : Radwane Hassen & Philippe Miossec

Au cours de cet article, nous allons nous interresser à la notion d’usine logicielle et montrer un exemple d’installation et de configuration d’une telle usine logicielle (Jenkins) pour l’environement Microsoft.Net.

1. Pourquoi l’usine logicielle ?

L’élaboration d’une application en entreprise ne se limite pas seulement à l’activité de développement et trop souvent des développeurs ne s’intéressent qu’à celle-ci. Pourtant d’autres étapes sont nécessaires à l’obtention de la valeur c’est à dire la livraison en production.

Non, nous ne sommes pas que des pisseurs de code :

Code Monkey

Un développeur doit être concerné non seulement par le développement mais aussi par toutes les phases qui permettent de mettre le produit en production et cela en s’outillant et en communiquant avec les équipes opérationnelles afin de constituer un workflow de produit efficace.
De plus, compte tenu de la répétitivité de ces actions un processus industrialisé permet un réel gain en productivité et peut devenir un argument sérieux de compétitivité. Tout cela, en évitant les erreurs humaines dans les tâches d’intégrations et de déploiement.
Et la logique peut être poussée jusqu’à la mise en production, certains grands noms de l’Internet (Google, Amazon, Flikr…) ont ainsi mis en place des procédés allant jusqu’à l’automatisation de la mise en production (Continuous Delivery), mais ça c’est une autre histoire…

1.1) Qu’est ce qu’une usine logicielle

Industrialiser

 

Une usine logicielle est un ensemble d’outils et de pratiques permettant d’automatiser les différentes étapes du développement d’un logiciel. Permettant ainsi la mise en place d’un processus automatisé optimisé, le rendant ainsi reproductible autant que souhaité sans qu’un membre de l’équipe ne soit mobilisé (et sans erreur de manipulation).

1.2) Les différentes briques

Usine logicielle

 

L’usine logicielle ne s’adresse pas uniquement aux développeurs ; elle cible les différents acteurs du projet : intégrateurs, techniques ou même la direction (avec d’éventuels indicateurs…). A chacune des briques d’une usine logicielle correspond une responsabilité, le tout formant un ensemble cohérent par lequel l’équipe aura défini son workflow de travail :

– La gestion de code source : la première brique essentielle est celle de la gestion de code source ou encore versionning. Actuellement, il en existe deux familles : les Version Control System (avec SVN, TFS, Perforce,…) où les sources sont centralisées sur un serveur et les Distributed Version Control System (avec Git, Mercurial,…) où la gestion des sources est distribuée. De notre point de vue, la seconde famille est l’évolution naturel de ces outils apportant une plus grande souplesse ainsi que d’autres fonctionnalités très avantageuses pour le développeur. Le choix d’un DVCS nous a donc semblé totalement naturel. Pour la suite de cette présentation, notre choix s’est donc porté sur Git.

– L’intégration continue : est une pratique d’eXtreme Programming (XP) qui permet d’avoir une version valide du logicielle continuellement… et à défaut détecte les problèmes d’intégration le plus tôt possible. Cela est également valable pour la détection de régressions et d’incohérences fonctionnelles à condition d’avoir des tests appropriés. Notre choix s’est porté sur Jenkins/Hudson, un des plus populaires, qui de part sa communauté et ses nombreux plugins offre une des solutions les plus abouties et extensibles.

– Le test : une fois l’intégration continue mise en place nous pouvons lancer les tests automatiquement, soit à chaque build (Test unitaire), soit la nuit (test intégration, fonctionnel, interface… Souvent plus long à exécuter).

– Les indicateurs : outre les rapports de build, nous pouvons inclure des rapports liés à la qualité du code, la couverture du code source par les tests, les règles de développement… Ceci donne un puissant outil pour observer et améliorer la qualité du code continuellement, ainsi qu’un outil mettant en valeur la qualité interne du code, un travail qui n’est pas assez mis en valeur.

– Le packaging : avant la livraison, aucune valeur concrète n’a été délivrée, ce qui est trop souvent oublié. Un processus automatisé et maîtrisé permet de packager et livrer un logiciel et donc d’obtenir de la valeur dès que les étapes de validation ont été passées.

2. Installation & mise en place

Tel que vu précédemment, 2 briques sont indispensables pour la réalisation d’une usine logicielle (les autres étant modulables et venant compléter le tout). Ce sont le logiciel de gestion de version (qui contient les sources du projet) et l’outil d’intégration continue qui permet d’orchestrer les différentes taches de construction, tests,… Nous allons donc voir comment installer et configuer ces 2 briques. Pour cela, nous utiliserons donc respectivement Git (pour la gestion des sources) et Jenkins (pour l’intégration continue).

2.1) Installation et configuration du contrôleur de code source : Git

Le contrôleur de code source étant une brique essentielle, nous allons faire une présentation succinte mais le sujet étant très (trop?) vaste, nous n’évoquerons que le strict minimum et vous invitons à compléter ces informations par des recherches sur le web.

Sous windows, l’utilisation de Git nécessite l’utilisation du portage sous windows msysgit (http://code.google.com/p/msysgit/). Nous conseillons d’installer GitExtension (http://code.google.com/p/gitextensions/) qui permet d’installer en même temps une interface graphique à Git et une extension pour VisualStudio 2005 à 2010 (msysgit étant suffisant pour l’intégration continue).

Lancez l’installation (Suivant, suivant…) et répondez au 2 questions (format de fin de ligne des fichiers et intégration de git dans le système) suivant vos besoins. Les choix par défaut conviennent la plupart du temps.

Après, l’installation, Git necessite de configurer le nom et l’email de l’utilisateur. Cela peut être fait, soit en lançant GitExtension pour la première fois (ou après dans l’onglet “Global Settings” de la fenêtre de configuration obtenu dans le menu “Settings=>Settings…”), soit en ligne de commande:

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

Le but n’est pas de détailler l’utilisation de Git (il y a suffisamment de documentation sur le sujet) et l’utilisation de l’interface graphique de GitExtension est en outre assez explicite. Voici toutefois quelques commandes de base necessaire à creer notre dépot et ajouter du contenu pour pouvoir configurer et tester notre usine logicielle.


//creation d’un dépot dans le répertoire courant
git init
//ajout de tous les fichiers du répertoire courant
git add .
//commit
git commit -m 'mon message'

Quelques astuces :
– télécharger le fichier .gitignore pour éviter d’archiver les fichiers inutiles générés par VisualStudio : https://raw.github.com/github/gitignore/master/Global/VisualStudio.gitignore
– Généralement, le fichier .gitignore consiste en le premier commit du projet mais il est possible (et peut être judicieux si tous les projets sont dans le même langage) de le définir plutôt dans ses préférences utilisateur pour ne pas être obligé de le rependre dans tous ses dépots.
– Utilisation de l’outil de merge p4merge qui permet une comparaison de fichiers et surtout un merge de modifications de façon plus aisée (3 way merge).Téléchargement et installation.

 

2.2) Installation et configuration de Jenkins

2.2.1 Installation de Jenkins
L’installation de jenkins reste assez simple. Pour cela, téléchargez la dernière version au format war à l’adresse suivante http://jenkins-ci.org/ et copier le fichier dans le répertoire où vous voulez installer Jenkins.
Pour lancer jenkins, vous devez avoir une version de la JVM (Java Virtual Machine) installée (nous ne détaillerons pas le procédure d’installation ici).
Lancez jenkins depuis la ligne de commande (depuis le répertoire de jenkins) :
java.exe -jar jenkins.war
Attendre le lancement et dans le navigateur chargez la page http://localhost:8080/

Ecran principal de Jenkins avec 2 projets configurés

- Ecran principal de Jenkins avec 2 projets configurés -

Il est fortement conseillé d’installer jenkins en tant que service windows sinon la procédure de lancement en ligne de commande décrite ci-dessus devra être reproduite systématiquement.
Pour cela, dans l’écran principal, cliquez sur “Administrer Jenkins” puis sur “Installer en tant que service Windows”.

2.2.2 Configuration de la construction des sources du projet

Note préalable : La suite de cet article indique la marche à suivre pour configurer entièrement votre usine logicielle jenkins et vaut la lecture ;). Cependant, si vous souhaitez installez rapidement jenkins, peut-être devriez vous directement lire le paragraphe §2.2.4.

2.2.2.1 Installation des plugins

Nous allons maintenant installer les plugins nécessaires pour gérer notre projet .Net. Pour cela, toujours dans “Administrer Jenkins”, cliquez sur “Gestion des plugins”.

Dans l’onglet “Disponibles”, nous choisirons :

  • Git
  • MSBuild
  • MStest
  • HTML Publisher plugin (pour pouvoir afficher le résultat de la couverture de code)

Puis cliquer sur “Installer sans redémarrer”

2.2.2.1 Configuration des outils .Net
Toujours dans “Administrer Jenkins”, cliquez sur “Configurer le système”.
Verifiez que l’executable de Git est bien détecté. Si ce n’est pas le cas, rajoutez Git dans le PATH de votre système (solution conseillée) ou renseignez dans le champ proposé, le chemin complet de l’exécutable.
Dans le paragraphe “MSBuild”, ajoutez une configuration de MSBuild en lui donnant un nom et le chemin vers l’exécutable
(ex : “MSBuild .Net 4” et “C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe”
cf https://wiki.jenkins-ci.org/display/JENKINS/MSBuild+Plugin )
Cliquez sur “Enregistrer” pour valider la configuration.

2.2.2.2 Creation du job d’intégration
Nous allons maintenant configurer le job d’intégration continue de notre projet. Pour cela, cliquez sur “Nouveau Job”.
Nommez votre projet puis sélectionnez l’option “Construire un projet free-style”.

Astuce : Par la suite, si vous voulez un job similaire à un job existant, vous pourez choisir l’option “Copier un Job existant” en saisissant son nom et ainsi récupérer le configuration du projet similaire pour l’adapter à votre besoin.

2.2.2.3 Configuration du dépot Git
Dans le paragraphe “Gestion de code source”, sélectionnez “Git” et renseignez le champ “Repository URL” avec le chemin vers votre dépôt Git et le champ “Branches to build” avec “master” pour ne compiler que la branche principale (la valeur par défaut permet de scruter TOUTES les branches).

2.2.2.4 Déclenchement du build
Dans le paragraphe “Ce qui déclenche le build”, sélectionnez “Scruter l’outil de gestion de version” et renseignez le planning à “* * * * *” pour scruter le dépôt Git chaque minute.

2.2.2.5 Compilation des sources
Dans le paragraphe “Build”, cliquez sur le bouton “Ajouter une étape au Build” et selectionnez “Build a VisualStudio projet or solution using MSBuild”
Dans “MsBuild Version”, vous devez retrouver la ligne correspondant à la configuration que vous avez effectuée à l’étape “§2.2.2.1 Configuration des outils .Net”. Sélectionnez là.
Dans “MsBuild Build File”, indiquez le chemin (en relatif) du fichier .sln de votre projet.
Dans “Command Line Arguments”, indiquez les paramètres de msbuild. Souvent, le seul paramètre nécessaire permet d’indiquer la configuration à compiler par le paramètre “/p:Configuration=DEBUG”.
Il peut cependant être nécessaire de reconstruire entièrement le projet (dans notre cas pour obtenir tous les warnings lors de la compilation pour utiliser par la suite le plugin “warnings” mais qui à pour contrepartie d’augmenter le temps de build), ce qui peut se faire en ajoutant le paramètre “/t:Clean;Build”.

A ce stade, vous pouvez lancer un build et vérifier que votre projet est bien rapatrié du dépôt Git et compile. Pour cela, n’oubliez pas de sauver la configuration puis cliquez sur “Lancer un build”.
Si le build ne marche pas ou que le résultat attendu n’est pas le bon, vous pouvez maintenant et tout au long de la configuration des différentes étapes voir les logs de déroulement de chaque build en affichant la page “Sortie Console” du build souhaité.

Ecran de résultat d'un build avec l'ensemble des métriques disponibles

- Ecran de résultat d'un build avec l'ensemble des métriques disponibles -

2.2.2.6 Configuration d’une tache de tests unitaires
Nous allons maintenant configurer l’intégration continue pour executer les tests unitaires MSTest.

Pour cela, nous allons “Ajouter une étape au build”, cette étape étant de type “Exécuter une ligne de commande batch windows”.

Dans la zone de texte, insérer la ligne de commande pour l’execution des tests mstest. Ne pas oublier de :
– précéder la ligne de commande par la suppression du fichier de résultat auquel cas la ligne de commande échoue si le fichier existe déjà,
– terminer le script par un “exit 0” car sinon un échec d’un des test entraînerait l’échec du build.

Un exemple de script pour exécuter des tests mstest ressemblerait à celui-ci (les parties en gras sont celles à adapter à votre besoin) :



REM MSTest necessite l’absence du fichier résultat
del MSTestResults.trx

MSTest.exe /nologo /usestderr /testSettings:"%WORKSPACE%\Solution\ContinuousIntegration.testsettings" /resultsfile:MSTestResults.trx /testcontainer:"%WORKSPACE%\Solution\MSTest.MonProjet.Assembly1\bin\Debug\MSTest.MonProjet.Assembly1.dll" /testcontainer:"%WORKSPACE%\Solution\MSTest.MonProjet.Assembly2\bin\Debug\MSTest.MonProjet.Assembly2.dll"
REM On ne veut pas que le build soit en echec si les tests ne sont pas tous un succès
exit 0

Dans la partie “Actions à la suite du build”, recherchez et activer l’option “Publish MSTest test result report” et indiquez le nom du fichier trx de résultat des tests (dans notre cas “MSTestResults.trx”).

Vous pouvez également sauvegarder le fichier de résultat de test pour le laisser à la disposition des développeur. Il peut alors être ouvert avec VisualStudio pour avoir les résultats des tests unitaires. Pour cela, cochez la case “Archiver des artefacts” et indiquez le nom du fichier de résultat des test (dans notre cas “MSTestResults.trx”).

A ce stade, vous pouvez lancer un build et vérifier que les tests sont bien executés. N’oubliez pas de sauver la configuration puis cliquez sur “Lancer un build”.

L’execution de 2 builds avec des résultats fait ainsi apparaitre un graphe représentant l’évolution du nombre de tests en échec sur le projet.

legende : Résultats des tests untaires des différents builds

- Résultats des tests untaires des différents builds -

2.2.2.7 Mesure de la couverture de code
Nous allons maintenant configurer la couverture de code qui permet de visualiser les parties du code de l’application couvertes ou non par les tests unitaires.
Pour cela, nous allons utiliser l’outil opencover ( https://github.com/sawilde/opencover/downloads ) et l’outil de génération de rapport ( http://reportgenerator.codeplex.com/ ). Les télécharger, les installer et mettre les exécutables dans le PATH.
Pour générer la couverture de code, nous allons modifier le script écrit précédement de façon à appeler les tests unitaires depuis l’outil de couverture de code.
Une ligne de commande utilisant opencover doit être de la forme :

OpenCover.Console.exe -register:user -target:"Chemin absolu vers l’executable de test" -targetargs:"arguments de l’executable passés précédement" -filter:+[MonProjet.*]* -output:"coverage_report.xml"

Notes : 1. Faire attention à bien passer le chemin absolu vers l’executable de tests (soit dans notre cas “C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe”)
2. Faire également attention à bien échapper par un ‘\’ tous les guillemets ’ “ ‘ dans les arguments de l’executable.

Il reste à inclure dans le script l’appel au générateur de rapport html avec les résultats du test :
reportgenerator.exe fichierResultatCouverture.xml repertoireDeGeneration

Dans notre cas le script une fois modifié est donc le suivant :

del MSTestResults.trx
OpenCover.Console.exe -register:user -target:"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" -targetargs:"/nologo /usestderr /testSettings:\"%WORKSPACE%\Solution\ContinuousIntegration.testsettings\" /resultsfile:MSTestResults.trx /testcontainer:\"%WORKSPACE%\Solution\MSTest.MonProjet.Assembly1\bin\Debug\MSTest.MonProjet.Assembly1.dll\" /testcontainer:\"%WORKSPACE%\Solution\MSTest.MonProjet.Assembly2\bin\Debug\MSTest.MonProjet.Assembly2.dll\" " -filter:+[MonProjet.*]* -output:"coverage_report.xml"
reportgenerator coverage_report.xml coverage_report
exit 0

Il reste à indiquer au plugin “HTML Publisher” les informations de couverture à publier. En se referant aux données ci-dessus, on indiquera les données suivantes :
HTML directory to archive = coverage_report
Index page[s] = index.htm
Report title = Couverture de code

Sauvez et executez un build pour obtenir des résultats.

Un nouveau lien “Couverture de code” apparaît sur la page du projet nous permettant de consulter le rapport généré.

legende : Résultats de la couverture de code

- Résultats de la couverture de code -

Nous avons maintenant mis en place assez rapidement une usine logicielle minimale nous permettant de compiler les sources archivées sur un dépôt Git commun, exécuter les tests unitaires et obtenir une couverture de code.

Arrivée ici, nous avons rempli une bonne partie de nos objectifs et avons une usine logicielle fonctionnelle. Il convient toutefois de permettre à l’équipe d’être au courant de l’état du build (cela est très important de fournir de façon active les résultats à l’équipe de développement). Pour cela, Jenkins fourni de nombreuses méthodes nativement ou à travers l’installation de plugins (email, flux rss, lava lamp,…). Nous conseillons toutefois d’installer le plugin “Hudson Tray Application Plugin” qui permet à toute personne d’installer depuis le portail Jenkins un programme affichant le résultat des builds dans la barre de notification du système.

2.2.2.8 Archivage de fichiers de build
Jenkins permet, à la suite d’un build, de conserver certains fichiers de votre choix. Pour cela, dans la configuration du projet, cocher la case “Archiver des artefacts” et indiquez le chemin des fichiers à archiver (par exemple : “.\bin\Debug\*”).

2.2.3 Mises en place de métriques de notre code

Il est maintenant intéressant d’obtenir des métriques un peu plus poussées sur le code écrit au court du projet pour donner un retour aux développeurs sur la qualité du code écrit. Pour cela, nous pouvons utiliser plusieurs plugin, décrit ci-dessous, au choix…

Nous allons ici adresser les thèmes suivants :
– Complexité du code écrit (plugin “CCM”)
– Duplication de code (plugin “Dry” / outil Simian)
– Suivi des taches ouvertes (plugin “Open Task Scanner”)
– Analyse statistiques de code et des assemblys (Plugin “Violation” / outil FxCop, Simian, Gendarme, StyleCop)
– Suivi des Warnings de compilation (Plugin “Warnings”)

2.2.3.1 La Complexité ciclomatique : CCM
C’est un indicateur permettant de connaître la complexité du code écrit. Pour une méthode donnée, la complexité exprime le nombre de chemins différents pour parcourir l’ensemble du code. Plus le nombre est élevé, plus la méthode est difficilement testable et maintenable. Il est alors utile de la refactoriser.
Pour cela, on peut utiliser CCM, un outil qu’on trouvera ici : http://www.blunck.se/ccm.html
A installer, ainsi que le plugin “CCM plugin” proposé dans Jenkins.
Aller dans “Administrer Jenkins” puis “Configurer le système” puis dans le paragraphe “CCM”, indiquez le chemin de l’executable (par ex : C:\Program Files (x86)\ccm\bin\CCM.exe)

“Ajoutez une étape au Build” du type “Invoke CCM” et spécifiez dans “Project Source Folders” la liste des projet C# à analyser (en allant à la ligne après chaque chemin indiqué). Par exemple :
.\Solution\MonProjet.Assembly1
.\Solution\MonProjet.Assembly2

Sauvez, buildez et contemplez les résultats :)

Suivi de la complexité du code pour les différents builds

- Suivi de la complexité du code pour les différents builds -

2.2.3.2 Métriques de qualité du code source : Violations

Tout d’abord, nous allons installer les outils suivants :
Installation de gendarme ( http://mono-project.com/Gendarme )
Installation de Simian ( http://www.harukizaemon.com/simian/index.html )
Installation FxCop depuis “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\FXCop\FxCopSetup.exe” (FxCop est fourni dans le sdk 7.0 ou 7.1)
Installation de StyleCop ( http://stylecop.codeplex.com/ )

Ne pas oublier de mettre les outils dans le path du système…
Pour utiliser ce plugin, il faut ajouter une étape supplémentaire dans le projet de build pour pouvoir générer les métriques souhaitées (au format xml, seul pris en compte par le plugin).
Pour cela, cliquez sur le bouton “Ajouter une étape au build”, puis choisissez “Executer une ligne de commande batch Windows”.
Nous allons ajouter une ligne de commande pour chaque outil utilisé.

Gendarme :
Gendarme est un outil d’analyse d’assembly. Pour cela, nous devons spécifier le chemin des assemblys que nous souhaitons analyser. Nous lui indiquons également de générer un fichier xml et lui indiquons le nom du fichier résultat.

gendarme --xml gendarme_report.xml .\Chemin\Vers\Mon\Assembly\Mon.Assembly.exe .\Chemin\Vers\Mon\Assembly\Mon.Assembly2.dll

Note: Gendarme nécessite la présence des fichiers pdb dans le répertoire du fichier assembly analysé.

Simian :
Simian est un outil d’analyse de code source à la recherche de code dupliqué. Pour cela, nous devons spécifier le pattern des fichiers à analyser (et également si besoin celui des fichiers à exclure). Nous lui indiquons également de générer un fichier xml et lui indiquons le nom du fichier résultat.

simian **/*.cs -formatter=xml:simian-output.xml -excludes=**/*.xaml.cs

Note: Le pattern **/*.cs indique qu’il faut analyser tous les fichier .cs se trouvant dans tous les sous-répertoires

FxCop :
FxCop est un outil d’analyse des fichier assembly.
Comme gendarme, il faut lui indiquer les fichiers assembly à analyser (paramètre “/file:”).
FxCop fonctionne grâce à des fichiers de règles que l’on peut utiliser au choix (paramètres “/rule:”) et dont la liste est disponible dans le sous-répertoire “rules” du dossier d’installation de FxCop. Dans l’exemple ci-dessous, toutes les règles sont utilisées.
Il convient également de lui indiquer le fichier de sortie (paramètre “/out:”)


fxcopcmd /file:"%WORKSPACE%\Chemin\Vers\Mon\Assembly\MonProjet.*.*" /directory:"%WORKSPACE%\Chemin\Vers\Mon\Assembly" /directory:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0" /rule:UsageRules.dll /rule:DesignRules.dll /rule:GlobalizationRules.dll /rule:InteroperabilityRules.dll /rule:MobilityRules.dll /rule:NamingRules.dll /rule:PerformanceRules.dll /rule:PortabilityRules.dll /rule:SecurityRules.dll /out:fxcop-result.xml

Note: Pour des raisons inconnues, il faut également indiquer à FxCop le répertoire (paramètre “/directory:”) du fichier “System.Core.dll” soit, dans notre cas, et en fonction su système et du framework “C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0”. Il est également conseillé de lui indiquer le répertoire des assemblys à tester

StyleCop:
StyleCop est fourni à travers un ensemble de dlls et s’intègre au sein de VisualStudio. Pour pouvoir l’utiliser en ligne de commande, on utilisera l’outil “StyleCop CLI” (http://stylecopcli.sourceforge.net/).
StyleCop fonctionne à partir d’un fichier de règles qu’il est préférable d’adapter à son besoin. Il est disponible dans le répertoire d’installation de StyleCop : “Settings.StyleCop”.
La configuration se fait avec l’outil “StyleCopSettingsEditor.exe” en passant le fichier de configuration en paramètre de l’application. Une fois configuré selon vos besoins, placez le fichier dans le répertoire de travail de Jenkins ( qui correspond à JENKINS_HOME\jobs\MonJob\Workspace avec JENKINS_HOME au répertoire de jenkins –cf valeur dans “Administrer Jenkins” -> “Informations sur le système” ->”JENKINS_HOME”– et MonJob au nom du job de build créé dans Jenkins). Si le fichier n’est pas positionné dans ce répertoire, lui indiquer le chemin complet.

On peut maintenant ajouter la ligne de commande suivante au script où on indique le chemin vers le fichier de la Solution, le nom du fichier de résultat à générer et le fichier de paramètre à utiliser :

StyleCopCLI -sln %WORKSPACE%\Solution\MaSolution.sln -out StyleCopResults.xml -set Settings.StyleCop

Enfin, le batch doit se terminer par “exit 0” pour que le build n’échoue pas si un des outils renvoie un code non satisfaisant.

Notre batch ressemble donc à cela :

REM Analyse statistique
gendarme --xml gendarme_report.xml .\Chemin\Vers\Mon\Assembly\Mon.Assembly.exe .\Chemin\Vers\Mon\Assembly\Mon.Assembly2.dll

simian **/*.cs -formatter=xml:simian-output.xml -excludes=**/*.xaml.cs

fxcopcmd /file:"%WORKSPACE%\Chemin\Vers\Mon\Assembly\MonProjet.*.*" /directory:"%WORKSPACE%\Chemin\Vers\Mon\Assembly" /directory:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0" /rule:UsageRules.dll /rule:DesignRules.dll /rule:GlobalizationRules.dll /rule:InteroperabilityRules.dll /rule:MobilityRules.dll /rule:NamingRules.dll /rule:PerformanceRules.dll /rule:PortabilityRules.dll /rule:SecurityRules.dll /out:fxcop-result.xml

StyleCopCLI -sln %WORKSPACE%\Solution\MaSolution.sln -out StyleCopResults.xml -set Settings.StyleCop
exit 0
REM Fin Analyse statistique

Il reste à configurer le plugin de façon à prendre en compte les fichiers générés lors de cette étape du build. Pour cela, il faut cocher l’option “Report Violations” et renseigner pour chaque ligne correspondante à l’outil utilisé (Gendarme, Simian, FxCop, StyleCop), le nom du fichier de résultat généré ainsi que ajuster (ou pas) selon vos besoins les 3 chiffres correspondants aux valeurs limites indiquant un build bon/de qualité médiocre/instable!

Le plugin est configuré et un graphe regroupant les diverses métriques devrait être disponible dans le tableau de bord du projet lors du prochain build. Un lien “Violations” est également disponible dans la colonne de gauche.

legende : Graphe de suivi des métriques d'analyse de code

- Graphe de suivi des métriques d'analyse de code -

2.2.3.3 Détection de tàches à faire : Task Scanner Plugin
Ce plugin permet de détecter des chaines de caractères types (FIXME, TODO,…) dans les commentaires et de suivre leur évolution.
Après l’avoir installé, allez dans la configuration du projet et activez la case à cocher “Recherche des tâches ouvertes dans le workspace”.
Puis configurez les options suivantes :
“Files to scan” = **/*.cs
“Tasks tags” = configuer les 3 champs de priorités avec les chaines de caractère que vous souhaitez.

Le plugin est configuré et un graphe “Open Tasks Trend” devrait être disponible dans le tableau de bord du projet lors du prochain build. Un lien “Tâches ouvertes” est également disponible dans la colonne de gauche.

Suivi des tâches laissées ouverte dans le code source

- Suivi des tâches laissées ouverte dans le code source -

2.2.3.4 Détection des similarités de code : Simian / Dry Plugin
Ce plugin permet une autre visualisation intéressante de l’analyse de la duplication de lignes de codes (donné par l’outil simian).
Le plugin utilise le même fichier de résultat obtenu par la commande définie plus tôt lors de l’utilisation du plugin “Violation”.
Dans la configuration du projet et activez la case à cocher “Publish duplicate code analysis results”.
Puis configurez l’option “Duplicate code results” par le nom du fichier xml de résultat (pour nous : simian-output.xml )
Le plugin est maintenant configuré et, comme le plugin “Task Scanner Plugin”, un graphe “Duplicate Code Trend” devrait être disponible dans le tableau de bord du projet lors du prochain build. Un lien “Duplicate Code” est également disponible dans la colonne de gauche pour parcourir les résultats…

Affichage des similarités (code dupliqué) dans le dernier build

- Affichage des similarités (code dupliqué) dans le dernier build -

2.2.3.5 Suivi des Warnings de compilation : Warnings Plugin
Ce plugin permet l’affichage, la comptabilisation et le suivi des warnings lors de la compilation du projet.
Dans la configuration du projet et activez la case à cocher “Scan for compiler warnings” et cliquez sur le bouton “ajouter” à côté du texte “Scan console log” et sélectionnez le parser “MSBuild”.
Le plugin est maintenant configuré et, comme le plugin “Task Scanner Plugin”, un graphe “Compiler Warnings Trend” devrait être disponible dans le tableau de bord du projet lors du prochain build. Un lien “Compiler Warnings” est également disponible dans la colonne de gauche pour parcourir les résultats..

Suivi des Warnings de compilation

- Suivi des Warnings de compilation -

2.2.3.6 Gamification
Il existe des plugins qui peuvent encourager votre équipe à venir consulter et résoudre les problèmes apparus lors des différents build et ceci en introduisant une certaine décontraction. Nous vous conseillons donc de tester le plugin “ChuckNorris” qui ajoutera une touche d’humour (informaticien) à chacun de vos builds ou le plugin “Continuous Integration Game” qui attribue et retire des points aux commiteurs en fonction de la qualité de leur commit et lors du cassage ou de la réparation des builds. Ambiance garantie!

2.2.3.7 ThinBackup
Ce plugin permet de faire des sauvegardes et restaurations des configurations des différents jobs créés.
Installez le plugin, redemarrez Jenkins et allez dans “Administrer Jenkins”, ”ThinBackup” et ”Settings”. Configurez le “Backup directory” avec le répertoire de votre choix.
Vous pouvez maintenant sauvegarde et restaurer vis configurations.

2.2.4 Installation facile et rapide : Bonus exceptionnel!!!!! ;)
Nous allons utiliser ThinBackup pour pouvoir installer facilement la configuration complète de job utilisant tous les plugins comme décrit tout au long de cet article. Nous allons vous fournir ci-dessous un squelette de configuration à adapter de façon à mettre en place jenkins TRES rapidement.
Pour cela, il faut installer préalablement TOUS les plugins utilisés dans la configuration (sinon la configuration sera perdue lors de l’import de la configuration), soit :

Configurer les plugins le necessitant (git, msbuild, ccm) dans “Administrer Jenkins”, ”Configurer le système”. Cette configuration a été décrite précédement.

Décompressez maintenant cette archive dans le répertoire utilisé par ThinBackup.
Allez dans “Administrer Jenkins”, ”ThinBackup”, ”Restore” et restaurez le backup correspondant.
Puis dans “Administrer Jenkins”, ”Recharger la configuration à partir du disque”.
Vous devez maintenant avoir un job fonctionnel pré-configuré avec toutes les étapes du build. Il ne reste plus qu’à adapter les chemins et noms à vos besoins :D
Vous pouvez également supprimer ce dont vous ne voulez pas…
Note: si vous avez oublié un plugin, vous pouvez le rajouter par la suite et relancer la restauration si besoin.

Nous avons maintenant créé un job avec Jenkins pour gérer l’intégration de notre projet de développement. Ce job étant relativement complet, il peut prendre un certain temps et toutes les métriques ne sont pas forcement nécessaires à chaque build. Il peut donc être utile de construire un build plus léger (avec seulement les tests unitaires et la couverture de code).
On peut donc toujours créer un ou plusieurs nouveaux jobs en copiant le job précédement créé et en supprimant les étapes non souhaitées.

3. Conclusion
Au cours de cet article, nous avons installé et configuré Jenkins pour mettre en oeuvre facilement une usine logicielle pour pouvoir construire et analyser un projet .Net. Nous avons également passé en revu les différents outils à notre disposition qui peuvent être intégrés lors du build pour obtenir des métriques permettant de donner un retour aux développeur et aussi faire une première configuration de ces outils. Nous avons vu que Jenkins est un solution satisfaisante et rapide à mettre en oeuvre pour construire vos projets .Net.
Il ne vous reste plus maintenant qu’à mettre en oeuvre ces outils sur vos projet pour le bonheur de vos équipes…

6 retours sur “Vers la production agile : Construire une usine logicielle .NET efficace”

  1. Guillaume says:

    Autant je trouve le tuto très sympa, autant je me méfie énormément de la notion d’usine logicielle.

    Il y a certes des étapes du cycle de vie d’une application qui sont automatisables et c’est très vertueux, mais la métaphore doit pour moi s’arrêter à de l’infrastucture et à du “DevOps”. Il me parait très dangereux que cette notion d’industrialisation déborde sur la collaboration avec le client et sur le cycle de développement lui-même : les développeurs ne sont pas des ouvriers et encore moins des machines. Les logiciels ne sont pas des voitures.
    En mettant en avant le concept d’usine logicielle, le risque est grand que nos patrons et nos clients nous confondent avec une unité de production industrielle et le cortège de préjugés qui vont avec : maîtrise parfaite des coûts et délais, taylorisation de la production, possibilité de délocaliser…

    Ce n’est pas un hasard à mon avis si le terme est très repris dans les offres commerciales des SSII et des sociétés de consulting. “On va vous monter une usine logicielle”… “Le process est maîtrisé et automatisé de bout en bout”…
    Attention à cette illusion de fiabilité et de reproductibilité. Les produits logiciels sont des objets malléables, négliger la part d’humain, de communication, de créativité nécessaire à leur confection serait à mon sens une grave erreur. Attention à la perte de sens du métier du développeur à qui on fait croire qu’il est guidé, assisté, et qu’il n’a plus qu’à débrancher son cerveau et remplir des cases avec du code.

    Personnellement, j’aurais remplacé “nous ne sommes pas *que* des pisseurs de code” par “nous ne sommes pas des pisseurs de code”. Tout court :)

  2. Radwane says:

    L’industrialisation n’intervient ici que sur les processus automatisables à savoir la construction, l’analyse du code et le report… Nous sommes ici à l’antipode de l’approche MDA. Cette notion de “Usine logicielle” n’intervient que pour décharger les développeurs et leur permettre de garder le focus sur quoi l’humain apporte une réelle valeur ajoutée. Nous sommes totalement dans l’approche Craftmanship avec un outillage qui permet à l’humain de s’exprimer là où il apporte le plus, c’est à dire le métier :)

    Par contre je ne vois pas comment, un processus efficace de mise en production puisse ne pas déborder sur la processus de développement et la collaboration avec le client. Ici nous ne vendons pas un outil, mais plutôt un état d’esprit avec de la confiance et de l’amélioration… La part contractuelle et comment vendre ça à un client, ne nous intéresse pas vraiment.

    Pour ta dernière remarque, c’était sous le forme d’un clin d’œil mais dans l’absolu, je suis totalement d’accord avec toi :)

  3. anthony says:

    Bonjour,
    quid de la gestion des librairies tiers? une petite piste?

  4. Philippe Miossec says:

    Un exemple de librairie tiers?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

By submitting this form, you accept the Mollom privacy policy.