Spring GDS 25 Aniversario
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
Monorepo
¿Qué es un monorepo?
Un monorepo es un único repositorio versionado que contiene muchos proyectos: varias apps, librerías compartidas, código de infraestructura, todo en un mismo sitio con un solo historial. Es lo opuesto a una configuración polyrepo, donde cada proyecto vive en su propio repositorio, con su versionado y su ciclo de releases.
El atractivo es compartir código sin la fricción. Cuando un frontend, un backend y tres paquetes compartidos conviven, un cambio que los toca todos cabe en un único commit atómico, con un solo set de pruebas, contra una versión consistente de cada dependencia. Nada de publicar un paquete interno y esperar a que los repos dependientes se actualicen. El coste es el tooling: un monorepo ingenuo reconstruye y vuelve a probar todo en cada cambio, así que se apoya en sistemas de build como Turborepo, Nx o Bazel que entienden el grafo de dependencias y solo tocan lo que de verdad ha cambiado. Una empresa con una web app, una app móvil y una API que comparten los mismos tipos y la misma lógica de validación los mantiene sincronizados en un monorepo, de modo que un cambio en un tipo compartido rompe la build al instante en vez de en producción semanas después.
Google, Meta y muchos equipos de producto modernos trabajan con monorepos. El patrón escala, pero solo con el build y el CI adecuados por debajo.
Monorepos en Dallonses
Usamos monorepos en proyectos donde varias apps comparten código de verdad, porque la alternativa es un goteo lento de bugs por versiones desalineadas que nadie disfruta persiguiendo. Tipos compartidos detectados en tiempo de build, una sola pull request que toca frontend y backend a la vez, una única fuente de verdad para las dependencias. La estructura se paga sola la primera vez que un cambio rompedor aparece en CI en vez de en manos de un cliente.
La disciplina está en el tooling, no en la disposición de carpetas. Un monorepo sin caché inteligente y builds selectivas convierte cada commit en una ejecución de CI de veinte minutos, que los equipos empiezan a saltarse en silencio. Configuramos el grafo de dependencias para que los pipelines solo construyan y prueben lo que ha cambiado, y ahí es donde este trabajo se cruza con nuestra práctica de pipelines CI/CD y estandarización de plataformas. El repo se mantiene rápido, y rápido es lo que hace que la gente siga pasando las validaciones.
¿Haciendo malabares con varios repos que no paran de descoordinarse? Un monorepo podría ser la solución. Hablemos.
Servicios relacionados
Trabajos relacionados
Vizitio
Convertir una marca en un negocio que funciona.
Access Ticket
Medio millón de personas. Una app. Cero caos.
¿Listo para trabajar juntos?
Reservar una reunión
