Monorepo w małej firmie: oszczędność czy klątwa?
Kiedy słyszę „monorepo” od founderów małych firm, od razu czuję mieszane uczucia. Z jednej strony – kusząca obietnica prostoty: jeden repo, jedna historia commitów, łatwe udostępnianie kodu. Z drugiej – widzę projekty, które po roku toną w zależnościach, a każde wdrożenie zamienia się w rosyjską ruletkę. Czy monorepo ma sens dla małego zespołu? Odpowiedź nie jest czarno-biała.
1. Złudzenie prostoty
Większość zespołów przechodzi na monorepo, bo wierzy, że to uprości zarządzanie. Rzeczywistość? Prawidłowo skonfigurowane monorepo wymaga narzędzi takich jak Nx, Turborepo czy Bazel. Bez nich – zaczyna się chaos. Przykład: klient, startup z 5 developerami, postanowił zebrać wszystkie mikroserwisy w jednym repo. Po trzech miesiącach każda zmiana w bibliotece shared powodowała łańcuchową reakcję – developerzy musieli czekać godzinami na CI, a konflikty merge’ów były codziennością.
Monorepo nie jest magicznym rozwiązaniem. To architektura, która wymaga dyscypliny. Jeśli Twój zespół nie ma doświadczenia z monorepo tools, rozważ start z rozwiązaniami typu „multi-repo z pakiet managerem” (np. Lerna) lub hybrydą.
2. Wydajność CI/CD – cichy zabójca budżetu
Monorepo w małej firmie często oznacza, że każdy commit uruchamia testy dla całego projektu. To drogie. Klient z branży e-commerce – 4 developerów, 3 aplikacje w monorepo – płacił za GitHub Actions 2x więcej niż z oddzielnymi repozytoriami. Dopiero wdrożenie inteligentnego cachowania (Turborepo) i selektywnego uruchamiania testów zmniejszyło koszty o 40%.
Wniosek: monorepo bez odpowiedniej optymalizacji CI to prosta droga do przepalania budżetu. Jeśli nie możesz poświęcić czasu na konfigurację narzędzi, lepiej zostań przy multi-repo.
3. Zależności – gdy współdzielenie boli
Współdzielenie kodu między projektami to główna zaleta monorepo. Ale tylko jeśli robisz to z głową. Widziałem firmę, która wrzuciła wszystkie biblioteki do jednego folderu shared – bez wersjonowania. Efekt: każda zmiana w shared wymuszała aktualizację u wszystkich konsumentów, często z break change’ami. To nie jest oszczędność, to dług techniczny.
Rozwiązanie? Każda biblioteka w monorepo powinna mieć własny package.json i semver. Używaj narzędzi do zarządzania zależnościami (np. Changesets). A przede wszystkim – zadaj sobie pytanie: czy te projekty naprawdę potrzebują współdzielić kod? Czasem lepiej skopiować 100 linijek niż stworzyć zależność, która będzie ciążyć przez lata.
Kiedy monorepo ma sens?
Nie zawsze jest złe. Monorepo sprawdza się, gdy:
- Masz mały zespół (2-5 osób) i wszystkie projekty są ze sobą ściśle powiązane (np. frontend + backend + biblioteka UI).
- Używasz narzędzi takich jak Nx, które automatyzują CI i dependencje.
- Macie doświadczenie z monorepo i dyscyplinę code review.
Jeśli natomiast dopiero zaczynacie, macie rozproszone zespoły lub projekty o niskiej współzależności – startujcie z multi-repo. Przynajmniej do czasu, aż poznacie własne potrzeby.
Podsumowanie
Monorepo to potężne narzędzie, ale dla małej firmy może być zarówno oszczędnością, jak i klątwą. Kluczem jest świadomość kosztów – nie tylko tych finansowych, ale też czasu zespołu i inwestycji w narzędzia. Zanim podejmiesz decyzję, przetestuj na małym projekcie. A jeśli potrzebujesz wsparcia w optymalizacji architektury – JurskiTech chętnie pomoże uniknąć typowych pułapek.
Monorepo to decyzja strategiczna. Nie daj się skusić pozornej prostocie.
