Wpis z mikrobloga

Jaki flow do pracy z gitem w następującym przypadku?
Mamy monorepo i to repo zawiera wiele produktów/aplikacji (mamy wspólne projekty wspóldzielone ze wszystkimi produktami, mamy wspólne projekty które są współdzielone tylko między niektórymi produktami i projekty związane tylko z konkretnym produktem).

Do pracy z gitem jest rozważany microsoftowy Release flow bo jest przyjemny i prosty. Wiązałoby się to z wprowadzeniem feature toggli.
Nie bardzo mogę znaleźć informacje jak ten flow radzi sobie z równoległym releasem wielu produktów gdzie są używane części wspólne.
Czy ktoś ma doświadczenia w tym temacie, albo może podesłać jakieś materiały? Zastanawiam się czy release flow będzie faktycznie odpowiedni do równoległych relesów.

#programowanie #git #devops
  • 19
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@LeopoldStuff: Pytanie podstawowe brzmi, czemu nie rozdzielicie tych produktów a części wspólne nie wydzielicie jako submodułów? Wiele-do-wiele-do-wiele nie brzmi jak nic pozwalającego na synchronizację wydania wielu releasów w różnych stadiach.
  • Odpowiedz
Najlepiej powydzielać aplikacje do osobnych repozytoriów, a części wspólnie także w osobnym repo (lub przy jednej aplikacji) i współdzielić przez menadżer pakietów (np. nuget dla C# lub pip dla pytona). Pozwala to na fajne wersjonowanie paczek (nie zawsze trzeba podnosić paczkę we wszystkich aplikacjach).
  • Odpowiedz
@marcin_k: tak jak powyżej napisałem, wydaję mi się że wtedy części wspólne ciężko się rozwija i jest niechęć do grzebania tam gdy za każdym razem zmiana w częściach wspólnych wiązałaby się z budowowaniem paczki gdzieś w innym repo i ściąganiem po swojej stronie
  • Odpowiedz
@LeopoldStuff: Jeżeli wiele produktów korzysta z tego samego kawałka kodu, oznacza to, że to coś powinno być albo usługą z api albo najzwyczajniej w świecie osobnym libem ze swoim repo. Sytuacja, o której piszesz jest nie do utrzymania na dłuższą metę.
  • Odpowiedz
@LeopoldStuff: po prostu robisz release branch per aplikacja i nie masz problemu. Wadą jest sytuacja, gdy masz buga w częsci wspólnej: wtedy trzeba zrobić cherry-picka z tym patchem na wszystkie afektowane branche.
  • Odpowiedz
Sytuacja, o której piszesz jest nie do utrzymania na dłuższą metę.


@sw69: większość największych korpo pracuje w takim modelu i sobie chwalą, no ale się nie da.
  • Odpowiedz
@Saly: no właśnie tak zakładałem że największym problemem to będzie odpwiednie cherrypickowanie do wielu release branchów (i oczywiście do mastera) co spowoduje że przy wielu releasach będzie można się pogubić ale to nie jest raczej duży problem.
  • Odpowiedz
@sw69: zgadzam się tu z @Saly, monorepo jest szeroko stosowane i daje największą elastycznośc ale ma też minusy. Trzeba wtedy sporo poświęcić na skrypty budujące/testujące żeby były wydajne i budowały tylko to co się zmieniło
  • Odpowiedz
@Saly: nie bardzo widzę jeden jak jeden release branch może istnieć dla wielu aplikacji releasowanych czasem wspólnie a czasem w innym terminie gdzie przez pewien okres czasu releasy będą nachodzić na siebie (ale nie będą w tym samym czasie relesowane).
  • Odpowiedz
@LeopoldStuff: Może źle się wyraziłem. W projektach, w których uczestniczyłem, Monorepo sprawdzało się tak gdzie zespół był doświadczony i wiedział o co chodzi. Kultura pracy w niektórych projektach jest jednak totalnie daleka od oczekiwań. Miałem projekty gdzie nie było żadnego code review. Każdy mógł wrzucać wszystko do mastera itp. To są realia wielu firm i to nie tylko polskich. Potem do takiej części wspólnej trafiają rzeczy, które wpływają np. na
  • Odpowiedz
Wadą jest sytuacja, gdy masz buga w częsci wspólnej: wtedy trzeba zrobić cherry-picka z tym patchem na wszystkie afektowane branche.


@Saly: Jak masz to w paczce, to poprawiasz w repo z częścią wspólną i wydajesz nową wersję paczki, po czym robisz update paczki w pozostałych repozytoriach. Dokładnie tak samo jak z bugami w paczkach zewnętrznych.

większość największych korpo pracuje w takim modelu i sobie chwalą, no ale się nie
  • Odpowiedz
@Saly: Mam jeszcze pytanie odnośnie problemu z długimi buildami.
Załóżmy że master ma gate'y czyli przy każdym PR będzie się merdżował gdzieś na boku z danym feature branchem i budował żeby sprawdzić czy wszystko ok. Problem jest taki że buildy od zera są bardzo długie bo bardzo rozległa jest aplikacja (a w zasadzie wiele aplikacji) i sporo ludzi pracuje na kodem więc bez przerwy ktoś coś będzie oddawał trigerując kolejne
  • Odpowiedz
@LeopoldStuff: ciężko raczej. W monorepo używa się specialnych systemów do budowania takich jak Bazel, które cachują absolutnie wszystko i potrafią przeanalizować co jest potrzebne do zbudowania danego targetu. Tak czy owak to bardziej pytanie odnośnie twojego systemu do budowania: czy potrafi działać tak jak chcesz
  • Odpowiedz
@Saly: niestety nie będzie to trywialne zadanie, ale generalnie z tego co piszą to taki jest właśnie koszt używania monorepo i release flow. Zobaczymy jak wyjdzie. Dzięki za odpowiedź
  • Odpowiedz