Ç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 phoenix (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 damaki . É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 barmic 🦦 . Évalué à 2.
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.
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.
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 Narmer . É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.
Gaia pipeline : Gaia is an open source automation platform which makes it easy and fun to build powerful pipelines in any programming language. Version Alpha.
Agola CI/CD : CI/CD redefined.
Banzai Cloud Pipeline
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.