GitLab CI parallel:matrix : les needs individuels sont enfin là

Avant, parallel:matrix permettait de lancer la même tâche sur plusieurs versions. Mais impossible de référencer UN job spécifique de la matrice dans un needs. Toute la matrice formait un bloc indivisible. GitLab 16.7 a changé ça. Maintenant, tu peux needs un job précis de la matrice. Et ça débloque des pipelines plus propres. Avant : le workaround # ❌ Avant GitLab 16.7 : impossible de référencer un job de la matrice test: parallel: matrix: - PYTHON: ["3.9", "3.10", "3.11"] script: pytest deploy: needs: ["test"] # Attend TOUS les jobs de la matrice script: ./deploy.sh Après : des needs chirurgicaux # ✅ GitLab 16.7+ : on cible un job précis test: parallel: matrix: - PYTHON: ["3.9", "3.10", "3.11"] script: pytest deploy_39: needs: ["test: [3.9]"] script: ./deploy-py39.sh deploy_latest: needs: ["test: [3.11]"] script: ./deploy-pylatest.sh Le job deploy_39 attend UNIQUEMENT test: [3.9]. Il n’attend pas les tests Python 3.10 et 3.11. Résultat : le déploiement peut partir dès que sa version est validée, sans attendre les autres. ...

just : un Makefile moderne que j'ai quitté pour make

J’ai découvert just en parcourant des projets Rust lorsque j’ai commencé à apprendre le langage. just c’est un Makefile sans la syntaxe particulière de Make. Les recettes sont plus lisibles, le langage est pensé pour lancer des commandes (pas pour compiler du C). Et la syntaxe des dépendances est plus intuitive : # justfile deploy: build push kubectl apply -f deploy/ build: docker build -t monapp . push: docker push monapp:latest Moi qui ai tendance à utiliser pas mal Make pour ce genre de raccourcis (et jamais pour builder du C), ça m’a convaincu pendant 3 mois. Puis j’ai travaillé sur des machines où just n’était pas installé. Et là, Make est toujours installé. Prêt à opérer. Aucun obstacle. ...

k9s : l'UX qui fait aimer Kubernetes, au prix de l'amnésie kubectl

k9s est un excellent TUI Kubernetes. Quand je l’ai découvert, j’ai eu l’impression de passer du terminal IBM 3270 à un OS graphique. Tu navigues dans les pods avec ↑↓, tu filtres avec /, tu lances des commandes avec :. Plus besoin de taper kubectl get pods -n machin -o wide | grep bidule. Mais il y a un prix : tu oublies kubectl. Vite. Très vite. Ce que k9s fait mieux que kubectl Navigation : :pods → liste des pods → Enter sur un pod → logs. 3 touches au lieu de kubectl get pods -n X && kubectl logs -n X pod/Y. Filtrage : /error filtre en temps réel. Ctrl+A pour désactiver. C’est grep intégré, réactif à chaque frappe. Actions : d pour décrire, s pour shell, l pour logs, y pour YAML. Tout le monde a les mêmes raccourcis — pas besoin d’apprendre les flags. Nodes : :nodes → tu vois l’état des nœuds, les pods par nœud, les ressources utilisées. En une vue. kubectl describe node × 10 nœuds, c’est 10 commandes. k9s = une vue. Le revers Après 3 mois de k9s intensif, j’ai réalisé que j’étais incapable d’écrire un kubectl get pods --sort-by=.status.startTime sans Google. k9s m’a rendu plus rapide au quotidien mais plus dépendant d’un outil qui n’est pas installé partout. ...

uv a remplacé pip dans mon workflow Python

J’ai découvert uv en février 2025. En mars, pip n’existait plus chez moi. Avant, gérer les dépendances Python c’était pip + pip-tools + virtualenv + un fichier texte pour se souvenir de la commande d’activation. Trop de pièces mobiles pour un truc qui devrait être simple. (Quant à poetry, j’ai jamais passé le pas) uv pip install est 10 à 100× plus rapide que pip. uv venv crée un virtualenv en moins d’une seconde. Et uv pip compile remplace pip-tools sans avoir à installer quoi que ce soit. Tout est dans un seul binaire. ...

age + sops : le combo qui remplace GPG pour les secrets dans Git

Stocker des secrets dans Git, tout le monde le dit : c’est une mauvaise pratique. Mais stocker ses secrets dans un vault et ses fichiers de config dans Git, c’est deux sources de vérité qui finissent par dériver. sops résout ça : on commit ses secrets chiffrés avec ses fichiers de config. Un seul dépôt, une seule source de vérité. Au déploiement, le secret est déchiffré à la volée. Setup avec age # Générer une clé age (une ligne) age-keygen -o ~/.config/sops/age/keys.txt # Récupérer la clé publique age-keygen -y ~/.config/sops/age/keys.txt # → age1ql3z7hjy54p3w6d... La config minimale .sops.yaml à la racine du dépôt : ...

age vs GPG : pourquoi j'ai arrêté de m'arracher les cheveux

Pendant des années, chiffrer un fichier c’était : générer une clé GPG, la stocker sur une clé physique, gérer l’expiration, prier pour que le keyring ne soit pas corrompu, et relire la doc GPG pour la trente-septième fois. age a remplacé tout ça. Une clé publique, une clé privée, zéro concept de keyring. La clé privée tient sur une ligne. La clé publique aussi. C’est tellement simple qu’on peut les stocker dans son gestionnaire de mots de passe. ...

zellij : pourquoi je n'ai jamais eu besoin de tmux

Je n’ai jamais utilisé tmux. Pas par principe, juste parce que quand j’ai commencé à chercher un multiplexer, zellij est tombé au bon moment. C’est contre-intuitif : tmux est plus réputé, plus ancien, installé partout. Mais zellij a une qualité rare : il est utilisable sans config. Pas de .tmux.conf à écrire. Pas de préfixes bizarres à mémoriser. Une barre d’état qui montre les onglets et les processus en cours, sans plugin. Des raccourcis qu’on découvre en appuyant sur Ctrl+G. ...

GitLab CI resource_group : empêcher deux déploiements concurrents

Quand deux pipelines déploient sur le même environnement en parallèle, le deuxième écrase le premier. Résultat : état incohérent, erreurs de connexion, rollback en catastrophe. resource_group règle ça proprement. Tu assignes un nom de groupe à un job de déploiement. GitLab garantit qu’un seul job par groupe s’exécute à la fois. Les autres attendent. deploy_staging: stage: deploy script: ./deploy.sh staging environment: name: staging resource_group: staging Si deux pipelines arrivent en même temps sur deploy_staging, le premier s’exécute, le deuxième attend que le premier finisse. Pas de lock manuel, pas de vérification Slack “qui déploie ?”. ...

direnv + .envrc : j'arrête de source des variables à la main

J’en avais assez de taper source .env en entrant dans chaque projet. Et surtout d’oublier de le faire une fois sur trois, et de perdre 10 minutes à comprendre pourquoi la variable d’environnement n’était pas chargée. direnv règle ça en un hook shell. Tu entres dans un dossier, il exécute .envrc. Tu en sors, il décharge tout. Plus rien à faire. Mais ce qui change tout, c’est quand on le combine avec un password manager en CLI (pour ma part rbw) pour injecter les secrets automatiquement : ...

fzf + rg + fd : la trinité qui rend mon terminal plus rapide que l'explorateur

Trois outils. Chacun remplace un binaire POSIX vieux de 40 ans. Ensemble, ils transforment le terminal en interface plus rapide que n’importe quel explorateur graphique. Alors oui, c’est dans les vieux pots qu’on fait les meilleures soupe et si un binaire qui a 40 ans est toujours utilisé, c’est qu’il y a une bonne raison, mais là, ce serait dommage de se privée d’une UX shell bien léchée. fd remplace find. Même usage, syntaxe humaine : ...