Git - dwie gałęzie master vs dodatkowe repozytorium

Witam,

Założenia:

• projekt posiada dwie wersje językowe
• każda z wersji jest instalowana na osobnym serwerze
• główne różnice pomiędzy wersjami będą widoczne w bazie danych
• w samym kodzie rozbieżność będzie stanowić głównie przełączanie się pomiędzy modułami (np. moduł X włączony dla wersji polskiej, dla wersji angielskiej wyłączony)
• może się trafić przypadek dodatkowej funkcjonalności tylko dla określonej wersji
• wersje są spójne pod względem wersji użytej aplikacji

Rozwiązania:

• 2x branch master (np. master_pl i master_en),
• osobne repo pod daną wersję językową

Prościej by mi było ogarniać to w obrębie jednego projektu.
Przełączałbym się jedynie pomiędzy bazami danych i branchami.
Proszę o poradę czy taki model jest akceptowalny (posiadanie więcej niż jednej, głównej gałęzi w repozytorium)?

nie wystarczy dobra konfiguracja i odpalanie aplikacji w trybie pl/en? ._.

Feature toggle + odpowiednia konfiguracja = jedno repo. Osobne repo to dramat, osobne branche to ból jak będzie jakiś rozjazd i trzeba będzie poświęcać sporo czasu na migrowanie featurów pomiędzy tymi wersjami.

Zdecydowanie -- jeden master, jedno repozytorium, jeden projekt, dwie wersje językowe z odpowiednią (dość prostą -- z tego, co piszesz) konfiguracją...

baant napisał(a):

nie wystarczy dobra konfiguracja i odpalanie aplikacji w trybie pl/en? ._.

To wymóg klienta żeby osobna wersja była na oddzielnym serwerze.
Klient wie, że istnieje taka możliwość żeby skonfigurować na jednym serwerze kilka wersji językowych aplikacji ale z pewnych względów nie chcemy tego tak ustawiać (ograniczenia uprawnień użytkowników panelu administracyjnego do konkretnej wersji językowej).

Shalom napisał(a):

Feature toggle + odpowiednia konfiguracja = jedno repo. Osobne repo to dramat, osobne branche to ból jak będzie jakiś rozjazd i trzeba będzie poświęcać sporo czasu na migrowanie featurów pomiędzy tymi wersjami.

Bardziej ten kierunek, na razie pewnie będzie jeden master wpięty do obu serwisów.
W przyszłości jeśli zajdzie potrzeba będę wydzielał mastera zależnie od wersji językowej.
Wszystkie operacje obrębie jednego repozytorium.

Wiara czyni cuda napisał(a):

baant napisał(a):

nie wystarczy dobra konfiguracja i odpalanie aplikacji w trybie pl/en? ._.

To wymóg klienta żeby osobna wersja była na oddzielnym serwerze.
Klient wie, że istnieje taka możliwość żeby skonfigurować na jednym serwerze kilka wersji językowych aplikacji ale z pewnych względów nie chcemy tego tak ustawiać (ograniczenia uprawnień użytkowników panelu administracyjnego do konkretnej wersji językowej).

Ale instalacja nie ma nic wspólnego z repozytorium i projektem... Może być przecież jeden projekt, a z niego instalacja na dwa różne serwery dwóch różnych wersji....

Ty hostujesz aplikację bezpośrednio z repozytorium Gita, czy co?

@Wiara czyni cuda: Ale wiesz, że z jednego source kodu możesz zbudować różne wersje językowe w większości nowożytnych technologi ? W projekcie uzywasz placeholderów a następnie na etapie budowania zamieniane są one na odpowiednie wartości.

Schadoow napisał(a):

@Wiara czyni cuda: Ale wiesz, że z jednego source kodu możesz zbudować różne wersje językowe w większości nowożytnych technologi ? W projekcie uzywasz placeholderów a następnie na etapie budowania zamieniane są one na odpowiednie wartości.

Rozbieżność między serwisami nie ma związku z tłumaczeniem :-)

Jeśli już pójdziesz w stronę feature toggle, to jeszcze jedna ważna rzecz:

• wersje językowe osobno
• feature toggle niezależne od wersji językowej

Żeby się nie skończyło na feature togglach działających na takiej zasadzie:

if(lang=="en-US" || lang=="en-GB" || lang == "pt-BR" ... ) {
    ....
}

Wiara czyni cuda napisał(a):

• główne różnice pomiędzy wersjami będą widoczne w bazie danych

Czemu w ogóle wersje językowe różnią się głównie zawartością bazy danych? I dlaczego wsparcie tego miałoby wymagać odrębnych branchy albo nawet repozytoriów?

Wsparcie różnych wersji językowych to kwestia jakiegoś i18n na froncie, może ogarnięcia jakiejś biblioteczki tłumaczeń jeśli to konieczne (np. żeby serwer zwracał odpowiedzi w języku użytkownika). Konfiguracja serwera też raczej będzie w plikach konfiguracyjnych, chyba, że to jakaś specjalna konfiguracja którą sobie administrator zmienia w locie... ale jeśli tak, to nadal nie widzę po co odrębne branche na to :(

superdurszlak napisał(a):

Wiara czyni cuda napisał(a):

• główne różnice pomiędzy wersjami będą widoczne w bazie danych

Czemu w ogóle wersje językowe różnią się głównie zawartością bazy danych? I dlaczego wsparcie tego miałoby wymagać odrębnych branchy albo nawet repozytoriów?

Bo może jedna wersja jest dla klientów polskich a druga angielskich? Zgaduję -- ale to tym bardziej jeden projekt z jednym masterem...

superdurszlak napisał(a):

Żeby się nie skończyło na feature togglach działających na takiej zasadzie:

if(lang=="en-US" || lang=="en-GB" || lang == "pt-BR" ... ) {

Widziało się takie rzeczy, widziało..
nawet podobną linijkę się kiedyś napisało :)

Wiara czyni cuda napisał(a):

Rozwiązania:

• 2x branch master (np. master_pl i master_en),
• osobne repo pod daną wersję językową

To nie są rozwiązania. To smrodki, które kopną cię w zadek w ciągu tygodnia. Co zrobisz, jak ktoś ci zgłosi bug'a? Będziesz go naprawiać w 2 miejscach? Jak zaimplementujesz cokolwiek nowego?
Z tego co piszesz 90% kodu masz wspólne 10% kodu osobne. Najlepiej załatwić to konfiguracją, czyli gdzieś tam globalna zmienna, a w kodzie po prostu if lang=="PL" Rozszerzeniem tego jest wyciągnięcie części różnego kodu do osobnych 2 repozytoriów i wczytywanie jako bibliotek o wspólnym API, ale z różną implementacją.

Panowie, o jakich feature togglach Wy piszecie? Przecież autor pyta o permanentną konfigurację w zależności od wersji językowej, a nie chwilowe przełączniki na czas testowania czy wdrażania nowych ficzerów.

somekind napisał(a):

Przecież autor pyta o permanentną konfigurację w zależności od wersji językowej, a nie chwilowe przełączniki na czas testowania czy wdrażania nowych ficzerów.

Zaraz się okaże, że permanentność tej konfiguracji przeminie po miesiącu - i będzie potrzebna „konfiguracja” w języku X z ustawieniami jak w języku Y, a częściowo jak w języku Z.

I co wtedy?
W przypadku np. pliku konfiguracyjnego - proste, przygotowuje się odpowiedni plik konfiguracyjny.
W przypadku dwóch osobnych branchy releasowych z różnymi feature'ami, różnymi fixami – de facto dwóch forków projektu – przygotowanie trzeciego może się okazać masakrycznie pracochłonne.

Azarien napisał(a):

Zaraz się okaże, że permanentność tej konfiguracji przeminie po miesiącu - i będzie potrzebna „konfiguracja” w języku X z ustawieniami jak w języku Y, a częściowo jak w języku Z.

I co wtedy?

Nic, konfiguracja to nadal konfiguracja. :)

W przypadku np. pliku konfiguracyjnego - proste, przygotowuje się odpowiedni plik konfiguracyjny.

Pełna zgoda.

W przypadku dwóch osobnych branchy releasowych z różnymi feature'ami, różnymi fixami – de facto dwóch forków projektu – przygotowanie trzeciego może się okazać masakrycznie pracochłonne.

Owszem, a ktoś twierdzi inaczej?

Mam wrażenie, że w ogóle nie zrozumiałeś, o czym pisałem, być może wyraziłem się nie jasno, więc się poprawiam.

Feature toggle to technika służąca do próbnego wdrażania nowych ficzerów systemu w celu sprawdzenia, czy działają prawidłowo albo pasują użytkownikom, a w razie problemów dają możliwość ich łatwego wyłączenia (bez redeploymentu wszystkiego), a także łatwego rozwoju (bo mogą istnieć w głównej gałęzi, więc nie mamy długożyjącego feature brancha, którego trzeba co chwilę aktualizować z masterem). W założeniu feature toggle to coś, co zostanie usunięte, gdy ficzer wejdzie na stałe albo wyleci z aplikacji.
Ustawienie języka aplikacji albo włączenie/wyłączenie całego modułu systemu na konkretnym serwerze ma się nijak do feature toggle. To jest po prostu konfiguracja.

@somekind Mam wrażenie, że czepiasz/czepiamy się słówek, więc spróbuję przedstawić cały pomysł nieco dokładniej.
Problem polega na odpowiedzi na pytanie jaki jest właściwy sposób na utrzymywanie 2 wersji językowych aplikacji. Z mojego doświadczenia, najlepszym sposobem jest posiadanie 1 gałęzi kodu będącej w stanie obsłużyć oba języki. To, który język jest obsługiwany w danej chwili przychodzi z zewnątrz (konfiguracja). Autor pytanie nie napisać czym te wersje mają się różnić. Jeżeli chodzi tylko o interface użytkownika, to jest od groma gotowych rozwiązań pozwalających wstawić odpowiednie wartości. Czasami może wystąpić jeszcze:

1. Inna logika biznesowa, bo np. w jednym kraju RSSO liczy się wg. innego wzoru, albo system ma rozpoznawać tablice rejestracyjne wg. innego schematu
2. Inny zestaw funkcji (bo np. rozpoznawanie twarzy gdzieś jest zabronione.

Oba punkty powinny być rozwiązane na tej samej gałęzi kodu, a informacja o tym, która opcja akurat jest wybrana powinna być definiowana nie w kodzie typu public static final String FLAVOUR = "PL", tylko wstrzykiwana z zewnątrz - parametr command line, plik konfiguracyjny, zmienna środowiskowa osobny micro service z konfiguracją, systemowe locale - nie wiem bo konkretnie się sprawdzi w tym przypadku.
W kodzie aplikacji albo będziemy mieli ileś tam if...then, albo można wyciągnąć specyficzne dla języka fragmenty do osobnych bibliotek/modułów/usług (nie wiem w czym to jest pisane, więc nie odpowiem dokładnie). Te kawałki kodu mogą być wstrzykiwane albo runtime, albo build time z CI. Też nie powiem co jest lepsze, bo nie wiem nawet czy to aplikacja desktop, czy rozproszony system działający w kontenerach.
Podsumowując, możliwe są 2 podejścia, albo wszystko załatwia kod, dostajemy pojedynczy zestaw artefaktów i za pomocą zewnętrznie podanego parametru / zestawu parametrów definiujemy które gałęzie kodu są właściwe dla tej instancji, albo zaprzęgamy do roboty CI, który zbuduje osobne artefakty skonfigurowane do działania w konkretnych sytuacjach.

Niezależnie od tego co zostaje wybrane, obowiązkowym punktem startu jest zrobienie dokładnej analizy czym mają się różnić te instancje, bo jak zwykle, wybór narzędzi powinien zależeć od tego co ma zostać zrobione.

Jedno repo, jeden master. Przecież wersje językowa możesz określić na etapie budowania aplikacji albo odpalania jej z odp. parametrami (a nawet w runtime, ale rozumiem ze to niepożądane). Jeden codebase, a aplikacje działają na różnych wersjach.

Proponuje dopytać klienta, jaka dokładnie potrzeba stoi za tym wymaganiem.