Coder ses propres outils DevOps avec un agent IA - releaser & glint
Posted on Tue 14 July 2026 in Libre
Au boulot je passe une bonne partie de mon temps sur des pipelines GitLab CI et des workflows de release. Et régulièrement je tombe sur des trucs pour lesquels l'outillage existant fait 80% du taf correctement et se vautre lamentablement sur les 20% restants.
Avant, dans ce cas-là, on bricolait un script bash dégueulasse planqué dans un coin du repo, sinon on se bagarrait avec un outil existant à coups de configuration alambiquée jusqu'à ce que ça marche, ou à peu près. Cette fois j'ai pris une autre approche : coder mes propres outils CLI en Go, avec Claude Code en mode agent.
Résultat : deux outils, releaser et glint, et un REX sur la démarche.
Le problème de départ
GitFlow vs les outils de release automatique
semantic-release et consorts sont très bien foutus, mais ils partent tous du principe que vous êtes en TBD (trunk-based development) : une branche principale, on tag dessus, la version suivante c'est le dernier tag + le bump calculé depuis les Conventional Commits. Simple.
Sauf que sur pas mal de projets au boulot on est en GitFlow, avec des branches release/1.1, release/1.2, etc., maintenues en parallèle. Le concept même de "dernier tag sur la branche" n'a plus de sens de la même façon, et le major.minor est contraint par le nom de la branche, pas par les commits. Les outils existants soit l'ignorent complètement, soit demandent une configuration tellement tordue pour s'y adapter que ça devient plus fragile que le problème de départ.
Linter un .gitlab-ci.yml sans GitLab
Deuxième irritant, plus bête mais tout aussi chiant au quotidien : pour valider un .gitlab-ci.yml, l'outil de référence c'est le CI Lint intégré à GitLab par API.
Sympa, sauf qu'il faut soit pousser ses modifs a répétition, attendre, GitLab n'est pas vraiment verbeux et il ne dit quasiment rien sur les erreurs de logique (règles qui ne se déclenchent jamais, jobs orphelins, includes qui se marchent dessus). Rien d'équivalent à ansible-lint ou hadolint en local pour ce besoin.
Deux irritants récurrents, deux petits outils dédiés plutôt que deux usines à gaz de configuration pour forcer des outils génériques à faire un truc pour lequel ils n'ont pas été pensés.
releaser
releaser automatise le cycle de release en GitFlow avec Conventional Commits.
Documentation complète : Documentation releaser
Le principe :
- il extrait le
major.minordepuis le nom de la branche (release/1.2→1.2) - il cherche le dernier tag correspondant sur cette branche
- il analyse les Conventional Commits depuis ce tag
- il calcule le patch suivant (uniquement le patch, le major.minor est verrouillé par la branche)
- il met à jour les fichiers de manifeste du projet (
pom.xml,package.json,build.gradle,pyproject.toml) - il commit, tag, crée la release GitLab/GitHub, et notifie si configuré (Slack, Teams, Google Chat, Telegram, webhook)
En usage courant :
releaser --init # génère une config par défaut
releaser # exécute le cycle complet
releaser --dry-run # preview sans aucun effet de bord
releaser --verbose --dry-run # preview avec le détail des décisions
releaser --no-push # commit + tag en local seulement
Exemple d'une config .releaser.yml minimale, tout est optionnel avec des valeurs par défaut :
git:
tag_prefix: "v"
branch_pattern: "release/*"
bump_rules:
fix: patch
feat: patch
breaking: patch
build:
type: maven
file: pom.xml
Dans un job GitLab CI, ça donnerait ça :
release:
stage: release
rules:
- if: '$CI_COMMIT_BRANCH =~ /^release\/.*/'
script:
- releaser
artifacts:
reports:
dotenv: release.env
glint
glint c'est le linter local pour .gitlab-ci.yml qui n'existait pas. 45 règles (GL001 à GL045) qui couvrent la structure du pipeline, la validité des mots-clés, les dépendances entre jobs, les features dépréciées.
glint check # lint le pipeline, exit 0/2/10 selon la sévérité
glint render # fusionne includes/extends en un seul YAML
glint graph # visualise les dépendances (arbre terminal ou Mermaid)
glint explain GL007 # explique une règle et comment la corriger
glint lsp # démarre un serveur LSP pour l'intégration éditeur
Il résout les include: locaux, HTTPS, templates GitLab et composants du Catalogue CI/CD, avec du cache offline. Il simule aussi l'évaluation des règles rules:/only/except sur différents contextes de branche/tag, ce qui permet de repérer un job qui ne se déclenchera jamais sans avoir à pousser dix commits de test pour le vérifier.
Sortie en texte coloré, JSON, SARIF (pour l'intégration GitHub/GitLab scanning), JUnit, ou en annotations GitHub. Hook pre-commit, composant GitLab CI, action GitHub, extension VS Code : de quoi le brancher où on en a besoin.
git clone https://git.k3nny.fr/k3nny/glint
cd glint && go build -o glint ./cmd/glint/...
sudo mv glint /usr/local/bin/
Petite précision : C'est un outil perso construit pour un besoin perso, pas un produit. Je préfère l'assumer clairement plutôt que de vendre du rêve sur mon repo publique mais pas trop.
La démarche : coder avec un agent IA plutôt qu'à la main
Voilà le vrai sujet de cet article.
Ces deux outils, je ne les aurais probablement jamais écrits "à l'ancienne". Précision qui a son importance : je n'ai jamais développé en Go auparavant 😂.
Pas par flemme de coder donc, mais plutôt un calcul coût/bénéfice : un CLI Go avec parsing de commits, gestion multi-format de manifestes, notifications multi-canal, ou un linter avec 45 règles et un serveur LSP, je saurais faire mais c'est plusieurs jours de haute plomberie avant d'arriver à quelque chose d'intéressant. Avec un agent comme Claude Code, ce calcul change tout.
Quelques points qui ont vraiment fait la différence dans la pratique :
- Spécifier avant de coder. Le point de départ, c'est toujours d'expliquer précisément le problème métier (le coup du
major.minorverrouillé par la branche, les codes de sortie attendus pour un linter en CI) avant de laisser l'agent produire quoi que ce soit. Spec floue == Résultat foireux et faut s'y reprendre et redéfinir le besoin et patatra. - La partie ingrate, déléguée sans regret. Parser des Conventional Commits, gérer 4 formats de manifestes différents, écrire les tests qui vérifient que
release/1.2ne bumpera jamais vers1.3.0, rédiger le README avec tous les exemples de config : c'est exactement le genre de tâche mécanique où un agent est plus rapide et plus rigoureux que moi à 23h un mardi. Reste quand même à relire ce qu'il raconte, parfois c'est partiel et pas uniforme. - Itérer par petits cycles. Plutôt que "code-moi un linter GitLab CI complet", ça a été un rythme de type "prends en compte ce cas spécifique, avec les tests, 100% coverage, mise à jour README.md". Un agent est bien meilleur sur un scope précis et vérifiable que sur une spec vague de 3000 mots.
Au final, le gain n'est pas "l'IA a codé mes outils à ma place" (fin si un peu quand même), c'est plutôt que le seuil de rentabilité qui justifie de construire un outil dédié plutôt que de forcer la main à un outil générique a beaucoup baissé.
Deux irritants qui seraient restés des scripts bash bricolés dans un coin d'un repo pendant des années sont devenus deux vrais petits outils, testés, documentés, avec un CLI propre.
Conclusion
- Coder son propre outil reste justifié quand l'outil générique du marché ne colle juste pas au contexte (GitFlow, absence d'accès à l'API GitLab en local)
- Un agent IA type Claude Code ne remplace pas la réflexion sur le problème, il réduit drastiquement le coût de la partie ingrate une fois le problème bien posé
- Ça reste du code produit sous ma responsabilité : ptête ça va péter des trucs..
- J'ai cramé pas mal de tokens on va pas se le cacher
- Mais l'utilisation de RTK permet de limiter la casse
Les deux sont sous licence Apache 2.0, disponibles sur mon Gitea perso.
HF.
