Jenkins : Analyse de code pour Objective-C avec Clang scan-build

Dans un soucis de réactivité et d’amélioration de la qualité des livrables, il est de bon ton de mettre en place des tests unitaires, souvent exécutés automatiquement sur une plateforme d’intégration continue telle que Jenkins.

Ces tests automatisés permettent de générer des rapports de tests ainsi que d’en mesurer la couverture de code. Cependant, certains problèmes peuvent être détectés en amont des tests, lors de la phase de build. Il s’agit de l’analyse statique de code. Cette analyse est d’autant plus utile pour les développement iOS où la mémoire est généralement gérée manuellement par le développeur. Cette analyse est aussi utilisable de la même manière sur un projet destiné à Mac OS.

 

Cette analyse préalable au build permet de détecter en amont toutes sortes d’erreurs dans le code pouvant être à l’origine de bugs ou pire, de crashes:

  • Variables inutiles
  • Fuites mémoire

 

 

Pré-requis

 

Pour disposer de cette fonctionnalité sur Jenkins, certains éléments doivent être préalablement installés:

  • Le plugin Jenkins : Clang Scan-Build Plugin, disponible dans l’interface de gestion des plugins de Jenkins
  • Clang Static Analyser : outil d’analyse disponible site le site web : http://clang-analyzer.llvm.org/

 

 

Configuration de Jenkins

 

Avant de commencer la configuration du Job Jenkins, il est nécessaire de configurer Jenkins pour qu’il sache où se situe Clang Static Analyzer.

Pour cela, rendez-vous dans le menu « Jenkins > Administrer Jenkins > Configurer le système ».

Cliquez sur le bouton « Clang Static Analyzer installations » et configurer Jenkins comme indiqué ci-dessous. Notez que dans cet exemple, Clang Static Analyzer est installé dans le répertoire « Applications » de l’utilisateur « jenkins ».

Jenkins SystemSettings ClangStaticAnalyzer

 

 

Configuration du Job Jenkins

 

Pour cet exemple, j’ai créé un projet iOS de base, pour lequel j’ai créé un job dans Jenkins afin de builder l’application dans sa configuration de debug. La target de build principale s’appelle « SampleApp ».

Contrairement aux autres étapes de build, la phase d’analyse statique du code est très bien intégrée dans Jenkins et nécessite très peu de configuration. Dans notre cas, il suffit de spécifier le nom de la target à utiliser. Pour des projets plus complexes, on peut cependant spécifier le Workspace ainsi que le Scheme. Des réglages avancés permettent aussi de spécifier le SDK cible ainsi que la configuration de build (« Debug » dans notre cas).

 

On effectue l’analyse statique au tout début du build Jenkins, c’est-à-dire avant même la compilation et l’exécution des tests automatisés :

Jenkins JobConfig RunClangScanBuild

 

Ensuite, ce qui nous intéresse, c’est de traiter et visualiser les résultats de cette analyse. Pour cela, il est nécessaire d’ajouter une action à la suite du build Jenkins comme ci-dessous :

Jenkins JobConfig PublishClangScanBuildResults

Cette étape permet de publier les rapports de l’analyse de code. Une option permet aussi de faire échouer le Job lorsque le nombre maximum de bugs tolérés est dépassé.

 

Pour les besoins des tests, j’ai volontairement inséré des erreurs dans le code de l’application lors de certains builds :

  • Une variable assignée mais jamais utilisée –> Dead Store
  • Un memory leak : objet alloué mais jamais libéré
On obtient les résultats présentés dans la partie suivante.
 
 
 

Résultats obtenus

 

Sur la page d’accueil du job Jenkins, on obtient un graphe qui représente l’évolution du nombre de bugs détectés en fonction des builds :

Jenkins JobResults ClangScanBuildTrend

On peut voir ici qu’on a eu 2 bugs introduits au build #34 et qu’ils ont été fixés lors du build #36. Si on clique sur la courbe au niveau du build #34, on peut accéder à la liste des problèmes détectés.

 

Cette partie fournit des informations importantes relatives aux problèmes : type du bug, description et emplacement du code fautif.

Jenkins JobResults ClangScanBuildDetailedResults

 

La dernière colonne permet d’accéder aux détails concernant chaque problème remonté par l’analyse statique. D’un simple clic, on se retrouve dans le code, à l’endroit ou l’anomalie a été détectée avec les explications correspondantes, un peu à la manière de l’analyse que l’on peut effectuer depuis xCode.

Jenkins JobResults ClangScanBuildResultsIssueDetails

 

L’avantage du fait de centraliser cette analyse sur un serveur d’intégration continue c’est qu’elle sera effectuée systématiquement, par exemple à chaque fois qu’une modification du code source est détectée. On obtient ainsi un retour rapide sur le nombre de bugs potentiels ajoutés au code, ce qui permet d’améliorer la réactivité de chaque développeur ainsi que la qualité du livrable en cours de réalisation.

De plus, les résultats seront conservés et exportés sous la forme d’un graphe pour un suivi visuel de la qualité/sûreté du code. De cette manière, on obtient un reporting assez détaillé et explicite avec un effort de configuration minime. On aurait tors de se priver d’un tel garde fou lors du développement d’applications en Objective-C. L’analyse de Clang est relativement pertinente et fournit des résultats facilement intelligibles par le développeur.



One More Thing…


Les versions précédentes de Clang scan-build rencontraient parfois des soucis d’interprétation avec le code iOS ARC (Auto Reference Counting). Certaines personnes obtenaient des résultats non valides (faux positifs) liés à la gestion de la mémoire. Il semble que ces erreurs liées à l’utilisation conjointe de Clang scan-build avec du code ARC aient été fixées depuis. En effet, les tests effectués par mes soins avec du code ARC n’ont pas posé de problème à l’analyseur.

 

Lyon JUG : soirée Gradle vs Maven 3

Lyon JUGNouvelle soirée au Lyon JUG, mardi 23 novembre : Gradle vs Maven 3.

Les JDuchess continuent leur teasing contributif avec des interviews des intervenants, permettant de venir profiter de la soirée plus armés sur les enjeux et perspectives de chacun de ces outils de construction : interview d’Arnaud Héritier sur Maven 3, et interview de Grégory Boissinot sur Gradle.

Inscription et informations pratiques, as usual, sur la page officielle.

Lyon JUG : soirée gestion de configuration décentralisée (GIT, Mercurial)

Après une pause estivale, le Lyon JUG est de retour!Lyon JUG Il reprend son rythme habituel, et son moyen quasiment mnémotechnique : chaque troisième mardi du mois, toujours à l’Epitech.

La soirée du 21 septembre sera consacrée aux nouveaux systèmes de gestion de configuration décentralisée : GIT et Mercurial.

LeLogo JDuchess Frances développeuses seront plus que jamais conviées : on y annoncera la création de l’antenne lyonnaise de JDuchess. Leur activité commence par une interview des intervenants à cette soirée.

Inscription et informations pratiques sur la page officielle.

La forge Open Source Codendi 4.0 est disponible

La forge logicielle de Xerox s’offre une version 4.0 née sous le signe de l’ouverture 🙂

Pour rappel, Codendi est une plate-forme collaborative de gestion de projet développée par Xerox, et permet de rassembler divers outils : gestion de code source, suivi de projet, gestion de documents, et d’autres outils de communication et de collaboration (forums, wikis, listes de diffusion, suivis de bugs).

Codendi 4
www.codendi.org

Cette nouvelle version majeure s’accompagne d’un changement de philosophie dans le mode de distribution : le code source est désormais disponible au public, et téléchargeable gratuitement sur le tout récent site communautaire de Codendi, sous forme d’une image ISO. Cet outil sous licence GPL était auparavant distribué uniquement aux entreprises sous forme d’un service payant, comprenant support technique et mises-à-jour.

Il y aura désormais deux versions : une version communautaire gratuite « Codendi Labs », et une version « Pro », plus stable, distribuée aux clients. Codendi renforce ainsi sa position sur le marché open-source, quelques mois après avoir gagné le Lutèce d’Or dans la catégorie « Meilleur projet libre réalisé par un Grand Groupe ».

Plus techniquement, cette nouvelle version offre notamment les fonctionnalités suivantes :

  • Une interface avec Hudson, la plate-forme d’intégration continue. Supervision des jobs, déclenchement des builds, résultats des tests, tout ceci est maintenant accessible depuis Codendi. Très utile pour être agile.codendi_hudson
  • Messagerie instantanée : déjà disponible en version 3.6 depuis les logiciels de messagerie instantanée compatible XMPP/Jabber, tel que Pidgin, il est maintenant possible de communiquer entre collaborateurs depuis l’interface web
  • Un tableau de bord évolué : affichage de flux RSS et Twitter, statistiques SVN/CVS, tout est personnalisable au niveau projet et utilisateur grâce une interface plus dynamique

Codendi est aussi partenaire du projet français COCLICO aux côtés de Bull, Orange Labs, Thales et l’INRIA, dont l’objectif est d’améliorer l’inter-opérabilité entre forges. Objet Direct contribuera également à ce projet en proposant notamment une application RIA pour le suivi de projet SCRUM.

Liens

Site communautaire de Codendi : http://www.codendi.org
Site professionnel de Codendi : http://www.codendi.com
Hudson, plate-forme d’intégration continue : http://hudson.dev.java.net

Séminaire à l’Université de Savoie : tests automatisés et intégration continue

Voici un rêve qui vient de se réaliser : animer un cours à l’Université de Savoie aux étudiants de deuxième année de Master Technologies de l’information et des communications. Pour la petite histoire, j’ai suivi ce cursus il y a déjà quelques années.

Le séminaire portait sur la mise en place de tests automatisés et de l’intégration continue dans un projet de développement logiciel. Ce sont 2 sujets qui prennent toute leur importance dans un développement itératif et incrémental mais qui ne sont pas toujours traités dans un cursus universitaire. C’est là l’intérêt de la démarche de l’Université de Savoie: demander à des intervenants spécialisés dans le génie logiciel de venir partager des retours d’expérience avec les étudiants.

Seul bémol : cette intervention est arrivée un peu tardivement dans le cursus et les étudiants vont avoir du mal à mettre en place les bonnes pratiques présentées dans leur projet de fin d’année. L’année prochaine, on essaiera de la planifier un peu plus tôt. Il est également envisagé de programmer une journée de type « Travaux dirigés », dans laquelle les étudiants pourront se confronter concrètement à cette mise en place sous l’œil vigilant d’un consultant.

Open Source SUN : nouveautés MySQL et intégration continue avec Hudson

Le 12 décembre dernier, Sun Microsystems mettait l’Open SOurce à l’honneur, à l’occasion d’un événement technique dont on pourra retrouver l’ensemble des présentations à cette adresse : http://www.slideshare.net/tag/aquariumparis

Je m’attarderai ici sur 2 des thèmes abordés : les évolutions MySQL 5.1 et 6.0 et le serveur d’intégration continue Hudson.

Un point sur MySQL par Serge Frezefond, responsable techique MySQL
Présentation en deux temps, après un rappel sur la popularité de MySQL auprès de nombreux sites Webs tels que FaceBook, a fait une présentation en deux temps :

  • Un retour sur les nouveautés de MySQL 5.1, disponible depuis le 27 novembre 2008. On retrouve donc la possibilité de faire un partitionnement d’une table sur plusieurs systèmes de fichiers. La programmation de taches, à un instant donné, périodiquement ou suite à un évènement. Au mode de réplication par instruction, viennent s’ajouter deux nouveaux modes : le mode de réplication basé sur les lignes et mixte pour lequel MySQL choisira le mode le plus adapté. La possibilité d’ajouter des logs de manière dynamique. La réplication de clusters permettant de dupliquer rapidement la base afin d’en augmenter les capacités.
  • Un aperçu des nouvelles fonctionnalités qui seront introduites dans la version 6. L’apparition d’un nouveau moteur transactionnel nommé Falcon, qui permettra des gains sensibles sur certaines requêtes. La possibilité de faire des backups en ligne

Ce que je retiens de la démonstration de l’outil d’intégration continue Hudson
Pour mémoire, l’intégration continue consiste à réaliser des builds de manière fréquente afin de déceler les problèmes d’intégration au plus tôt.
Une fois déployé sur un serveur d’application, Hudson permet d’automatiser la génération de builds et l’exécution de la batterie de tests qui s’ensuit. Pour cela, il faut indiquer les sources du projet (par un dépôt SVN par exemple), le gestionnaire de configuration Maven ou les scripts Ant peuvent être utilisés. On peut choisir sous quelles conditions les builds doivent être construits : par exemple, on peut demander à Hudson de lancer le build dès qu’un développeur réalise un commit et ne réaliser que quelques tests essentiels. L’ensemble complet des tests pourra néanmoins être réalisé quotidiennement, aux heures creuses par exemple. Ces tests complets pourront éventuellement reposer sur des matrices de configurations qui peuvent être employées pour tester l’application sur différentes combinaisons : bases de données, versions de Java, etc.. Par son interface, Hudson donne la possibilité de voir l’évolution au fur et à mesure des différents builds et surtout, en cas d’échec, d’avertir par flux RSS ou directement par mail le développeur soupçonné d’être la cause de l’erreur afin qu’il puisse intervenir au plus tôt.
Hudson, même si ce n’est pas une nouveauté, apparaît comme un outil simple d’emploi pour faire de l’intégration continue.