vulp

vulp est né de notre propre atelier, pas d'une idée de produit. Nous gérons des dizaines de dépôts à la fois - marques, panneaux, bots, outils - et à un moment, le simple fait de garder en tête quel dépôt attend un commit et lequel attend un push coûtait plus que le travail lui-même. Le git ordinaire est excellent pour un seul dépôt et totalement démuni face à trente à la fois.

Nous avons donc construit un outil qui traite tout l'espace de travail comme un seul ensemble : il scanne chaque dépôt en une seule passe, réunit leur état dans un tableau et permet de lancer la même opération sur plusieurs à la fois. Nous avons posé une condition ferme dès le début - le même outil doit servir aussi bien l'humain au clavier que le script dans la CI, sans deux bases de code distinctes à maintenir.

Quand vous gérez un seul dépôt, le git ordinaire suffit amplement. À trente, cela devient un rituel : entrer dans le répertoire, vérifier la branche, voir si l'arbre est propre, vérifier si vous êtes en avance sur le distant, revenir, le suivant. Le temps de saisir l'état de l'ensemble, un quart d'heure s'est écoulé, et il reste facile de manquer le seul dépôt qui porte des changements non poussés depuis deux jours.

Le pire, c'est que ce coût croît linéairement avec le nombre de dépôts alors que l'attention humaine, non. Plus il y a de répertoires à parcourir, plus grande est la chance que l'un soit sauté - et c'est en général celui où quelque chose est en suspens. Une boucle shell sur les répertoires aide un peu, mais chaque boucle de ce genre est un script de plus à écrire et à maintenir, réécrit de zéro chaque fois qu'une opération différente est nécessaire.

vulp rassemble cet état en un seul endroit et vous permet de faire la même chose sur plusieurs dépôts en une seule commande. Au lieu de trente appels à git status, vous obtenez un tableau, et au lieu d'une boucle sur les répertoires - une seule commande au périmètre clair.

La décision d'architecture la plus importante a été prise tout au début : toute la logique vit dans le noyau, et la CLI et la TUI ne sont que deux peaux sur la même chose. La CLI est sans invite et renvoie du JSON, elle s'insère donc dans les scripts et la CI sans analyser du texte destiné aux humains. La TUI donne ce même savoir à une personne qui préfère regarder un tableau plutôt que de retenir des drapeaux.

Grâce à cela, une nouvelle opération apparaît aux deux endroits en même temps. Vous l'écrivez une fois, dans le noyau, et le script cron comme l'humain à la touche obtiennent exactement le même comportement - avec les mêmes protections. Toute une classe de décalages du type "à la main, ça se comporte autrement que depuis le pipeline" disparaît.

Le drapeau qui exige un arbre propre n'est pas un caprice. Sans lui, un push en lot peut expédier du travail à moitié fini avec le travail achevé - et sur trente dépôts à la fois, de sorte que l'erreur ne se défera pas d'un seul geste. Les garde-fous de vulp sont conservateurs par défaut : nous préférons que l'outil refuse et demande d'être explicite plutôt qu'il fasse en silence quelque chose d'irréversible.

Le même principe s'applique aux opérations de masse. Un push sur une branche protégée, un push vers un dépôt en avance sur l'état local, un commit avec un arbre sale là où il ne devrait pas y en avoir - ce sont autant de choses sur lesquelles l'outil doit s'arrêter et demander, pas deviner l'intention. L'automatisation sans freins est plus rapide exactement jusqu'à la première erreur.

Le push lui-même n'est pas la fin de l'histoire - ce qui compte, c'est ce qui se trouve réellement sur le serveur. Nous y gardons un miroir des dépôts, et après une opération, vulp compare l'état local à ce miroir et montre où le code d'un dépôt s'est écarté de ce qui est vraiment déployé. Cela attrape le piège classique : un changement commité et poussé, mais jamais déployé, qui ne vit donc que dans git.

À cela s'ajoute le travail quotidien autour des dépôts, qui passe lui aussi par le même outil : la revue des PR, des issues et des statistiques de contribution. Au lieu d'ouvrir un navigateur pour chaque dépôt séparément, vous le voyez de façon agrégée, là où vous regardez déjà l'état de l'espace de travail.

L'effet est ennuyeux au meilleur sens du terme : vérifier l'état de l'espace de travail et pousser ce qui est prêt a cessé d'être un rituel matinal de clics. Il reste une seule commande, à lancer à la main ou à planifier et oublier - avec les mêmes protections dans les deux cas.

Le gain plus profond, c'est que l'outil évolue avec le nombre de dépôts et non contre lui. Le vingtième dépôt n'ajoute aucun rituel, car tout l'atelier est parcouru en une seule passe de toute façon. Une nouvelle opération est une correction dans le noyau que la CLI, la TUI et le script de CI reçoivent tous - en un seul commit, sans écart de version.

Le plus important, cependant, c'est que vulp n'est pas un gadget à part à côté de notre travail - c'est la même couche par laquelle passent la main et l'automate. Un humain clique, cron se déclenche, et ils font exactement la même chose, tout aussi sûrement. C'est la différence entre un script qui marche chez son auteur et un outil sur lequel on peut compter chaque jour.