Sunt curios de parere celor activi pe forum legat de subiectul de mai sus.
Pentru proiectele in care incarcati dependintele proprii (module scrise de voi care pot functiona de sine statator) preferati sa folositi repo-uri separate pentru fiecare din ele sau sa fie totul intr-un singur mare repository cu proiectul principal?
Repo pentru fiecare modul cat mai granular, toate modulele se incarca la initializarea proiectului
Repo unic pentru proiect si modulele dependente (doar interne, cele externe se incarca ca de obicei)
Repo unic cu toate dependintele (externe si interne)
Tocmai de cateva zile s-a terminat migrarea spre monorepo a unui produs la care fac acum consultanta. Ratiunea este o mai suoara scriere a testelor de integrare, precum si o rulare full-stack pe computerul fiecarui developer. De asemenea, f important este si faptul ca se simplifica f mult modul in care se lucreaza la un feature care atinge mai multe module, pentru ca se pregateste un singur pull-request. Daca va intereseaza, am facut “din topor” un mic cod python care te ajuta sa migrezi la monorepo pastrand istoria tuturor celorlalte proiecte. Si Symfony se scrie pe monorepo, iar la tag de relese se impinge pe repo-urile de componente care sunt read-only.
Bun topic. Lunga discutia. Fiecaruia i se potriveste altceva.
Am lucrat o buna bucata de vreme pe un mono-repo mare. Am ramas cu o impresie buna despre treaba asta, dar iti trebuie si un tooling pe masura, cel putin intr-o firma mare.
OTOH, pare ca toata lumea open-source si in general modern development s-a orientat spre separate repos. De exemplu. majoritatea limbajelor de programare considera un pachet echivalent cu un repository. Majoritatea toolurilor de build/CI/deploy, cat si platforme PaaS precium Heroku, GAE etc au ideea ca un repository este o singura aplicatie si o singura unitate de deployment. Fireste, poti sa configurezi si sa faci in asa fel incat sa nu fie asta o problema, dar e peste mana, la un moment-dat.
O alta mare problema era ca era foarte usor sa ai dependinte de cod “intern” al unei alte componente.
Exact, de aceea Fabien foloseste la Symfony un monorepo pe care il taguieste cu un release number, dupa care are un tool de linie de comanda care merge si impinge codul din componentele individuale in repo-urile proprii. Acestea sunt folosite independent de o gramada de oameni. Uite cum toate single-repo sunt marcate ca [READ-ONLY] aici. E modul lor a atinge un common ground intre separate repos and monorepos.
La exemplul pe care l-am dat cu echipa pe care o ajut acum, ei nu au avut nevoie sa faca asta, fiind putine repos.
Problema de care ma lovesc tot timpul e cu dependintele intre componente individuale si code review + integrare in acest caz. Cu repo-uri individuale e criminal sa faci asa ceva la monorepo ai un singur branch/PR unde vezi modificarile peste toate modulele.
Ce vroiam sa spun este ca inca nu am intalnit proiect unde repo-uri separate ar fi utile cu toate ca acestea sunt prezentate ca si best practice.
Sunt cateva motive pt atomicizarea pe repo individuale, insa cele mai multe se refera la distributia de module. Adica atunci cand eu folosesc un 3rd party e bine sa il pot aduce doar pe acela, nu tot frameworkul sau ce o mai fi. De asemenea, pt a-mi impacheta codul, vreau acele 3rd party, dar daca e posibil fara folderul de docs si teste.
Sunt cateva dezavantaje si la monorepo. Sa ne gandim putin la toate asseturile care le avem intr-o combinatie de multe aplicatii, o parte din ele duplicate. Cu cat am mai multe fisiere mari pe disk, cu atat mai lent imi va fi lucrul cu git. Adica fac un git clone la monorepo si merg la sala sa bag o alergare pana se termina (vorbim de proiecte multe si maricele). Aici se poate lucra la rescrierea istoriei in asa fel incat nu avem chiar toate metadatele de git. Remember, daca am urcat din greseala ca tester niste samples de 100 mega si pe urma le sterg, nenea Linus tot tine cont ca a fost acolo (dar imi da scule cu care sa sterg urmele).