Journal Laminar: un outil d'intégration continue qui semble léger

Posté par  . Licence CC By‑SA.
Étiquettes :
13
21
déc.
2019

Ça fait quelques temps (en années, probablement) que la notion d'intégration continue m'intéresse, de loin, mais j'ai toujours eu l'impression que les outils existants sont super spécialisés, difficiles à installer réellement (souvent distribué avec l'OS quasi-complet, que ce soit via un conteneur ou une VM, ou pire: installé par wget foobar | sudo sh), pas vraiment très séduisant selon moi.

Bref, après la lecture du journal sur citop j'ai refait des recherches, et suis tombé sur laminar, outil écrit en C++ sous licence GPL (via l'excellent alternativeto, bien pratique ce site).
J'ai lu rapidement quelques fichiers source aléatoires, comme j'aime le faire quand je compte adopter un outil, ainsi qu'une bonne partie de la doc, même si je n'ai pas encore tenté l'install (n'étant pas chez moi, et de toute façon je vais avoir pas mal de choses à faire dans les jours à venir) et de ce que j'ai compris:

  • peu de dépendances: boost (pour un seul template header-only), rapidjson, sqlite, et canproto;
  • la seule interface graphique exposée est une page non-intéractive (dans le sens ou elle ne peut interagir avec le système, juste donner des infos à l'utilisateur) non sécurisé;
  • l'écriture des tâches se fait en shell, pas besoin d'apprendre python, ruby, lisp, ou autre langage, pas non plus de DSL;
  • le code me semble plutôt clean: moins d'une 10aine de fichiers cpp, un CMakeLists de moins de 150 lignes, et un code qui semble beau en lecture diagonale (sur les 3-4 fichiers que j'ai lus, hein);

Ce que la page d'accueil annonce, c'est qu'il s'agit d'un outil léger, rapide, fait pour être hébergé soi-même, qui ne fait qu'une seule chose.
Mon impression, c'est que les promesses sont tenues, il me semble même simple d'implémenter une interface moins «lourde» qu'une interface web (encore que, n'ayant pas vue la page de résultats, je ne sais pas ce qu'elle vaut…) puisqu'il est possible de simplement utiliser les scripts foo.after pour émettre des données vers un fichier ou un outil de monitoring, par exemple.

Si quelqu'un connaît, je serais curieux d'avoir un avis d'expérience réelle, parce que ça me motive pas mal, malgré l'inconvénient que, du coup, il faut être accessible du web si on veut l'intégrer à github, gitlab, bitbucket, sourceforge ou autre, mais bon, perso, ça ne me dérange pas trop (les raisons de ça n'ont pas leur place ici).

  • # Drone

    Posté par  (site web personnel) . Évalué à 6.

    Je ne connais pas cet outil, mais moi aussi je cherchais un outil léger et rapide et je suis tombé sur drone.io.

    J'aime sa légèreté et le fait qu'il ne dépende que de docker, que j'utilise déjà.

    En généralement les outils en go sont aussi pas mal niveau légèreté. J'utilise gitea comme forge a côté de drone.

  • # A court terme, pourquoi pas

    Posté par  . Évalué à 6.

    Je maintiens des systèmes d'intégration continue et de déploiement continu (CI/CD) depuis maintenant une dizaine d'années. Un bon système d'intégration continue, ça doit être bien documenté, facile à administrer, fiable, déterministe et ne doit pas rendre obligatoire de s'y coupler fortement. Après vient la scalabilité, mais dans ce que tu me décris, ça ne semble pas être un problème.
    Franchement, Laminar remplit une grosse partie du contrat. C'est quasiment qu'une interface pour afficher des résultats de build. Je suis juste sceptique sur sa pérennité, parce que coder ça en C++ ne semble pas très pertinent pour une interface web. Mais c'est pas franchement risqué de s'y engager vu que le couplage reste faible avec ses scripts shell à la place d'un langage de pipeline comme c'est actuellement la mode (Jenkins, gitlab, …).
    En ce qui concerne les intégrations, ça fait voyager dans le monde du vendor lock-in et/ou dans l'enfer des plugins gratuits de CI/CD. J'aimerais bien avoir de beaux outils parfaits à te proposer, mais l'offre libre de CI/CD n'est pas au beau fixe. Soit on a des outils fragiles avec plein de plugins de qualité variable au rythme de maintenance aléatoire (Jenkins), soit on a des trucs sous documentés (Concourse), pleins de contraintes (Drone) ou une conso délirante de ressources (Gitlab).
    Côté logiciels propriétaires, oui, faudra se fader des interfaces web. Teamcity est un plaisir à utiliser et administrer, son offre gratuite est potable pour de petits projets. Il encourage très fortement au vendor lock-in, hélas.

    • [^] # Re: A court terme, pourquoi pas

      Posté par  . Évalué à 2.

      Un bon système d'intégration continue, ça doit être bien documenté, facile à administrer, fiable, déterministe et ne doit pas rendre obligatoire de s'y coupler fortement.

      Je ne comprends pas bien ce dernier point. Le build doit être agnostique (pas dépendant d'un IDE ou d'une CI), mais la glue autour pour gérer un workflow/pipeline pour la CI/CD ça ne me gène pas que ce soit spécifique.

      une conso délirante de ressources (Gitlab).

      J'ai très peu utiliser gitlab CI et je n'ai jamais administré autre chose que des workers, je ne me suis pas rendu compte de souci de ressources.

      Teamcity est un plaisir à utiliser et administrer, son offre gratuite est potable pour de petits projets.

      Il consomme pas trop de ressources ? Je ne m'en suis jamais servi, mais un ami, m'expliquait que c'était assez contraignant à ce niveau là (on utilise déjà intellij et upsource au boulot, passer de jenkins à teamcity pourrait être une bonne idée).

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Alternatives

    Posté par  . Évalué à 2.

    Je suis comme vous je cherche l'outil légér (out jenkins) et simple pour répondre à mes besoins de CI/CD.
    En plus de drone je suis tombé sur les 3 projets suivants (écrits en Go), je n'ai pas encore choisi.

    D'autres ici : https://github.com/ciandcd/awesome-ciandcd

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.