Accueil > Mobile, Outillage > Jenkins : Analyse de code pour Objective-C avec Clang scan-build

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.

 

  1. Pas encore de commentaire
  1. Pas encore de trackbacks


trois × 7 =