Tooling de desarrollo
Un CLI por el que despliega todo el equipo
Un comando que hace que un despliegue sea seguro, y que de paso deja los mismos estándares en todos los repositorios.
- Rol
- Autor y responsable
iniciativa propia - Construido con
- Node.js, TypeScript
internals de git, APIs - Lo usa
- El equipo de ingeniería
en cada proyecto de cliente - Estado
- En mantenimiento activo
versionado y documentado
Por qué existe
Dos problemas, y los dos merecían resolverse una vez en lugar de cada semana.
Ninguno parecía un problema desde fuera. Nada estaba roto, nada estaba ardiendo, y los dos tenían un apaño que una persona cuidadosa podía llevar en la cabeza. Eso es justo lo que los hacía caros: el coste estaba repartido en fino entre cada semana y cada persona, así que nunca llegaba como algo que arreglar, solo como algo con lo que tener cuidado.
El primero es que un proyecto puede tener dos dueños escribiendo en el mismo árbol de archivos. Los desarrolladores son dueños del código, mientras otra persona, un cliente o alguien de QA, es dueña de la configuración que edita desde un editor en vivo, y git solo tuvo copia de una de las dos. Despliega una rama por encima y la mitad que no es tuya desaparece, en silencio. Todo el mundo conocía la regla. Estaba escrita. Igualmente salía mal, porque saber una regla y acordarse de ella un viernes a las seis son cosas distintas. Así que sincronizar necesitaba a un desarrollador senior mirando, lo que significaba esperar a que hubiera uno.
El segundo es la consistencia. A lo largo de muchos proyectos de cliente, las convenciones se desvían: estructuras de carpetas distintas, patrones distintos, reglas de IA distintas, un resultado distinto según quién cogiera el trabajo. La revisión de código lo acaba pillando, que es un sitio lento y caro donde pillarlo.
Empecé a construir esto por iniciativa propia para arreglar los dos, porque resultaron ser el mismo problema: lo que se supone que el equipo tiene que recordar debería ser algo que la herramienta ya hace.
La mayor parte del trabajo no fue el código. Fue mirar dónde se iba realmente el tiempo, separar la parte que de verdad cambiaba de un cliente a otro de la parte que reconstruíamos siempre, y decidir qué debía negarse a hacer la herramienta en lugar de solo qué debía facilitar. Escribir los comandos después fue la parte corta.
Nada de esto es específico de una plataforma. La forma del problema, dos dueños escribiendo en un mismo árbol y convenciones que se separan entre proyectos, aparece en cualquier equipo que lleve más de un puñado de repositorios.
$oma sync-preview
Fetching themes...
Sync changes to "OMA | Northbeam | Preview"? yes
Checking git status...
Git repository is clean
Creating preview theme backup...
Committed all theme changes
Tagged qa-preview-backup/2026-09-21T14-53-02
Full theme state preserved in git history
Committing JSON changes...
Committed JSON changes
Comparing local files with preview theme...
Compared with preview theme
$oma sync-preview -t 124906102
Fetching theme info...
Live theme: Northbeam Production
Type the theme ID to continue:
Aborted. Live theme left untouched.
$oma rules sync
CLAUDE.md managed block updated
skills/oma-shopify-theme synced
skills/oma-nextjs synced
agents 4 definitions
Project notes left untouched
Una única fuente de verdad, que viaja con
la herramienta en vez de recordarse.
Qué garantiza
Nada sobrescribe lo que no le pertenece
Lo que editó otra persona va en un sentido, el código va en el otro. La herramienta no hace la escritura que cruza esa línea, se lo pidas como se lo pidas.Siempre hay vuelta atrás
El estado remoto se commitea y se etiqueta antes de escribir nada, así que la versión que existía antes de un sync se queda en el historial de git y se puede devolver con un solo comando.Las convenciones llegan con la herramienta
Cada cliente es su propia cosa, así que no hay dos proyectos iguales. Lo que no hace falta reinventar cada vez es la base compartida: los patrones, la estructura y el scaffolding se instalan en lugar de copiarse del repositorio que alguien tuviera abierto por última vez.Las reglas de IA viajan con ella
Nuestros estándares de código y las definiciones de agentes se distribuyen a cada repositorio desde una única fuente de verdad, así que la asistencia de IA de todo el mundo sigue las mismas convenciones y el resultado se mantiene consistente en todo el equipo.
Por qué esto importa en un equipo
Nadie me pidió que construyera esto. Vi el mismo problema repitiéndose, y que el coste lo pagaba siempre quien era más senior y menos disponible.
Esa es la parte que merece la pena saber de mí. Voy a notar aquello que el equipo lleva tiempo esquivando, y voy a ir a arreglarlo bien en lugar de volverme mejor esquivándolo. Significa que un desarrollador junior puede desplegar sin supervisión, que un proyecto nuevo es consistente desde el primer día, y que la gente senior recupera sus tardes.
También significa que estoy cómodo siendo responsable de algo de principio a fin y siguiendo siéndolo después: diseñarlo, construirlo, versionarlo, documentarlo, y mantenerlo funcionando mientras otras personas dependen de ello cada día. Construirlo llevó semanas. Mantenerlo es continuo, y esa es la parte que decide si una herramienta así sobrevive al contacto con un equipo real.