Tutoriel pour choisir une solution d'intégration continue pour le développement mobile

La programmation ne se limite pas à l'écriture du code source. Un ensemble de procédures et de méthodologies doit être mis en place pour assurer la qualité d'un développement. Citons par exemple la documentation qui permettra d'assurer maintenabilité et facilité d'utilisation (en expliquant un algorithme complexe, en détaillant l'API publique, en fournissant des exemples concrets…)

Une de ces procédures met l'emphase sur un suivi continu du développement à chaque mise à jour de la source (analyse du code à la recherche d'erreurs syntaxiques, vérification de la présence d'un environnement de test, exécution des tests unitaires ou fonctionnels, etc.) : l'intégration continue.

Elle n'est pas obligatoire pour mener à bien un développement, mais devient immensément utile lors de la multiplication des projets. Elle permet de soulager les développeurs en réalisant des tâches automatiquement, et fournit des indicateurs sur la qualité du développement et du code.

In fine, l'intégration continue pourrait même effectuer automatiquement des livraisons en production dans certaines situations prédéfinies.

Il existe de nombreuses solutions d'intégration continue (ou CI, pour Continuous Integration) : open source ou commerciales, sur le cloud ou self-hosted, dédiées à une technologie ou totalement techno-agnostiques…

À ITELIOS, nous avons étudié les possibilités offertes aux équipes de développement mobile, et nous avons choisi de partager ce retour d'expérience avec vous !

Avant de continuer, je tiens à préciser que nous ne serons évidemment pas exhaustifs, car il existe des dizaines de solutions possibles. Nous n'allons présenter que celles qui ont retenu notre attention. N'hésitez pas à partager votre propre expérience en commentaire.

Jenkins est la solution d'intégration continue open source la plus connue et la plus déployée au monde. Ses avantages principaux résident dans son prix (gratuit) et sa communauté (grâce à son côté open source).

Développé en Java, Jenkins a l'avantage d'être multiplateforme et peut être utilisé pour des développements spécifiques tels qu'iOS/OSX. Conçu dès le départ pour l'extensibilité, il peut être (quasi) totalement customisé via des plug-ins, dont le catalogue est actuellement très fourni par la communauté.

Il existe notamment un plug-in dédié à l'utilisation de Xcode ainsi qu'un plug-in Gradle pour Android.

Le fonctionnement de Jenkins est simple : un projet est constitué d'un moyen de récupérer le code source, d'une ou plusieurs tâches d'exécution et d'éventuelles tâches post-exécution.

Ces tâches peuvent être de différentes natures : compilation, exécution de script Ant, etc. Les plug-ins permettent d'ajouter des tâches spécifiques liées aux technologies qu'ils supportent. Si aucun plug-in ne vous convient et que le temps vous manque pour en développer un, vous pouvez aussi exécuter des scripts et des outils en ligne de commande.

La solution possède toutefois un point faible : son aspect. L'UI proposée par Jenkins n'est vraiment plus au goût du jour. Attention, elle n'est pas moche pour autant, mais elle est bien loin de ce que certaines autres solutions proposent.

À noter également, Jenkins est prévu pour être une solution purement self-hosted. Des solutions d'hébergement en ligne existent, mais elles ne font pas partie de l'offre de base.

Ce que nous aimons :

• l'aspect open source ;
• la communauté existante et les nombreux plug-ins ;
• l'extensibilité quasi infinie.

Ce que nous n'aimons pas :

• l'aspect vieillissant de l'interface ;
• certaines tâches mobiles trop compliquées à mettre en œuvre (les tests sur simulateur, par exemple) ;
• le côté self-hosted (un critère très subjectif, je vous l'accorde).

CircleCI est l'une des solutions les plus convoitées du moment. Totalement gérée depuis le cloud, elle adresse un très grand nombre de projets grâce à son support des technologies les plus utilisées.

Du web (NodeJS, Java, Ruby, PHP…) au mobile (iOS, Android), CircleCI s'est fait de très nombreux clients par cette capacité à accompagner les applications qui font le monde d'aujourd'hui.

Et si une technologie n'est pas supportée directement par CircleCI, ce n'est pas un problème grâce à l'intégration de Docker dans la solution.

Exception notable : CircleCI n'est pas compatible avec les projets .Net. Le support de Windows n'est pas présent et Docker ne permet d'exécuter des environnements de développement spécifiques que sur un Linux.

CircleCI fut l'un des pionniers dans les solutions cloud pour le mobile. Cet historique se ressent : la documentation est claire et la technologie est bien couverte.

CircleCI supporte l'exécution des tests sur mobile : XCTest, Kif ou même Kiwi pour iOS, exécution d'une tâche de test Gradle dans un simulateur pour Android.

La solution n'est pas exempte de défauts. Principal bémol : CircleCI n'est prévu pour fonctionner qu'avec GitHub. Si vous avez opté pour Bitbucket, car vous aimez l'intégration avec JIRA et Confluence (ou pour toute autre raison), passez votre chemin, car CircleCI n'est pas pour vous.

Ce que nous aimons :

• la solution 100 % Cloud ;
• le support du mobile nativement ;
• l'intégration de Docker pour le support d'autres technologies.

Ce que nous n'aimons pas :

• la relation trop étroite avec GitHub ;
• la fermeture du service empêchant l'extensibilité via des tâches spécifiques ;
• l'incapacité à exécuter du code .Net.

Bitrise est une solution récente dans le milieu de l'intégration continue, qui a fait le choix d'une approche Mobile First.

Initialement conçu pour ne fonctionner qu'avec iOS, Bitrise étend aujourd'hui son service à Android via une approche container avec Docker.

Cette approche permettra (enfin, permet déjà, mais sans support) d'étendre le service d'intégration continue aux plateformes web utilisables par une Dockerization : NodeJS, Ruby, PHP, Java, etc.

Malheureusement, cette approche ne permet pas une compatibilité avec les projets .Net. Toutefois, le service ayant proposé une architecture spécifique pour iOS dès le départ, il n'est pas exclu d'imaginer le développement futur d'une architecture particulière pour les projets .Net, si le besoin s'en fait sentir.

Un des points forts de Bitrise est son extensibilité. L'équipe a développé tout un écosystème permettant de créer ses propres tâches et de les intégrer dans le répertoire central de Bitrise. Ce système, nommé StepLib, est la base du fonctionnement de l'outil.

Quant au fonctionnement général, il est similaire à la quasi-totalité des services d'intégration continue présentés, à la différence que les builds sont démarrés via des Trigger. Ceux-ci sont basés sur la branche qui doit être buildée. Ils permettent de proposer des scénarios de compilation différents en fonction de la branche Git qui vient d'être mise à jour.

Par exemple, si c'est master qui est déclenché, en plus de faire les mêmes actions que pour le scénario de la branche develop, on va également incrémenter le numéro de version et envoyer le build sur iTunes Connect. Autre exemple, pour toute autre branche que master ou develop, on va juste se limiter à une analyse de code statique à la recherche d'erreurs.

L'interface proposée est simpliste. Elle permettra à quiconque maitrisant la génération d'applications de mettre en place des builds rapidement. Toutefois, elle propose aussi un mode avancé permettant aux utilisateurs chevronnés d'aller plus loin dans la configuration de leurs scénarios/projets.

Ce que nous aimons :

• une solution 100 % cloud ;
• la simplicité, non limitative, de l'interface ;
• l'extensibilité accessible à tous ;
• l'intégration de Docker pour le support d'autres technologies ;
• le fonctionnement à base de trigger, très pratique avec un processus type Git Flow.

Ce que nous n'aimons pas :

• l'impossibilité de développer des tâches privées, ou d'avoir un répertoire StepLib privé ;
• l'incapacité à exécuter du code .Net.

Atlassian Bamboo est une solution purement commerciale faisant partie de la suite d'outils développée et proposée par la société Atlassian.

Cette société développe de nombreux outils facilitant la vie de tous les développeurs : JIRA, Confluence, Bitbucket, SourceTree, et bien sûr Bamboo.

Contrairement aux autres solutions présentées, Bamboo est vraiment orienté vers le web et non le mobile. Pourquoi ? Parce que Bamboo a une approche légèrement différente passant par une séparation entre la partie « génération » et la partie « déploiement ».

Dans la majorité des solutions CI, le SCM (pour Source Control Manager) indique au serveur CI qu'un job doit être lancé via un webhook. Ce job est constitué d'un ensemble de tâches (customisables ou pas) et potentiellement de tâches post-exécution.

Bamboo explose littéralement cette approche en découpant l'intégration continue en deux sections bien distinctes.

Les tâches de déploiement contiennent la configuration des environnements de déploiement : le staging, la production, etc. Dans Bamboo, ce ne sont pas les tâches de génération qui sont déclenchées, mais celles de déploiement.

Les tâches de génération sont semblables aux jobs que l'on peut trouver dans n'importe quelle autre solution. Il s'agit d'un ensemble de tâches à exécuter séquentiellement et permettant de créer le build adéquat.

Cette approche est peu adaptée au développement mobile. Nous ne déployons pas sur des serveurs distants, mais construisons des applications que nous devons distribuer par la suite.

De plus, la gestion de l'environnement fait partie intégrante du processus de construction, très souvent via des commandes Gradle ou des schemes Xcode spécifiques. Cela va à l'encontre du principe proposé par Bamboo.

À noter que Bamboo a deux modes de fonctionnement : self-hosted ou dans le cloud. Les deux pouvant être utilisés conjointement afin de créer des environnements complets. La solution cloud est limitée à Linux.

Ce que nous aimons :

• le choix self-hosted ou dans le cloud ;
• l'extensibilité.

Ce que nous n'aimons pas :

• la complexité d'utilisation ;
• la configuration peu adaptée aux projets mobiles ;
• le besoin d'avoir des serveurs self-hosted pour gérer des builds iOS/OSX.

Greenhouse est la solution la plus simpliste que nous ayons rencontrée. Elle n'est prévue que pour iOS et Android et n'est pas extensible.

Néanmoins, Greenhouse remplit son job : compilation, tests (XCTest, Kif, Espresso, etc.), distribution.

Pour un développeur mobile qui ne souhaite pas de fonctionnalité spécifique et qui veut simplement s'assurer que son build compile et passe tous les tests à chaque commit, Greenhouse est une solution tout à fait envisageable.

Pour celui qui souhaiterait aller plus loin, en exécutant des scripts spécifiques, ou toute autre tâche, cette solution ne sera évidemment pas le bon choix.

Une entreprise qui ne ferait pas que du mobile et qui souhaiterait avoir une seule solution pour toutes les technologies exploitées ne pourra évidemment pas se tourner vers Greenhouse.

Le support des projets mobiles .Net n'est pas de mise. Cela est un critère discutable pour certains vu le peu d'applications mobiles développées sur Windows, mais cela rentre en compte dans nos critères.

Ce que nous aimons :

• la solution 100 % Cloud ;
• le support du mobile nativement ;

Ce que nous n'aimons pas :

• la trop grande simplicité ;
• la non-extensibilité du service ;
• l'incapacité d'exécuter du code .Net ;
• l'interface que nous jugeons trop « simpliste ».

Nous sommes d'abord partis sur une solution de type Jenkins. Malheureusement, l'approche self-hosted est vite devenue compliquée à gérer. Nous avions des machines virtuelles sous Linux pour le web, des machines virtuelles sous OSX pour le mobile, sans oublier l'intégration avec le LDAP interne et bien d'autres soucis (mise à jour des plug-ins, gestion du keychain sous OSX, etc.). Beaucoup trop de contraintes opérationnelles pour nous.

Nous avons donc décidé d'opter pour une solution cloud et avons d'abord envisagé la piste de Bamboo, car nous utilisons au quotidien la grande majorité des outils Atlassian. Malheureusement, bien que prometteur, le modèle de fonctionnement particulier de Bamboo nous a paru bien trop compliqué à mettre en œuvre, notamment pour avoir un mode unifié entre le pôle mobile et le pôle e-commerce/web.

Finalement, nous avons choisi Bitrise. Moins fourni que CircleCI, qui fut envisagé après Bamboo, mais compatible avec Bitbucket, ce qui fut déterminant dans notre choix.

Le support récent d'Android, l'ouverture à Docker et le support très actif de l'équipe technique ont su nous convaincre d'investir sur cette plateforme.

Elle est aujourd'hui en phase de bêta dans l'ensemble du pôle mobile d'ITELIOS, et nous envisageons l'utilisation de Docker, via Bitrise, pour l'ensemble de nos autres projets web, hors projets .Net bien entendu, malgré l'absence de support technique officiel sur ce type de projet.

Twitter : @vincentsaluzzo

Développeur iOS depuis qu'il est né, il s'est très récemment ouvert à d'autres technologies : NodeJS, Web, Demandware… mais son cœur restera toujours en forme de pomme !

Ce tutoriel a été publié avec l'aimable autorisation de la société Itelios.

Nous tenons à remercier f-leb pour la relecture orthographique, et Malick SECK pour la mise au gabarit.