Cześć Mirki/MIrabelki, jak zarządzacie projektami w gitcie? Jak radzicie sobie z różnymi apkami które składają się w 95% z tego samego kodu, ale których core chcecie równolegle rozwijać?
Dołączyłem kilka lat temu do ekipy która miała swój produkt (dla uproszczenia nazwijmy go eshopem - nie jest nim, ale powiedzmy, że łatwiej będzie mi przekazać o co mi chodzi na konkretnym przypadku). Produkt ten składa się z kilku modułów (powiedzmy koszyk, widok produktów, jakiś tam analizator sprzedaży, cokolwiek). Przez wiele lat było dwóch głównych klientów, utworzono dla każdego osobne repo (1 repo = 1 aplikacja). Klienci szli w miarę równo do przodu, jakoś ogarnialiśmy subtelne różnice między poszczególnymi modułami w ich aplikacjach (zwłaszcza, że to była ta sama branża i często razem prosili o takie same zmiany/funkcjonalności). Minęło kilka lat pojawiło się więcej klientów i jest coraz więcej customizacji. Ten chce słodkie kotki w menu, drugi woli coś innego, trzeci mówi że ten moduł jest w złych kolorach, a czwarty ma za dużo filtrów. Coraz bardziej się wszystko rozjeżdża, chociaż 95% kodu jest taka sama. Ale coraz trudniej nam to ogarnąć i sklejać w jedno. Dochodzimy już do tego że za chwilę przestaniemy ogarniać co się dzieje i nie zawsze idziemy z naszymi klientami równo. Na tą chwilę zastanawiamy się jak to ogarnąć po stronie gita i kontroli naszych zmian, czy nie lepszą opcją byłoby przejść na submodules pod moduły naszej apki. Czyli zrobić osobne repa na każdego klienta, w środku jako submodules różne moduły na różnych branchach dla danego klienta i jakoś tak to ogarnąć? Rozwijalibyśmy mastera każdego modułu jako core, a potem robili merge mastera do brancha pod konkretnego klienta. Nie wiem czy to jest dobry pomysł;/ Macie jakieś pomysły/propozycje, jak to ogarniacie u siebie? #git #devops #programowanie #zarzadzanieprojektami
czy nie lepszą opcją byłoby przejść na submodules pod moduły naszej apki.
@UrimTumim: submodules dla kodu rozwijanego równocześnie to zło. W skrócie łączysz wszystkie wady stosowania monorepo i odzielnnych repo dla kodu wspólnego nie zyskując nic w zamian
w środku jako submodules różne moduły na różnych branchach dla danego klienta i jakoś tak to ogarnąć?
@UrimTumim: nie używaj branchów w taki sposób, to tylko pogarsza sprawę. Im więcej dziwnych branchy
@UrimTumim: dostałeś fajne odpowiedzi już. W jednej firmie z którą pracowałem utrzymywali każda fanaberie klientów jako feature flagi i trzymali ich mnóstwo, a potem testowali konkretne kombinacje.
Weszliście we wsparcie klienta z szyciem softu na miarę, nie jest to lekki kawałek chleba. Na hacker news było w tamtym roku dużo wątków o tym. Jedni załamywali się i pisali np nowa wersje softu niekompatybilna wstecz i czekali aż klienci przejdą albo się
#p0lka Mulat, student, pracujący, aktywny, i nie karzeł 180 tylko minimum 183 to ma z czym startować do pięknej, niewysokiej acz stawiającej warunki p0lki.
jak zarządzacie projektami w gitcie? Jak radzicie sobie z różnymi apkami które składają się w 95% z tego samego kodu, ale których core chcecie równolegle rozwijać?
Dołączyłem kilka lat temu do ekipy która miała swój produkt (dla uproszczenia nazwijmy go eshopem - nie jest nim, ale powiedzmy, że łatwiej będzie mi przekazać o co mi chodzi na konkretnym przypadku).
Produkt ten składa się z kilku modułów (powiedzmy koszyk, widok produktów, jakiś tam analizator sprzedaży, cokolwiek).
Przez wiele lat było dwóch głównych klientów, utworzono dla każdego osobne repo (1 repo = 1 aplikacja). Klienci szli w miarę równo do przodu, jakoś ogarnialiśmy subtelne różnice między poszczególnymi modułami w ich aplikacjach (zwłaszcza, że to była ta sama branża i często razem prosili o takie same zmiany/funkcjonalności).
Minęło kilka lat pojawiło się więcej klientów i jest coraz więcej customizacji. Ten chce słodkie kotki w menu, drugi woli coś innego, trzeci mówi że ten moduł jest w złych kolorach, a czwarty ma za dużo filtrów. Coraz bardziej się wszystko rozjeżdża, chociaż 95% kodu jest taka sama.
Ale coraz trudniej nam to ogarnąć i sklejać w jedno. Dochodzimy już do tego że za chwilę przestaniemy ogarniać co się dzieje i nie zawsze idziemy z naszymi klientami równo.
Na tą chwilę zastanawiamy się jak to ogarnąć po stronie gita i kontroli naszych zmian, czy nie lepszą opcją byłoby przejść na submodules pod moduły naszej apki. Czyli zrobić osobne repa na każdego klienta, w środku jako submodules różne moduły na różnych branchach dla danego klienta i jakoś tak to ogarnąć?
Rozwijalibyśmy mastera każdego modułu jako core, a potem robili merge mastera do brancha pod konkretnego klienta.
Nie wiem czy to jest dobry pomysł;/ Macie jakieś pomysły/propozycje, jak to ogarniacie u siebie?
#git #devops #programowanie #zarzadzanieprojektami
Komentarz usunięty przez autora
@UrimTumim: submodules dla kodu rozwijanego równocześnie to zło. W skrócie łączysz wszystkie wady stosowania monorepo i odzielnnych repo dla kodu wspólnego nie zyskując nic w zamian
@UrimTumim: nie używaj branchów w taki sposób, to tylko pogarsza sprawę. Im więcej dziwnych branchy
Weszliście we wsparcie klienta z szyciem softu na miarę, nie jest to lekki kawałek chleba. Na hacker news było w tamtym roku dużo wątków o tym. Jedni załamywali się i pisali np nowa wersje softu niekompatybilna wstecz i czekali aż klienci przejdą albo się