La gestió de repositoris de codi és una decisió arquitectònica que va més enllà de l'organització de fitxers: defineix com col·laboren els equips, com evolucionen els productes i com s'escalen les operacions tecnològiques. Després d'anys treballant en entorns tan diferents com el monorepo massiu de Meta i el polirepo descentralitzat d'AWS, he arribat a una conclusió que reformula el debat: l'elecció entre monorepo i polirepo no és d'enginyeria, sinó organitzativa. A Q2BSTUDIO, on desenvolupem aplicacions a mida i solucions cloud, vivim aquesta tensió diàriament. Aquest article explora les lliçons apreses als dos extrems i com una migració de 15 repositoris a un de sol va transformar la nostra manera de treballar.
A Meta, el monorepo —un únic repositori Mercurial amb milers de milions de línies de codi— permetia canvis atòmics. Un sol commit podia modificar el frontend d'iOS, el backend en Hack i les eines internes. La visibilitat total del codi facilitava refactoritzacions massives: qualsevol desenvolupador podia trobar totes les referències a una funció i actualitzar-les sense dependre d'equips externs. No obstant, l'onboarding requeria descarregar gigabytes, les cerques eren lentes sense eines pròpies i la conflictivitat en fitxers calents era constant. El problema del codi mort es feia evident: en eliminar un projecte legacy, vaig descobrir que una funció de conversió hexadecimal tenia més de 200 referències creuades entre equips. El monorepo obliga a assumir la responsabilitat de no trencar dependències alienes, però almenys pots veure exactament l'impacte.
A AWS, la filosofia era oposada: cada servei vivia al seu propi repositori, amb pipelines independents i ownership clar. L'autonomia permetia triar tecnologies dispars (Java, Python, Go) i escalar sense coordinació central. Però la visibilitat era terrible. Per descobrir com un altre equip resolia un patró d'infraestructura, calia usar el cercador intern i assumir que el codi estava desactualitzat. La duplicació era endèmica: el mateix component CDK es reescrivia dotzenes de vegades. Les reparacions de seguretat es convertien en malsons: un pegat en una llibreria compartida requeria alliberar una nova versió, obrir PRs a desenes de repositoris consumidors i esperar que tots actualitzessin. La coordinació entre repositoris era costosa i propensa a errors.
La migració que va transformar la nostra perspectiva va ocórrer en un cap de setmana. Teníem 15 serveis en repositoris separats: autenticació, facturació, calendari, notificacions, etc. La gota que va fer vessar el got va ser un canvi de permisos a nivell d'organització que necessitava coordinació en 9 repositoris. Dues setmanes de treball per a una modificació que hauria d'haver estat trivial. Vam decidir unificar-ho tot en un monorepo. El dissabte al matí vam planificar l'estructura: '/services/' per a cada servei, '/pkg/' per a codi Go compartit, '/packages/' per a TypeScript, '/db/' per a models de base de dades com a font única de veritat. A la tarda vam clonar cada repositori antic a la seva carpeta corresponent. La part dura va ser consolidar el codi compartit: teníem 8 còpies del model d'usuari, 5 del middleware d'autenticació, 3 del client de Stripe. Vam comparar versions, vam triar la més completa i vam afegir les funcionalitats que faltaven.
El diumenge vam configurar el CI/CD amb detecció de canvis. Abans, 15 fluxos de treball de GitHub Actions sumaven 3.200 línies de configuració. Ara, un sol workflow detecta quins serveis s'han modificat i executa només els seus tests. Si es canvia '/db/', es prova tot. El desplegament es va simplificar: serveis com Cloud Run, Cloud Functions i frontends coexistien al mateix repositori. Per gestionar-los amb una sola eina, vam crear Pilum, un orquestrador open-source de desplegament multi-cloud. El diumenge al vespre van aparèixer errors típics: una dependència circular amagada pel versionat en polirepo, importacions trencades i migracions de base de dades conflictives. Els vam resoldre i verificar. El resultat: 24 hores de treball que van reduir el temps de desplegament de tots els serveis un 82%, els PRs per a canvis transversals un 90% i el temps d'incorporació de nous desenvolupadors de 2 dies a 4 hores.
Els beneficis quantitatius van ser contundents, però les lliçons qualitatives són més profundes. El monorepo força l'estandardització sense necessitat de governança explícita: en tenir un únic model d'usuari, tots els serveis importen la mateixa definició. Els errors de version skew desapareixen. La seguretat millora perquè un pegat s'aplica atòmicament. No obstant, no és una bala de plata. En organitzacions amb unitats de negoci genuïnament independents —com Amazon amb AWS, Retail i Prime Video— el polirepo té sentit perquè l'aïllament organitzatiu justifica el cost de la coordinació. A startups i equips de fins a 50 enginyers, el monorepo redueix la fricció i accelera la iteració.
El patró que observem a la indústria és revelador: Google, Meta, Microsoft, Stripe i Uber operen amb monorepos. Amazon, Netflix i Spotify amb polirepos. Tots dos models funcionen; la diferència és l'estructura organitzativa, no l'enginyeria. La llei de Conway es compleix: l'arquitectura del sistema reflecteix la comunicació de l'equip. Si el teu equip necessita coordinació constant, el monorepo és més eficient. Si necessites aïllament regulatori (per exemple, un servei amb dades HIPAA davant d'un lloc de màrqueting), el polirepo pot ser necessari.
A Q2BSTUDIO, apliquem aquestes lliçons quan ajudem els nostres clients a migrar al núvol o a modernitzar les seves arquitectures. Oferim serveis cloud a AWS i Azure, integrant monitorització, seguretat i escalabilitat. Per a un client del sector financer, vam migrar 30 microserveis des d'un polirepo caòtic a un monorepo amb Bazel, reduint les fallades d'integració en un 70%. Un altre client, una startup de healthtech, necessitava complir amb normatives de protecció de dades; vam dissenyar un monorepo amb forts boundaries d'ownership mitjançant CODEOWNERS, mantenint la flexibilitat de desplegaments independents. La clau és entendre que l'estructura del repositori no és un dogma, sinó una eina al servei de l'organització.
El camí d'evolució recomanat: de 0 a 10 enginyers, un monòlit o 2-3 serveis en monorepo n'hi ha prou. De 10 a 50, els límits naturals de servei emergeixen; el monorepo manté baixos els costos de coordinació. De 50 a 200, el disseny domain-driven i els CODEOWNERS sòlids eviten el caos. A partir de 200, es pot considerar el polirepo per a unitats realment autònomes, però com demostra Google, no és necessari. L'error comú és tractar l'arquitectura de 200+ com a punt de partida. Els microserveis prematurs són optimització prematura.
El futur apunta a eines que automatitzin la gestió de monorepos: canvis atòmics, proves intel·ligents i desplegaments progressius. A Q2BSTUDIO també treballem amb intel·ligència artificial per analitzar dependències i suggerir refactoritzacions. La IA aplicada a repositoris pot detectar codi mort, recomanar extraccions i predir l'impacte de canvis. A més, integrem BI amb Power BI per mesurar la salut del codi i la productivitat de l'equip. La ciberseguretat és un altre pilar: als nostres serveis de pentesting assegurem que els repositoris no exposin secrets o vulnerabilitats. I els agents d'IA que desenvolupem automatitzen tasques repetitives com la revisió de PRs o la generació de documentació.
En definitiva, la gestió de monorepos a escala és un equilibri entre visibilitat i control, velocitat i autonomia. El que vaig aprendre a Meta i AWS, i que vaig confirmar a la nostra migració, és que no existeix una resposta universal. Cada organització ha d'avaluar la seva mida, cultura i necessitats de negoci. Si el teu equip gasta més d'unes hores setmanals en gestió de dependències o en coordinar llançaments múltiples, val la pena considerar el monorepo. I si decideixes fer el pas, fes-ho amb planificació, mesurant abans i després, i recolzant-te en eines modernes de CI/CD i ownership. A Q2BSTUDIO estem preparats per acompanyar-te en aquest viatge, combinant experiència tècnica amb un enfocament pràctic i orientat a resultats.
