vulp

vulp è nato dalla nostra stessa officina, non da un'idea di prodotto. Gestiamo decine di repository insieme - marchi, pannelli, bot, strumenti - e a un certo punto il solo tenere a mente quale repo aspetta un commit e quale un push costava più del lavoro stesso. Il git normale è eccellente per un singolo repo e del tutto impotente di fronte a trenta insieme.

Abbiamo quindi costruito uno strumento che tratta l'intero workspace come un'unica cosa: scansiona ogni repo in un solo passaggio, raccoglie il loro stato in una tabella e permette di eseguire la stessa operazione su molti insieme. Abbiamo posto una condizione ferma fin dall'inizio - lo stesso strumento deve servire sia l'umano alla tastiera sia lo script nella CI, senza due basi di codice separate da mantenere.

Quando gestisci un singolo repo, il git normale basta e avanza. A trenta diventa un rituale: entrare nella cartella, controllare il branch, vedere se l'albero è pulito, controllare se sei avanti rispetto al remote, tornare indietro, il prossimo. Prima di afferrare lo stato dell'insieme è passato un quarto d'ora, ed è comunque facile mancare l'unico repo che tiene modifiche non spinte da due giorni.

Il peggio è che questo costo cresce linearmente con il numero di repo, mentre l'attenzione umana no. Più cartelle da percorrere, più alta la probabilità che una venga saltata - e di solito è proprio quella in cui qualcosa è in sospeso. Un ciclo shell sulle cartelle aiuta un po', ma ogni ciclo del genere è un altro script da scrivere e mantenere, riscritto da zero ogni volta che serve un'operazione diversa.

vulp raccoglie quello stato in un unico posto e ti lascia fare la stessa cosa su molti repo con un solo comando. Invece di trenta chiamate a git status ottieni una tabella, e invece di un ciclo sulle cartelle - un solo comando con un ambito chiaro.

La decisione architetturale più importante è stata presa proprio all'inizio: tutta la logica vive nel nucleo, e la CLI e la TUI sono solo due pelli sulla stessa cosa. La CLI è senza prompt e restituisce JSON, quindi si inserisce negli script e nella CI senza analizzare testo pensato per gli umani. La TUI dà la stessa conoscenza a una persona che preferisce guardare una tabella piuttosto che ricordare i flag.

Grazie a questo una nuova operazione compare in entrambi i posti in una volta sola. La scrivi una volta, nel nucleo, e sia lo script cron sia l'umano con un tasto ottengono esattamente lo stesso comportamento - con le stesse protezioni. Sparisce un'intera classe di discrepanze del tipo "a mano si comporta diversamente che dalla pipeline".

Il flag che richiede un albero pulito non è un capriccio. Senza di esso un push in blocco può spedire lavoro a metà insieme a quello finito - e su trenta repo in una volta, così l'errore non si annulla con una sola mossa. I guardrail in vulp sono conservativi per default: preferiamo che lo strumento rifiuti e chieda di essere espliciti piuttosto che faccia in silenzio qualcosa di irreversibile.

Lo stesso principio vale per le operazioni di massa. Un push su un branch protetto, un push verso un repo avanti rispetto allo stato locale, un commit con un albero sporco dove non dovrebbe essercene uno - sono tutte cose su cui lo strumento deve fermarsi e chiedere, non indovinare l'intenzione. L'automazione senza freni è più veloce esattamente fino al primo errore.

Il push in sé non è la fine della storia - ciò che conta è ciò che sta davvero sul server. Lì teniamo un mirror dei repository, e dopo un'operazione vulp confronta lo stato locale con quel mirror e mostra dove il codice di un repo si è discostato da ciò che è realmente distribuito. Questo intercetta la trappola classica: una modifica commessa e spinta, ma mai distribuita, che quindi vive solo in git.

A ciò si aggiunge il lavoro quotidiano intorno ai repo, che passa anch'esso per lo stesso strumento: la revisione di PR, issue e statistiche di contributo. Invece di aprire un browser per ogni repo separatamente, lo vedi in forma aggregata, proprio dove guardi già lo stato del workspace.

L'effetto è noioso nel senso migliore del termine: controllare lo stato del workspace e spingere ciò che è pronto ha smesso di essere un rituale mattutino di clic. È rimasto un solo comando, da lanciare a mano oppure da pianificare e dimenticare - con le stesse protezioni in entrambi i casi.

Il guadagno più profondo è che lo strumento scala con il numero di repo e non contro di esso. Il ventesimo repo non aggiunge alcun rituale, perché tutta l'officina viene comunque percorsa in un solo passaggio. Una nuova operazione è una correzione nel nucleo che la CLI, la TUI e lo script di CI ricevono tutti - in un solo commit, senza deriva di versione.

La cosa più importante, però, è che vulp non è un gadget separato accanto al nostro lavoro - è lo stesso strato attraverso cui passano sia una mano sia un'automazione. Un umano clicca, cron scatta, e fanno esattamente la stessa cosa, con la stessa sicurezza. È la differenza tra uno script che funziona dall'autore e uno strumento su cui puoi contare ogni giorno.