Aller au contenu | Aller au menu | Aller à la recherche

Outils d'integration continue, retour d'expérience

Dans un billet précédent, j'avais fait un comparatif d'outils d'intégration continue. Après quelques jours d'utilisation, revirement de décision, j'ai finalement abandonné Jenkins...

J'avais testé peut-être un peu trop rapidement les différentes solutions. Il s'avère que je n'avais pas assez approfondi l'utilisation de Jenkins. L'une des premières tâches à implémenter, était de récupérer les sources d'un site statique à partir d'un dépôt git, et de les pousser via un rsync ou un scp vers le serveur de prod ou de dev en fonction de la branche. J'ai bien mis 2-3 heures à trouver les bons plugins, à les configurer et à faire en sorte que ça fonctionne. Et encore, le résultat me paraissait un peu bancal. J'ai ensuite regardé pour une autre tâche de test / déploiement plus complexe. Je me suis battu contre l'outils. Usine à gaz.

J'ai abandonné. Quand on se bat trop contre un outils, il faut le changer.

J'ai alors ré-installé Gitlab-CI et écrit un petit script bash pour le déploiement du site statique. En à peine une heure, tout était opérationnel. Le site se déployait à chaque push, sur le serveur de test ou sur le serveur de prod suivant la branche modifiée. J'ai essayé un truc plus complexe. Idem, je ne me suis pas battu. J'ai juste écrit plus de code. C'est moins sexy qu'un clickodrome, mais au moins ça fait exactement ce qu'on veut.

J'ai ré-installé également Strider-CD, en me disant que puisqu'il faudra que je me tape des scripts de tests/déploiement à la main, pourquoi ne pas ré-essayer Strider-CD. Rappelez vous, je disais qu'un de ses défauts était le manque de plugins, mais il en a un par défaut qui permet de lancer simplement des scripts, comme Gitlab-CI. Son autre souci est que l'intégration avec Gitlab ne se fait pas en un click. Il faut comprendre à quoi correspond chaque paramètre de la conf. Au final, ça n'a pas fonctionné à 100%, à cause de problème de certificats. Car cette fois-ci, contrairement à mes essais précédents, le gitlab et le strider sont accessibles via HTTPS, avec des certificats signés par une autorité "non officielle". J'ai eu beau mettre le certificat racine au niveau du système, toujours ces problèmes de certificats. Bref, j'ai lâché l'affaire au bout d'un moment. Par contre j'en ai profité pour tester son intégration avec Github : déclaration de l'appli Strider-cd dans le compte github, stockage des clés dans la conf, clic sur le bouton github dans l'interface : j'ai accès à tout mes projets github. Quelque autres clics plus tard, j'avais une tâche qui clonait le projet et pouvait exécuter des scripts sur les sources. Simplissime au final.

Conclusion :

  • Je laisse de coté Jenkins, finalement trop usine à gaz. Peut-être convient-il mieux pour des processus de tests très complexes ou projets java. Je ne sais pas. Mais en tout cas, à l'heure actuelle, il ne me plait pas du tout en tant qu'admin.
  • Gitlab-CI : le compagnon idéal quand on utilise Gitlab. Noter qu'il ne peut travailler qu'avec Gitlab. Il a quelques limitations comme je l'ai mentionné dans le billet précédent, mais on peut éspérer des améliorations dans un futur proche
  • Strider-CD : la solution la plus simple pour des projets se trouvant sur Github ou Bitbucket, que j'utiliserais probablement pour mes projets comme Jelix ou SlimerJS

Commentaires

1. Le jeudi, mars 6 2014, 15:06 par Philip_Marlowe

Juste au cas où ça pourrait te servir. Quand tu as parlé de Jenkins, ça m'a rappelé un post d'Emmanuel Stapf sur Eiffel Room.
http://www.eiffelroom.org/article/u...
Il y a quelques explications et un petit howto. Pour ma part, je suis neutre, ne connaissant ni ne m'en servant.

2. Le mardi, mars 18 2014, 18:44 par Shine-neko

FInalement tu utilises quoi ? Je suis dans le même cas que toi. Travis serait le compagnons idéal s'il n'était pas aussi cher :D