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 ?”. ...

En début de carrière, j’ai longtemps cru que bien comprendre les besoins d’un utilisateur, c’était une question de méthode. Agile, user stories, rituels Scrum bien tenus. J’ai appris que c’était surtout une question de patience, et d’accepter que les gens ne savent souvent pas ce qu’ils veulent jusqu’à ce qu’ils le voient (ou jusqu’à ce qu’on leur pose les bonnes questions). Ce qui ne marchait pas Chez Psynapse, j’ai construit un CRM à destination de thérapeutes. Pas des développeurs, pas des product owners rompus aux wireframes. Des gens dont le métier, c’est l’accompagnement humain, et qui n’avaient pas de vocabulaire pour me dire ce dont ils avaient besoin en termes de logiciel. ...

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 : ...

Tailscale, c’est bien. L’idée de reposer sur des serveurs tiers pour son réseau mesh, un peu moins. Headscale est l’implémentation open source du serveur de contrôle Tailscale : on garde les clients officiels, on remplace le plan de contrôle par quelque chose qu’on héberge soi-même. Point de départ : permettre un accès distant sécurisé aux serveurs d’une école. Pas envie de leur ouvrir des ports en direct ou de faire confiance à un service cloud tiers pour la gestion du réseau. Un petit VPS à 3-4€/mois avec Headscale, et les machines de l’école deviennent accessibles depuis n’importe où, sans exposition publique. ...

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 : ...

zoxide remplace cd par un saut intelligent. Tu tapes z projet et il t’emmène dans le dossier projet, même s’il est à 4 niveaux de profondeur. Il apprend tes habitudes : plus tu vas souvent dans un dossier, plus il le priorise. La commande s’appelle z. Pas zoxide, pas zoxide cd. Juste z. Un alias alias cd="z" et ni vu ni connu ! Setup # Installer sudo apt install zoxide # ou cargo install zoxide # Ajouter à .zshrc / .bashrc eval "$(zoxide init zsh --cmd z)" # (Le --cmd z renomme la commande en 'z' au lieu de 'zoxide') Cheatsheet zoxide Commande Équivalent cd Effet z projet cd ~/dev/machin/truc/projet Va au dossier le plus utilisé contenant “projet” z proj bidule - Combine “proj” et “bidule” pour trouver zi - Interface interactive avec fzf z - cd - Retour au dossier précédent z .. cd .. Remonte d’un niveau Le zi avec fzf est le plus utile : tu tapes zi, tu scrolles dans ton historique, tu choisis. Plus rapide que cd $(find . -type d | fzf). ...

Quand tu gères 120 dépôts et que chaque action commence par “ouvrir GitLab → Projects → chercher le projet → cliquer → …”, tu perds un temps fou. glab remplace l’interface web pour toutes les opérations courantes. # Installer brew install glab # macOS sudo apt install glab # Linux (ou télécharger le binaire) # Authentification (une fois) glab auth login Ce que j’utilise souvent # Créer une MR depuis la branche courante glab mr create --title "Fix: pipeline timeout" --assignee @me # Lister mes MRs ouvertes glab mr list --assignee @me # Voir le statut d'une pipeline glab ci status --branch main # Relancer un job spécifique glab ci retry --job build # Lister les issues glab issue list --label "bug" --assignee @me # Créer un snippet (partage de code rapide) glab snippet create fichier.py --title "Debug: race condition" Le combo qui tue avec git # Créer une branche, commit, push, MR en une passe git checkout -b fix/timeout git commit -am "fix: increase pipeline timeout" git push -u origin HEAD glab mr create --fill # --fill utilise le message du commit comme titre Cheatsheet glab Commande Équivalent UI GitLab glab mr list -a @me Merge Requests → Assignees → Moi glab mr view 42 Ouvrir la MR #42 glab mr merge 42 Bouton “Merge” glab ci status CI/CD → Pipelines glab ci trace Logs du job en cours glab release create 1.0 Deploy → Releases → New release glab api projects/:id API GitLab sans curl ni token glab api est la killer feature : tu appelles l’API GitLab directement avec ton token géré par glab. Plus besoin de curl -H "...". ...

J’ai deux vies Git : une pro (Gitlab d’entreprise, email pro, clé SSH pro) et une perso (GitHub perso, email perso, clé SSH perso). Avant d’utiliser ce qui suit, il m’est arrivé de devoir réécrire l’historique git parce que j’avais commit avec la mauvaise identité. includeIf règle ça. On définit une config différente selon le chemin du repo. # ~/.gitconfig [includeIf "gitdir:~/dev/michelin/"] path = ~/.gitconfig-michelin [includeIf "gitdir:~/dev/perso/"] path = ~/.gitconfig-perso Et chaque fichier ne contient que les différences : ...

GitLab peut extraire le pourcentage de couverture de tests depuis les logs du job et l’afficher dans le badge du projet, les MR, et l’UI. Il suffit de définir une regex dans coverage:. Et c’est là que tout le monde se plante. La regex qui foire systématiquement # ❌ Ne matchera JAMAIS job: script: pytest --cov coverage: '/TOTAL.*\s+(\d+%)$/' Pourquoi ? $ veut dire “fin de ligne”. Mais les logs GitLab sont collectés dans un buffer multi-lignes. La vraie fin de ligne dans ce buffer, c’est la dernière ligne du log entier, pas la ligne TOTAL. ...

Pousser un commit juste pour tester un changement de .gitlab-ci.yml, c’est 30 secondes par tentative. Sur une pipeline un peu tordue, 20 essais. 10 minutes perdues à corriger des erreurs de syntaxe. gitlab-ci-local exécute tes pipelines en local, avec Docker. Tu modifies ton .gitlab-ci.yml, tu lances gitlab-ci-local, tu vois les erreurs immédiatement. Zéro push, zéro attente de runner. # Installer npm install -g gitlab-ci-local # Lancer tous les jobs du .gitlab-ci.yml courant gitlab-ci-local # Lancer un job spécifique gitlab-ci-local --job build # Lister les jobs disponibles gitlab-ci-local --list Ce que ça supporte image, services, before_script, script, after_script artifacts, cache (local, pas partagé) variables, extends, !reference, needs parallel:matrix (partiellement) Ce que ça NE supporte PAS trigger (pipelines enfants) environment (pas de déploiement réel) rules:if avec des variables GitLab prédéfinies ($CI_COMMIT_BRANCH) Runner tags, Kubernetes executor Le piège gitlab-ci-local utilise Docker pour exécuter les jobs. Si ton job fait référence à $CI_REGISTRY_IMAGE ou $CI_JOB_TOKEN, ces variables n’existent pas en local. Il faut les définir manuellement : ...