Odluka o tome hoće li kod živjeti u jednom velikom repozitoriju ili biti razbijen na desetke manjih zna izgledati kao tehnički detalj, no dugoročno oblikuje brzinu razvoja, CI/CD troškove i način na koji timovi surađuju.

Što je monorepo

Monorepo znači da sav kod — frontend, backend, zajedničke biblioteke, možda čak i mobilna aplikacija — živi u jednom Git repozitoriju. Google, Meta i Google su poznati primjeri kompanija koje na ovaj način drže milijune datoteka u jednom stablu. Ne treba ga miješati s monolitom — monorepo je organizacija koda, monolit je arhitektura aplikacije; unutar monorepa mirno mogu živjeti potpuno odvojeni mikroservisi.

Što je multi-repo (polyrepo)

Suprotan pristup je da svaki servis, biblioteka ili aplikacija ima svoj repozitorij, svoj životni ciklus verzioniranja i svoj CI pipeline. Ovo je dugo bio defaultni pristup, posebno u mikroservisnim arhitekturama gdje svaki tim "vlasnik" svog repozitorija.

Prednosti monorepo pristupa

  • Atomske promjene — izmjena koja dira i backend i frontend (npr. promjena API kontrakta) ide u jednom commitu i jednom PR-u, umjesto koordinacije preko više repozitorija i verzija.
  • Dijeljenje koda bez publiciranja paketa — zajednička biblioteka se importira izravno, bez potrebe za internim npm registryjem i version bumpanjem kod svake sitne promjene.
  • Jedna istina o stanju koda — lakše je vidjeti cijelu sliku, refaktorirati preko granica servisa i provoditi konzistentne standarde (linting, testing) alatima poput ESLinta ili Prettiera na cijelom kodu odjednom.
  • Jednostavnije onboardanje — novi developer klonira jedan repozitorij, ne mora znati koji od petnaest repozitorija mu treba za koji zadatak.

Mane monorepo pristupa

  • CI/CD zna postati spor ako se ne koriste alati za inkrementalno buildanje — build cijelog stabla za promjenu jedne datoteke je neodrživo na većim projektima.
  • Git operacije (clone, checkout, blame) usporavaju se s veličinom repozitorija bez dodatnih alata (Git LFS, sparse checkout, virtualiziranih file sustava poput onih koje koristi Microsoft za Windows repo).
  • Pristupne kontrole su grublje — teže je nekom timu dati pristup samo dijelu koda ako alat to izričito ne podržava.

Prednosti multi-repo pristupa

  • Jasne granice vlasništva — tim potpuno kontrolira svoj repozitorij, svoj release ciklus, svoje CI pipeline bez utjecaja na druge timove.
  • Manji repozitoriji, brže Git operacije bez dodatnih alata.
  • Lakše je različitim servisima koristiti različite tehnologije i verzije ovisnosti bez sukoba.

Alati koji rješavaju monorepo skalabilnost

Ono što je nekad monorepo činilo nepraktičnim za manje timove danas rješavaju specijalizirani alati: Nx i Turborepo za JavaScript/TypeScript ekosustave donose inkrementalno buildanje i keširanje na razini pojedinog paketa, dok Bazel (Google) i Buck2 (Meta) rade isto na jeziku-agnostičan način za velike organizacije. Ovi alati grade graf ovisnosti između paketa i pokreću samo one buildove i testove na koje je konkretna promjena stvarno utjecala.

Kako odlučiti

Monorepo se isplati kad: tim je relativno mali do srednji, kod se često dijeli između servisa, a atomske promjene preko granica su čest slučaj. Multi-repo ima smisla kad: organizacija je velika s mnogo neovisnih timova, servisi imaju potpuno različite tehnološke stackove i release cikluse, ili je regulatorni/sigurnosni zahtjev strogo odvojiti pristup kodu po timovima.

Zaključak

Ne postoji univerzalno ispravan odgovor — Google i Meta koriste monorepo na ekstremnoj skali, dok Netflix i Amazon dugo promoviraju multi-repo mikroservisni pristup. Bitnije od same odluke je da tim razumije kompromise koje bira i da uloži u alate (CI keširanje, jasna vlasništva, dokumentacija) koji ublažavaju mane odabranog pristupa.