Spring GDS 25è Aniversari
Una empresa de logística que envia a 190 països va construir alguna cosa per enviar-se a si mateixa.
Un monorepo és un únic repositori versionat que conté molts projectes: diverses apps, llibreries compartides, codi d'infraestructura, tot en un mateix lloc amb un sol historial. És l'oposat d'una configuració polyrepo, on cada projecte viu al seu propi repositori, amb el seu versionat i el seu cicle de releases.
L'atractiu és compartir codi sense la fricció. Quan un frontend, un backend i tres paquets compartits conviuen, un canvi que els toca tots cap en un únic commit atòmic, amb un sol conjunt de proves, contra una versió consistent de cada dependència. Res de publicar un paquet intern i esperar que els repos dependents s'actualitzin. El cost és el tooling: un monorepo ingenu reconstrueix i torna a provar-ho tot a cada canvi, així que es recolza en sistemes de build com Turborepo, Nx o Bazel que entenen el graf de dependències i només toquen el que de debò ha canviat. Una empresa amb una web app, una app mòbil i una API que comparteixen els mateixos tipus i la mateixa lògica de validació els manté sincronitzats en un monorepo, de manera que un canvi en un tipus compartit trenca la build a l'instant en lloc de fer-ho en producció setmanes després.
Google, Meta i molts equips de producte moderns treballen amb monorepos. El patró escala, però només amb el build i el CI adequats per sota.
Fem servir monorepos en projectes on diverses apps comparteixen codi de debò, perquè l'alternativa és un degoteig lent de bugs per versions desalineades que ningú gaudeix perseguint. Tipus compartits detectats en temps de build, una sola pull request que toca frontend i backend alhora, una única font de veritat per a les dependències. L'estructura es paga sola el primer cop que un canvi trencador apareix a CI en lloc de fer-ho a les mans d'un client.
La disciplina és al tooling, no a la disposició de carpetes. Un monorepo sense caché intel·ligent i builds selectives converteix cada commit en una execució de CI de vint minuts, que els equips comencen a saltar-se en silenci. Configurem el graf de dependències perquè els pipelines només construeixin i provin el que ha canviat, i aquí és on aquesta feina es creua amb la nostra pràctica de pipelines CI/CD i estandardització de plataformes. El repo es manté ràpid, i ràpid és el que fa que la gent segueixi passant les validacions.
Fent malabars amb diversos repos que no paren de descoordinar-se? Un monorepo podria ser la solució. Parlem-ne.
Una empresa de logística que envia a 190 països va construir alguna cosa per enviar-se a si mateixa.
Convertir una marca en un negoci que funciona.
Mig milió de persones. Una app. Zero caos.















