jy[B]log

Gitlab-CI

Nous utilisons GitLab, alors pourquoi ne pas utiliser Gitlab-CI ? Interface épuré, forte intégration avec Gitlab, il semble être un bon candidat, même si, en lisant les caractéristiques sur le site, il semble léger. Vérifions tout cela. C'est parti donc pour une installation. Il faut savoir que c'est réalisé avec Ruby On rails et utilise mysql ou Postgresql pour ses données.

Première déconvenue : autant la documentation de Gitlab est très précise et claire (vous tapez toutes les commandes indiquées, dans le bon ordre, ça s'installe sans accro, en 20 minutes à peine), autant celle de Gitlab-CI est incomplète. Une impression de doc inachevée. Du coup ça a été un peu plus sport, avec, au hasard, des problèmes de création de la base de donnée avec PostgreSQL, l'absence totale de doc pour l'installer derrière un Apache (j'ai finalement pris le vhost créé pour Gitlab, renommé 2-3 trucs et ça roulait), des problèmes de configurations avec Puma, le serveur http utilisé par Gitlab-Ci (alors qu'ils utilisent Unicorn pour Gitlab...). M'enfin, on s'en sort quand même, avec un peu de temps et de patience.

Deuxième déconvenue : le manque de fonctionnalité s'est confirmé. C'est un outil trés, trés, trés simpliste par rapport à la concurrence. Ce n'est au final qu'un super hook pour git :

• Gitlab-ci se "branche" sur un dépôt Gitlab (pour des dépôts hébergés par d'autres outils, oubliez)
• à l'arrivée des commits, il clone ou fetch le dépot, et lance un script (que vous devez écrire) via un des "runners" installés en local ou sur d'autres machines.
• selon le code de sortie du script, alors la tâche est considérée comme un succès ou un échec.
• le rapport d’exécution se limite à la sortie console de votre script. pas de prise en charge des sorties xunit etc
• une notification du résultat par email peut être faite.

Et... c'est tout.

Cela veut dire que vous devez tout faire à la main dans le script de la tâche : lancement des tests, déploiements etc... Il n'y a pas de système de plugins pour lui rajouter des fonctionnalités. Le seul intérêt est son intégration avec Gitlab : il partage le même système d'authentification, il sait lister tout les projets, et la création d'une tâche se fait en cliquant sur un bouton en face du projet dans la liste. (Mais une seule tâche par projet).

C'est vraiment très light. Trop light pour nos besoins.

Strider-CD

Pendant mes recherches, je suis tombé sur cet outils que je ne connaissais même pas de nom : Strider-CD. Il a attiré mon attention grâce à quelques aspects originaux :

• il est basé sur NodeJS et utilise MongoDb pour le stockage de ses données
• il met en avant l'aspect déploiement d'un projet

Et il semble un peu plus riche en fonctionnalité que Gitlab-CI. L'installation pour un simple essai est plus simple (si nodejs et mongodb sont déjà installés) :

• clonage des sources
• un coup de npm install
• strider addUser pour créer un premier utilisateur
• strider pour lancer le serveur qui est disponible alors sur le port 3000

Par contre la documentation ne donne aucune instruction supplémentaire pour une installation sécurisée en production, la conf Apache pour faire du reverse proxy etc... Mais on s'en sort avec Google. Je n'ai pas essayé de configuré l'appli en HTTPS...

Strider-cd est orienté pas uniquement tests et intégration, mais aussi déploiement. Cela veut dire que les tâches de tests et de déploiements sont des étapes distinctes.

Il a un système de plugin. Les plugins sont des modules NodeJS. Ce système permet d'ajouter :

• des "runner" : ce sont les plugins chargés de lancer les tâches. Par défaut on a un simple runner qui lance les tâches sur la même machine. Il y en a un autre permettant de lancer les tâches via Docker. Mais ça devient un peu lourd. Aucun runner existant à déployer sur une autre machine (!)
• des "providers" : ils sont chargés de récupérer les sources d'un projet. Par défaut, il y a des providers pour github, bitbucket, et un générique pour récupérer un dépôt git quelconque (par exemple hébergé par gitlab)
• des "tâches" : ce type de plugin savent lancer un build, ou déployer des fichiers etc.. On a par exemple un plugin pour lancer les tests d'un module Node (qui va en gros faire un "npm test").
• des "basic" : ce sont des plugins dans lesquels vous faites de ce que vous voulez. Mais l'API exposée par strider sera moins spécifique que pour les autres types de plugin.

Le concept est plutôt attrayant. La réalisation de plugins n'a pas l'air trop compliquée. Un point noir cependant, l'offre est quasi nulle : il n'y a pratiquement pas de plugin existant. Le projet étant probablement trop jeune. il ne semble pas non plus y avoir la possibilité d'afficher des résultats sous une autre forme que du texte brute : comme Gitlab-CI, vous n'avez que la sortie console.

Aussi le choix de Strider implique :

• soit l'utilisation du plugin fourni "custom scripts" pour écrire les scripts shell qui lanceront les tests, qui feront les déploiements etc.. Bref, pas de clickodrome qui vous mâche le travail
• soit le développement de plugins qui permettront à terme de créer plus facilement les tâches. Mais il faut du temps.

Contrairement à Gitlab-Ci, Strider a du potentiel grâce à son système de plugin. Mais pour le moment, vu le manque de plugins et si on manque de temps pour en développer, il n'apporte pas grand chose de plus que GitLab-CI.

TeamCity

Avec Jenkins, TeamCity est un des outils que j'ai pu utiliser au quotidien dans des projets précédents. C'est certainement le plus complet que je connaisse, avec la possibilité entre autre d'organiser les builds de manière hiérarchique. Il a lui aussi un système de plugins. L'interface est toutefois un peu fouilli à mon goût, même si elle est plus moderne que celle de Jenkins. Et la principale ombre au tableau : c'est du bon bloatware J2EE powered avec tous les défauts qui vont avec : il faut une machine de guerre pour faire fonctionner le truc. En tout cas, c'est un mammouth par rapport à une appli NodeJs comme StriderCD.

Autre point : c'est payant. Ou presque : il y a bien une version gratuite, mais elle est limitée à 20 builds. Donc insuffisant pour une entreprise. Donc payant :-) Ça peut être un frein si le budget est limité..

Jenkins

Aaah Jenkins... Ce bon vieux Jenkins... Je te hais. Quelle interface horrible ! Quel bloatware ! Installation fraiche sur mon poste, 0 projet géré : pauvre machine, elle se fait déjà bouffer 6Go de mémoire virtuelle, et près de 800Mo de mémoire réellement utilisée. Sans rien faire hein ! Pas de tâche en cours, rien. Sans compter le processus jetty à coté. Non, lui, je n'en parlerais pas, ça fait trop mal. Bref, encore du bon bloatware Java. Tout comme TeamCity, il y a intérêt à avoir une machine bien dimensionnée.

Enfin bon, même si mes souvenirs ne sont pas très bon sur l'utilisation de cet outils, je reconnais, (à regret), qu'après l'avoir installé de nouveau, il semble la solution open-source la plus complète. Des plugins à profusion (il y a à priori tout ceux que l'on a besoin pour notre plateforme), de la doc un peu partout sur le web. Et puis j'ai découvert un plugin, "simple theme", qui permet de relooker un peu cette interface illisible par le biais d'une feuille CSS, celle-là par exemple.

Conclusion

Par rapport à nos besoins, j'ai finalement éliminé Gitlab-CI et Strider-CD. Je continuerai toutefois à surveiller du coin de l'oeil Strider-CD, il me semble prometteur. Il aura le potentiel de Jenkins quand il y aura suffisamment de plugins. Reste Jenkins et TeamCity. Ils ont tout deux le problème d'être gourmand en ressources. TeamCity est toutefois plus sympa. Si vous avez du budget, prenez TeamCity. Sinon Jenkins reste un bon outils dans l'ensemble. À la condition d'avoir une machine costaud.

Si vous utilisez d'autres outils d'intégration continue (autre que des formules Saas, que je ne veux pas), n'hésitez pas à m'en faire part :-)

Mise à jour 06/03/2014 : j'ai changé d'avis ! Voici un retour d’expérience.