Intégration continue : Docker, Jenkins, Azure, apk

L’objectif de cet article est de présenter la mise en place d’un serveur d’intégration continue dans le cloud azure avec le gestionnaire de conteneurs linux docker. Une première partie consiste en l’installation des logiciels nécessaires à l’utilisation de docker ( boot2docker, docker machine ) sur un poste fonctionnant sous Windows 7 Professionnel.

Une deuxième partie consiste en la création de la machine virtuelle sous azure et nous verrons comment déployer jenkins avec des plugin gradle, git et un sdk dans le cloud azure.
Dans une troisième partie, nous verrons comment paramétrer le serveur jenkins pour générer nos apks et le déployer sur notre compte de stockage azure.

Lire la suite

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.

 

Déploiement OTA d’une application iOS avec TestFlight

Lors de nos itérations de développement, notamment au sein de projets agiles, nous avons souvent besoin de distribuer des versions « beta » à un parc d’utilisateurs, aux clients, etc. Pour cela, nous allons réaliser des versions dites « Adhoc » que l’on va distribuer Over The Air à un parc d’utilisateurs/testeurs via TestFlight.

L’avantage de cet outil en ligne réside dans le fait qu’il s’intègre très bien avec la plateforme d’intégration continue Jenkins via le plugin idoine, permettant de facto l’automatisation des déploiements.

 

Présentation générale

TestFlight est un service Web SAAS gratuit. Il permet notamment de centraliser l’inscription des testeurs, de les répartir en équipes et de leur mettre à disposition des versions AdHoc d’une ou plusieurs applications.

Ce service est dédié aux applications iOS. Des alternatives telles que Appaloosa (payant et multi-plateformes) ou Zubhium (gratuit et dédié à Android, certaines prestations payantes) existent. Elles ne seront pas présentées ici mais proposent toutes une fonctionnalité commune : déployer automatiquement une application mobile sur un store privé. C’est extrêmement intéressant pour lancer une campagne de beta-testing ou simplifier le déploiement d’une version de démonstration sur le device d’un client.

Pour utiliser ce service, il faut d’abord s’inscrire sur le site https://testflightapp.com. Ensuite, on peut créer des équipes, des listes de déploiement et inviter des testeurs qui vont pouvoir « enregistrer » leurs devices de test sur le service. De cette manière, on peut facilement récupérer l’UDID de chaque iPhone, iPod ou iPad pour les rajouter à notre Provisionning Profile Adhoc sur le site d’Apple.

La récupération des UDIDs est donc simplifiée par le système d’invitations. Ce système évite les erreurs de saisie des identifiants, celle-ci étant généralement effectuée à la main. Les listes de déploiement (Distribution Lists) permettent de choisir quelle personne peut accéder à quelle application, pratique lorsqu’on travaille sur plusieurs projets.

A noter que TestFlight fournit aussi un SDK (non testé ici) qui permet d’ajouter des fonctions plus avancées telles que:

  • Enregistrer des sessions d’utilisation : utile pour analyser comment l’application est utilisée en conditions réelles
  • Gestion des crashlogs qui sont reportés automatiquement
  • Logging
  • Gestion du feedback au sein de l’application elle-même
  • Notification des nouvelles versions directement au sein de l’application

 

Exemple d’utilisation

Voici ce que l’on peut obtenir avec cette solution:

  • On peut uploader un build soit par drag’n’drop via un browser, soit via l’API depuis un serveur d’intégration (plugin Jenkins ou script shell).
  • Chaque membre reçoit un email notifiant la disponibilité d’un nouveau build (ici le n°15). Il contient un lien direct pour l’installation et permet d’envoyer un feedback en répondant simplement au message :
Jenkins Adhoc TestflightEmailNotif

 

  • On accède au store depuis un raccourci placé sur le dashboard du device :
TestFlight Dashboard

 

  • Sur notre device de test, on voit apparaitre le nouveau build dans le store hébergé par TestFlight

TestFlight Adhoc LatestBuild

 

  • Sur notre device de test, on peut aussi accéder aux anciens builds d’une application depuis la liste suivante :
TestFlight Adhoc PreviousBuilds

 

  • On peut ainsi facilement installer une version précédente, ce qui est notamment très utile lorsque l’on a besoin de reproduire un problème lié à une ancienne version :

TestFlight Adhoc OldBuild

 

 

N.B. Il est intéressant de créer un Tag sur le serveur de versioning utilisé à chaque fois que l’on publie un nouveau build afin d’assurer une tracabilité au niveau du code source.

 

Conclusion

 

Les points à retenir:
 
Avantages :

  • Bonne intégration grâce au plugin Jenkins qui permet des déploiements automatisés
  • Gestion d’un parc de beta users sous la forme d’équipes de testeurs (exemple : une liste par projet)
  • Récupération facilitée des UDIDs des différents devices de test, via un système d’invitations.
  • Déploiement OTA des applications
  • Notifications par mail à chaque nouvelle version
  • On peut facilement envoyer un feedback sur un build en répondant à cet email de notification. Le feedback est alors automatiquement intégré au portail TestFlight.
  • La dernière version de l’appli est directement accessible depuis une icône TestFlight sur le dashboard du device
  • On peut facilement accéder aux versions précédentes d’une application

 

Limitations :

  • Il faut au moins un device dédié par testeur, sinon le testeur ne voit pas les notifications des builds
  • Le service rencontre parfois quelques problèmes lorsque plusieurs personnes se partagent un device. En effet, un device ne peut être associé qu’à un seul compte TestFlight à un instant T et on rencontre parfois des soucis lors des changements de propriétaires. Ceci est certainement dû au fait que TestFlight est en cours de mise au point et ne couvre pas complètement ce genre de situations.
  • L’approche avec le SDK ajoute de nombreuses fonctions mais semble relativement intrusive à première vue. A essayer…

 

 

La Devoxx 2011 c’est fini ! (Part 2/2)

Voici la suite de nos aventures à la Devoxx 2011!

Hall des sponsors

Ça y est, les partenaires ont envahi tout le rez-de-chaussée qui abritait le petit déjeuner gargantuesque du premier jour. Il y aura donc moins à manger… mais à la clé moults goodies, concours et autres t-shirts aux couleurs des sponsors de l’évènement. Et je dois dire que nous sommes revenus chargés de cette journée ! (dont un superbe mug HTML5 du plus bel effet, photo!)

Quelques amusements... Mug HTML5 La librairie

Rangeons nos mugs, nos nouveaux vêtements trop voyant pour être vraiment portés… et entrons dans le vif du sujet :

Lire la suite