vulp

vulp surgió de nuestro propio taller, no de una idea de producto. Gestionamos decenas de repositorios a la vez - marcas, paneles, bots, herramientas - y en cierto momento solo mantener en la cabeza qué repo espera un commit y cuál un push costaba más que el trabajo en sí. El git normal es excelente para un solo repo y completamente impotente ante treinta a la vez.

Así que construimos una herramienta que trata todo el espacio de trabajo como un solo conjunto: escanea cada repo en una sola pasada, reúne su estado en una tabla y permite ejecutar la misma operación sobre muchos a la vez. Pusimos una condición firme desde el principio - la misma herramienta debe servir tanto a la persona en el teclado como al script en la CI, sin dos bases de código separadas que mantener.

Cuando gestionas un solo repo, el git normal basta de sobra. Con treinta se vuelve un ritual: entrar en el directorio, comprobar la rama, ver si el árbol está limpio, comprobar si vas por delante del remoto, salir, el siguiente. Para cuando captas el estado del conjunto ha pasado un cuarto de hora, y aun así es fácil pasar por alto el único repo que guarda cambios sin empujar desde hace dos días.

Lo peor es que ese coste crece linealmente con el número de repos, mientras que la atención humana no. Cuantos más directorios hay que recorrer, mayor es la probabilidad de que uno se salte - y suele ser justo aquel en el que algo está pendiente. Un bucle de shell sobre los directorios ayuda un poco, pero cada bucle así es otro script que escribir y mantener, reescrito desde cero cada vez que hace falta una operación distinta.

vulp reúne ese estado en un solo lugar y te permite hacer lo mismo sobre muchos repos con un único comando. En lugar de treinta llamadas a git status obtienes una tabla, y en lugar de un bucle sobre los directorios - un solo comando con un alcance claro.

La decisión de arquitectura más importante se tomó al principio del todo: toda la lógica vive en el núcleo, y la CLI y la TUI son solo dos pieles sobre la misma cosa. La CLI es sin prompts y devuelve JSON, así que se integra en scripts y CI sin analizar texto pensado para personas. La TUI da ese mismo conocimiento a quien prefiere mirar una tabla antes que recordar flags.

Gracias a eso una nueva operación aparece en ambos sitios a la vez. La escribes una vez, en el núcleo, y tanto el script de cron como la persona con una tecla obtienen exactamente el mismo comportamiento - con las mismas salvaguardas. Desaparece toda una clase de desajustes del tipo "a mano se comporta distinto que desde el pipeline".

El flag que exige un árbol limpio no es un capricho. Sin él, un push por lotes puede enviar trabajo a medias junto con el terminado - y sobre treinta repos a la vez, así que el error no se deshace de un solo movimiento. Los guardarraíles de vulp son conservadores por defecto: preferimos que la herramienta se niegue y pida ser explícito antes que haga en silencio algo irreversible.

El mismo principio vale para las operaciones masivas. Un push a una rama protegida, un push a un repo que va por delante del estado local, un commit con árbol sucio donde no debería haberlo - son todas cosas ante las que la herramienta debe detenerse y preguntar, no adivinar la intención. La automatización sin frenos es más rápida exactamente hasta el primer error.

El push en sí no es el final de la historia - lo que cuenta es lo que realmente está en el servidor. Allí mantenemos un espejo de los repositorios, y tras una operación vulp compara el estado local con ese espejo y muestra dónde el código de un repo se ha desviado de lo que está realmente desplegado. Esto atrapa la trampa clásica: un cambio commiteado y empujado, pero nunca desplegado, que por tanto solo vive en git.

A esto se suma el trabajo diario en torno a los repos, que también pasa por la misma herramienta: la revisión de PRs, issues y estadísticas de contribución. En lugar de abrir un navegador para cada repo por separado, lo ves de forma agregada, justo donde ya estás mirando el estado del espacio de trabajo.

El efecto es aburrido en el mejor sentido de la palabra: comprobar el estado del espacio de trabajo y empujar lo que está listo dejó de ser un ritual matutino de clics. Quedó un solo comando que se puede lanzar a mano o programar y olvidar - con las mismas salvaguardas en ambos casos.

La ganancia más profunda es que la herramienta escala con el número de repos y no contra él. El vigésimo repo no añade ritual, porque todo el taller se recorre en una sola pasada de todos modos. Una nueva operación es una corrección en el núcleo que la CLI, la TUI y el script de CI reciben todos - en un solo commit, sin desvío de versión.

Lo más importante, sin embargo, es que vulp no es un artilugio aparte junto a nuestro trabajo - es la misma capa por la que pasan tanto una mano como una automatización. Una persona hace clic, cron dispara, y hacen exactamente lo mismo, con la misma seguridad. Esa es la diferencia entre un script que funciona en casa de su autor y una herramienta en la que puedes confiar cada día.