Czy według was przechowywanie w jednym repo fronendu np. w Angularze i backendu a w zasadzie samego BFF do tego frontu ma sens?
Wtedy projekt byłby budowany i wydawany jako całość. Miałem tak w jednym projekcie. Moim zdaniem nie do końca ma to sens bo jeżeli tylko widok
by się zmienił to jakby poszedł deploy tego repo to ten BFF też by się zainstalował a w nim nie było zmian więc niepotrzebnie ale, że podbijamy wersję całości w release to musimy zainstalować. A może jest w tym jakaś wartość?
0
12
Przecież przechowywanie kodu, a releasowanie to rożne rzeczy. Fakt, że w lodówce trzymam różne produkty nie oznacza, że mam wszystkich użyć do przygotowania posiłku.
3
W jednym repo nie tylko może być front i backend, ale wiele różnych aplikacji. Monorepo vs multirepo to taki sam temat jak taby vs spacje.
0
Wtedy projekt byłby budowany i wydawany jako całość
Gdyby do tego był testowany jako całość (np. miał jakieś testy end-to-end polegające na odpaleniu backendu oraz wykorzystaniu Selenium do przetestowania frontendu), jak najbardziej :-)
3
Jeżeli nie pracujesz w modelu produktowym, gdzie jedna aplikacja = jeden team = jeden release cycle to multirepo nie ma większego sensu. Jeżeli masz frontend i backend, które tworzą razem jakiś produkt i ten produkt ma swój release cycle, ale release cycle widziany z punktu widzenia SDLC, a nie wypuszczenie hotfixa to i tak wszystko musisz zreleasować razem. Multirepo miało by może jeszcze sens gdyby w ramach waszego produktu były osobne zespoły odpowiedzialne za backend i frontend, ale raczej się już odchodzi od takich silosów, chociaż to też zależy od firmy.
W przypadku multirepo też da się sensownie testować całą aplikację/produkt, nie ma znaczenia czy znajdują się w osobnych repozytoriach. Wszystko zależy od konfiguracji środowiska i procesu deploymentu.
3
Jeden rabin powie tak, drugi inaczej. Oba podejścia mają swoje zalety i wady. Google trzyma ponoć całego Google'a w jednym repo.
4
lukascode napisał(a):
Moim zdaniem nie do końca ma to sens bo jeżeli tylko widok by się zmienił to jakby poszedł deploy tego repo to ten BFF też by się zainstalował a w nim nie było zmian więc niepotrzebnie ale, że podbijamy wersję całości w release to musimy zainstalować.
To wygląda jak osobny pod-problem pod tytułem "nasz proces deployu jest mało elastyczny i wymusza trzymanie kodu w odpowiedni sposób w repozytoriach, żeby skrypt deployujący zrozumiał". Devops bardziej chyba?
Czy według was przechowywanie w jednym repo fronendu np. w Angularze i backendu a w zasadzie samego BFF do tego frontu ma sens?
To zależy. Jak to jest robione razem przez tych samych ludzi (albo przynajmniej przez osoby z tego samego zespołu, które ze sobą mocno współpracują, nawet jeśli jeden robi frontend, drugi backend, to ciągle synchronizują swoją pracę czy korzystają ze wspólnego kodu), to więcej sensu moim zdaniem ma trzymanie tego razem.
Jeśli to jest robione oddzielnie, w izolacji, przez osoby z różnych zespołów (albo z tego samego ale bardzo niezależnie), to naturalne będzie podzielenie na różne repa, żeby to było niezależne od siebie.
2
To, ze masz projekty w jednym, bądź wielu repozytoriach nie ma znaczenia dla tego czy będziesz je wydawać razem, czy osobno. Ogólnie, to możesz mieć 2 repo i ładować je do jednego katalogu (i widzieć oba w IDE), albo mieć jedno repo i klonować tylko te katalogi, które cię interesują. Nie wiem po co i dlaczego, ale można.
Ja, osobiście robiłbym to tak, że miałbym 2 repozytoria, żeby łatwiej je klonować, zarządzać uprawnieniami, zarządzać CI/CD, w przyszłości łatwiej podmienić całość na "nowy backend", albo "nowy frontend". Jeżeli na jakimś etapie jest wymagana integracja artefaktów (np. backend ma być jednocześnie serwerem plików statycznych dla frontendu), to można to ogarnąć na etapie pajplajny: budujesz front, efekty wrzucasz do jakiegoś katalogu podczas budowania backendu, całość ładujesz na jakąś VM'kę, czy coś tam.
1
markone_dev napisał(a):
Multirepo miało by może jeszcze sens gdyby w ramach waszego produktu były osobne zespoły odpowiedzialne za backend i frontend, ale raczej się już odchodzi od takich silosów, chociaż to też zależy od firmy.
Moja obserwacja jest zupełnie inna: duże firmy idą w monorepo, bo zalety są ogromne, jeśli są tylko zasoby (a duże firmy je mają), żeby to wszystko postawić. Tak czy owak jak chce się mieć monorepo to trzeba używać narzędzi, które są zaprojektowane do działania w dużej skali. Np. googlowy Bazel wspiera gitowe sparse checkouty, ścisłe sprawdzanie drzewa zależności sprawia, że wiadomo na 100%, czy dany commit A powoduje jakiekolwiek zmiany w aplikacji B.