Neoxia intègre, depuis plusieurs années, les pratiques de Continuous Integration et, plus récemment, de Continuous Delivery dans ses projets internes et externes. Pour cela, nos projets s’appuient depuis bien longtemps sur un serveur d’intégration continue (CI). Historiquement, c’est Jenkins qui était en charge de cette fonction mais une deuxième solution est disponible en interne depuis 2014 : Drone. L’heure est à la comparaison entre ces 2 outils qui, projet après projet, nous poussent à améliorer la qualité de notre code et l’automatisation de nos processus de développement et de livraison.

Présentation générale

A ma droite, Jenkins, champion reconnu de l’intégration et du déploiement continus depuis plusieurs années. Fonctionnant sur la base d’un coeur applicatif et d’un écosystème de plugins, Jenkins est largement customizable et adaptable à quasiment tous les environnements (OS, serveurs de gestion de source, langages, outils de build, rapports de tests, etc.). Stable depuis plusieurs années, Jenkins reste cependant en constante évolution, que ce soit son cœur ou les plugins.

A ma gauche, Drone, notre outsider, un produit initialement disponible en SaaS et rendu Open Source dans un second temps. Drone est un serveur d’intégration continue qui s’appuie sur Docker, permettant aux développeurs de contrôler l’environnement dans lequel s’exécutent les builds de leurs applications. Il s’appuie lui aussi sur un ecosystème de plugins pour s’adapter aux différents environnements, tous ces plugins étant packagés via Docker. Drone.io est la version SaaS, Drone la version open source.

Retour d’expérience

Neoxia utilise (entre autres) ces 2 outils afin de conserver une qualité de code élevée et garantir des applications stables et fonctionnelles à ses clients. Les indicateurs les plus utilisés dans nos projets sont le nombre de tests, la couverture de code couvert par les tests, la stabilité des builds et, pour les fonctionnalités critiques de nos applications, la couverture fonctionnelle de cas précis/problématiques par nos tests techniques. Cependant, Drone et Jenkins sont utilisés dans des circonstances différentes.

Drone est utilisé majoritairement dans nos projets web, pour lesquels nous avons une préférence pour PHP & Laravel et dont le code est hébergé sur des repositories privés de Github. Dans ce cadre, Drone offre un excellent service puisque le besoin de configuration et de maintenance est réduit, offrant immédiatement une valeur ajoutée sans nécessiter un temps de configuration et/ou d’adaptation important. Les statistiques utiles (couverture de code des tests, qualité de code, etc.) sont extraites lors de l’exécution du job et envoyées à l’une de nos applications internes pour publication au sein de Neoxia. Avec peu d’effort et surtout, avec un charge de préparation/configuration/maintenance réduite, Drone nous offre un service adapté à nos besoins.

Quant à Jenkins, il est utilisé pour des projets ayant des profils très différents : Java, Javascript (Angular), .Net, PHP et même quelques tests pour Force.com ; le tout est stocké sur des repositories Github, Gitlab, SVN, Mercurial, etc. Dans ce domaine, nous utilisons la grande adaptabilité de Jenkins apportée par la richesse de ses plugins, ce qui nous permet de builder des projets variés sur les mêmes machines. Les statistiques utiles sont mises en forme de rapport via des plugins classiques (Clover PHP, JUnit, …) et publiées directement sur Jenkins. Cette souplesse se paye néanmoins par un temps de configuration (du système, des plugins et des jobs) et de maintenance (suivi des versions de Jenkins et des plugins) assez important (de l’ordre de quelques jours par an).

matrice de comparaison Jenkins et Drone

matrice de comparaison Jenkins et Drone

Conclusion

Drone sort vainqueur du match dès que la comparaison s’appuie sur le rapport Résultat / Temps investi. Dès lors que l’environnement technique est le même sur tous les projets et qu’il est basé des technologies supportées par Drone (c’est souvent le cas pour des systèmes d’informations d’organisations en développement ou relativement jeunes), l’utilisation de ce dernier limite le temps nécessaire pour arriver à une intégration continue fiable. Ce temps peut alors être investi ailleurs.

Cependant, Jenkins a l’avantage d’être adaptable à tout environnement d’intégration existant (par exemple, si vous avez déjà un serveur de qualimétrie du code source en interne, comme Sonar). De plus, si l’ensemble des projets à “builder” utilise des environnements techniques et des technologies parfois très différents (ce qui est souvent le cas pour des systèmes d’information avec un long historique), Jenkins parviendra à répondre à votre besoin. Le prix à payer est d’y investir un peu plus de temps pour mettre en place et maintenir le serveur.

Note : il existe des versions SaaS pour ces serveurs d’intégration. Pour Drone, vous pouvez chercher du côté de drone.io et pour Jenkins, différentes offres notamment celle de CloudBees.

En savoir plus sur nos offres