Gitflow problem pracy w zespole

Cześć,
Mam problem w pracy, do którego nie wiem jak się do niego zabrać.
Pracujemy w 6-osobowym zespole, gównie zajmujemy się Prestashop, Wordpres, Magento.
Obecnie pracujemy w dość pato systemie. Wszyscy pracujemy na tych samych plikach i bazie postawionych na serwerze lokalnym.
Gdy wprowadzimy odpowiednie zmiany, przenosimy zmiany przez FTP na serwer produkcyjny a w gicie (Aplikacji desktopowej) zaznaczymy swoje pliki, linijki kodu robimy comita i push. Taki system fajnie działał jak było nam 2/3 osoby, ale teraz robi się straszny bałagan, testowe funkcje, style itp.

Z tego co wiem, to zgodnie ze sztuką, to każdy z nas powinien mieć swoja lokalną wersję projektu i na niej pracować, tylko tu pojawia się problem.
Przyjmijmy, że np.: Pracownik A instaluje i przerabia moduł na swojej wersji projektu, następnie wrzuca to na serwer testowy (zmienia bazę danych, dodaje konfiguracje, nowe tabele). Pracownik B robi pula na swój testowy serwer, konfiguruje odpowiednio moduł, styluje i znowu wrzuca to na serwer testowy. Następnie pracownik A wrzuca zmiany na serwer produkcyjny, jak ktoś jeszcze w międzyczasie dokona zmian na testowym lub produkcyjnym to można się zapłakać.
Obecne rozwiązanie gdzie pracujemy wszyscy na jednych plikach i bazie zaoszczędza naprawdę sporo czasu, ale robi spore bałagan w projektach.

Czy możecie mnie nakierować w kierunku jakiegoś rozwiązania, narzędzia? Jak waszym zdaniem powinna wyglądać dzieżka pracy?

Ciężko zrozumieć to co napisałeś. Nie wiemy jakie pliki synchronizujecie przez ftp, a jakie przez gita.

O ile Cię dobrze zrozumiałem to przenosicie ręcznie pliki na ten serwer. Zamiast tego po prostu zainstaluj tam gita i ściągnij kod z mastera. Następnie, każdy z was robiąc jakieś zmiany powinien zrobić sobie lokalnie brancha i pushować do repozytorium na brancha, a nie na mastera. Tworzysz na jakimś serwerze gita Pull Requesta gdzie inni przeglądają Twoje zmiany i komentują je w razie gdyb widzieli jakieś błędy. Kiedy dany branch jest przetestowany lokalnie to merge'ujecie go do mastara i na serwerze pullujecie kod z mastera.

W gicie nie powinniście trzymać żadnych sekretów typu hasła. Wasz kod w gicie powinien sobie zaczytać plik z sekretami i go używać. Każdy z was powinien mieć swój własny plik z sekretami na waszym komputerze lub na tym serwerze.

Tak bym widział najprostszy workflow. Mając testowe serwery możecie tam zaciągać kod z branchy i go testować na tych serwerach zanim zmerdżujecie go do mastera.

Idąc w stronę bardziej dojrzałych rozwiązań to możecie po merge'u stworzyć artefakt z waszą aplikacją, otestować ten artefakt na serwerze testowym i zrobić wdrożenie tego artefaktu po prostu kopiując na serwer produkcyjny. Dzięki temu wiecie, że artefakt, który otestowaliście na serwerze testowym jest tym samym co zostało wdrożone na produkcję. Taki arfefakt to może być np. obraz dockerowy, który przyjmuje jakąś konfigurację z linkami do innych serwisów.

@twoj_stary_pijany: Dzięki za odpowiedz :) Ogólnie z wrzucenie plików na serwer produkcyjny to mamy to fajnie sprocesowane. Największy problem jest jak kilka osób musi pracować nad jedną funkcjonalnością projektu, nie było by problemu wrzucania i pobierania zmian przez gita z testowego ale tu dochodzi konflikt bazy. Nie wiem czy w takich projektach powinniśmy pracować wszyscy na jednej bazie czy czy każdy powinien mieć swoją.

Zakładam, że używacie jakichś plików z migracjami. Nie jestem ekspertem od weba, ale często spotykam się z problemami, że ktoś zrobił wdrożenie, zrobił upgrade bazy i później ktoś sobie testuje na tym samym serwerze stary kod i już baza jest popsuta więc musi ją resetować. W takim wypadku zalecałbym nawet dodanie kolejnego środowiska testowego. Np. tak:

• prod
• qa
• dev

Kiedy programista kończy swoją pracę lokalnie (na swojej bazie danych) to robi wdrożenie na dev. Dev jest środowiskiem dynamicznym i może być niestabilne bo wiele osób robi wdrożenie w tym samym czasie. Kiedy zrobicie merge do mastera to wiecie, że kod jest stabilny i robicie wdrożenie na qa. Na qa już wszystko musi działać dobrze bo jeżeli qa się wywali to macie prawie pewność, że prod też się wywali.

Gdyby to ode mnie zależało to bym skonteneryzował wszystko, kompilował dockera na dev i później robił deployment obrazu dockerowego na qa, a później na prod. Robienie wdrożenia kodu z gita ma tę wadę, że jest wiele rzeczy, które mogą pójść nie tak w międzyczasie. Ktoś może zmodyfikować jakiś plik na serwerze i będziesz szukał błędu przez cały weekend.

Natomiast na początku zdecydowanie szybciej się dostarcza feature bez całego CI/CD. Pytanie czy nie przyszedł czas na to, że powinniście wszystko skonteneryzować? To wszystko zależy jaki macie budżet i jak bardzo łatanie błędów deploymentu was spowalnia.

Chyba już wiem w jakim kierunku powinniśmy pójść. Dzięki wielkie.

M0D00 napisał(a):

Chyba już wiem w jakim kierunku powinniśmy pójść. Dzięki wielkie.

Powinniście całkowicie zmienić podejście. Bo to co teraz robicie to zakrawa o kryminał xD

1. Na oko to brakuje wam jakiegoś CI a nie gita
2. Dodatkowo brakuje wam środowisk DEV - przecież nie da sie tak pracować że każdy wrzuca zmiany na tą samą maszynę o_O
3. Dam głowę że nie macie też żadnych testów automatycznych tylko wszystko opiera się na szybkim "przeklikaniu" przez developera.

WordPress jest o tyle kłopotliwy do pracy z gitem, że ciężko zsynchronizować zmiany wprowadzone do panelu pomiędzy poszczególnymi wersjami.

@Xarviel: Dokładnie o to chodzi, można opisywać co wyklinać ale jest to bardzo czasochłonne.

Xarviel napisał(a):

WordPress jest o tyle kłopotliwy do pracy z gitem, że ciężko zsynchronizować zmiany wprowadzone do panelu pomiędzy poszczególnymi wersjami.

Nie wierzę w to, że nie da się tego spokojnie w gicie ogarnąć.

Wrzucanie zmian i programowanie przez ftp to najgorsze bagno i całkowity brak profesjonalizmu, amatorka, uważam.
Normalnie powinien każdy mieć oddzielnego lokala i pullować zmiany innych i wrzucać swoje na dev, najlepiej co najmniej 1-2 razy na dzień.
Jak funkcjonalność jest gotowa, to testujecie na dev, a później leci na prod.
Nie robić w kilka osób tej samej rzeczy, żeby nie było kolizji za dużo.
Na prod bezpośrednio wrzucacie tylko poprawki bugów.

A jak proces jest bardziej złożony to używacie gitflow.
Czyli funkcjonalności rozbijać na featury.

Każdy musi mieć własne środowisko Dev. Zastanówcie się nad jakimś dockerem, vagrantem czy innym virualboxem.
Każdy wrzuca kod do Gita i raz na jakiś czas np. raz dziennie wrzucacie zamiany i warto to jakoś zautomatyzować.

serek napisał(a):

Xarviel napisał(a):

WordPress jest o tyle kłopotliwy do pracy z gitem, że ciężko zsynchronizować zmiany wprowadzone do panelu pomiędzy poszczególnymi wersjami.

Nie wierzę w to, że nie da się tego spokojnie w gicie ogarnąć.

@serek

Wszystkie zmiany w panelu, które operują na copy zapisuja się w bazie danych, nie bezpośrednio w plikach. Więc przy 2-3 osobach, które jednocześnie coś dodaje posty, zdjęcia, jakieś zmiany w wtyczkach to może być ciężko, bo za kazdym razem zmienia się baza i trzeba byłoby ręcznie ją aktualizować.

WordPress ma co prawda wbudowaną możliwość eskportu/importu danych, ale nie zawsze to działa. Sam często dostawałem komunikat, że modułu X nie udało się zaimportować i miałem powiedzmy 80% zmian, a pozostałe 20% musiałem sobie wyklikac samemu jeśli to było coś ważnego.

Moim zdaniem przy takim zespole sprawdziło by się coś prostego:

feature branch --> branch staging --> branch master

Mergując zmiany do branch staging robicie sobie automatyczny deploy na serwer testowy. Jak wszystko działa to możecie to sobie mergować do mastera lub ew. jakiegoś brancha typu sprint ale to u was by się chyba nie sprawdziło

No ale to powinno działać tak, że każdy ma swoją lokalną bazę i sobie na niej klika wordpressy a jak ficzer jest gotowy to można go zmergować do "mastera" (ups! "maina") i wtedy jakiś tester sobie klika na testowym serwerze. Jeśli pracujecie w kilka osób nad tym samym to sorry, nie ma zmiłuj, trzeba na bieżąco robić rebasy... albo tak podzielić prace, żeby tych konfliktów było jak najmniej.

A jeśli chodzi o testowy serwer to wyjścia są dwa:

1. albo macie jakiś interfejs gdzie można sobie wybrać, który branch chcecie aktualnie załadować na testowy serwer (tylko, że wtedy musicie mieć idealnie napisane migracje, które pozwolą na cofanie zmian bo jest jedna baza)
2. albo macie to tak skonfigurowane, że każdy branch ma jakąś swoją instancję i swój adres (lub ewentualnie możliwość przełączenia konfiguracji - branch + baza danych)

Wielkie dzięki wszystkim za pomoc.

Myślę ze z pracą na plikach sobie poradzę. Gorzej z bazą, po przyjmijmy np. Pracownik A, zmienia ustawienia modułu na sowiej wersji sklepu, potem wrzuca to na serwer testowy (Znowu wyklinuje konfiguracje modułu) i finalnie robi to samo na produkcji.
Czy możecie podesłać jakiś pomysł/narzędzie na to jak można zautomatyzować przenoszenia zmian w bazie?

Robisz albo metodą ręczna. Każdy dopisuje sqlke do jakiegoś commmita i ktoś to potem ręcznie ogarnia. Albo korzystacie z jakiegoś systemu migracji. Nie korzystałem na Wordpress z tego ale wrzucając na szybko w Gugiel "Wordpress migrations" pokazały się porównania paczek które to migracje obsługują. Pewnie trzeba by to protestować i wybrać co Wam odpowiada.
Rozwiązanie nr 2 łatwo też zautomatyzować.

A jeśli chodzi o testowy serwer to wyjścia są dwa:

1. albo macie jakiś interfejs gdzie można sobie wybrać, który branch chcecie aktualnie załadować na testowy serwer (tylko, że wtedy musicie mieć idealnie napisane migracje, które pozwolą na cofanie zmian bo jest jedna baza)
2. albo macie to tak skonfigurowane, że każdy branch ma jakąś swoją instancję i swój adres (lub ewentualnie możliwość przełączenia konfiguracji - branch + baza danych)

Przełączanie się po branchach na serwerze testowym to słabe rozwiązanie, generuje pełno problemów.
Na serwerze testowym ma być jeden branch do testowania (dev, develop).
Featury jak przetestujesz lokalnie to robisz merga do deva i tyle, a jak osobno chcesz wrzucić feature, to go mergujesz do mastera na zasadzie hotfixa.

Mam wrażenie, że u Was kuleje tak na prawdę cały proces i pojedyncza zmiana jest trudna bo nie potraficie jej wpasować w Wasz proces.

Rozwiązań jest tyle ilu programistów, ale akurat pracuje z jedna z technologii, którą macie do czynienia (Magento) więc pokrótce jak wygląda prosty proces dla małego zespołu.

Mamy branch master. Gdy programista podejmuje task to tworzy sobie feature-branch wychodząc z mastera i wprowadza swoje zmiany.
Jeśli potrzebne są zmiany w bazie to Magento ma dwa główne mechanizmy:

• declarative schema do zarządzania schemą bazy danych - czyli innymi słowy jeśli jakiś moduł ma wprowadzić zmiany w bazie danych to masz odpowiedni plik XML, w którym wprowadzasz zmiany i są one wywoływane na bazie w momencie wywołacani bin/magento setup:upgrade
• do zmian danych w bazie masz kolejne rozwiązanie czyli upgrade scripty/patche - za pomocą tego rozwiązania możesz wprowadzić dowolne zmiany w bazie - np. coś zaimportować, zmienić ustawienia itp.

Dzięki tym dwóm rozwiazanium możesz w trakcie deploymentu dokonać dowolnej migracji bazy danych na każdym środowisku - czy to developerskim czy produkcyjnym, dzięki czemu nie ma rozjazdów w bazie.

Kolejny ważny element to w naszym przypadku co jakiś okres czasu (u nas raz dziennie) robiony jest dump bazy z głównego środowiska i jest on odpowiedni przerabiany - usuwane są dane wrażliwe, logi etc i wrzucany na s3. Taki dump każdy może sobie w dowolnej chwili wgrać na lokalne środowisko, dzięki czemu jak coś napsuje w lokalnej bazie danych, albo np. coś zostanie zmienione ręcznie na głównym środowisku, to można sobie pobrać bieżącą wersję bazy. Wszystko odbywa się automatycznie - developer wpisuje 1 polecenie do synchronizacji bazy danych. Podobnie mamy z synchronizacją mediów. W przypadku dużych projektów czasami pipeliny stripują część danych/mediów, aby takie synchronizacje nie trwały zbyt długo, ale to już detal.

I teraz wracając do naszych feature branchy - jak developer uznaje, że jest on gotowy, wszystko przejdzie CR to tester może sobie zbudować środowisko testowe. Środowisko testowe buduje się automatycznie - pobiera wyżej wspomniany strip bazy danych i buduje dany branch na serwerze testowym, odpalane są wyżej wspomniane migracje. Gdy występują jakieś żadkie sytuacje, że trzeba coś ręcznie skonfigurować bo import byłby zbyt kłopotliwy to dodajemy odpowiednie pole w JIRZE z opisem deployu dla testera, ale to jest RZADKOŚĆ - nie pamiętam kiedy ostatnio miałem taką sytuację.

Jak tester przetestuje wszystko to leci MR do mastera - z reguły nie ma konfliktów, bo branche mają krótki cykl życia + często deployujemy na produkcję.

Oczywiście tak jak pisałem są inne strategie np. z branchem developerskim/stagingowym etc. Trzeba dobrać pod projekt. Ale kluczowe "take away"

• zamiast wgrywać zmiany przez FTP musicie mieć pipeliny potrafiące w każdej chwili zbudować projekt od zera z tego co jest w repozytorium - na początek polecam albo deployer.org (chyba najprostsze z możliwych narzędzi) albo gitlab pipelines / github actions. Tutaj można ogarnąć cały proces bardzo fajnie. Póki będziecie wgrywać zmiany przez FTP będzie burdel - tak już powoli nawet hindusi nie robią.
• koniecznie musicie używać migracji. W Magento masz cały mechanizm gotowy. W Prestashop o ile pamiętam też są migracje np. przy updajtach, więc pewnie ten mechanizm możecie wykorzystać. Nie wiem jak WP.
• środowiska developerskie powinny być spięte - np. szybka możliwość updajtu bazy danych, przetestowania builda etc - jak coś nie jest proste to ludzie tego nie robią. Myślę, że docker bardzo ułatwia ogarnięcie takich środowisk developerskich, więc jak nie stosujecie to warto zacząć.

Zbudowanie takiego procesu nie jest rzeczą prostą, zwłaszcza jak się nie pracowało wcześniej w podobnej metodologii, ale przy odrobinie ogarnięcia tematu jest do zrobienia.

zamiast wgrywać zmiany przez FTP musicie mieć pipeliny potrafiące w każdej chwili zbudować projekt od zera z tego co jest w repozytorium - na początek polecam albo deployer.org (chyba najprostsze z możliwych narzędzi) albo gitlab pipelines / github actions. Tutaj można ogarnąć cały proces bardzo fajnie. Póki będziecie wgrywać zmiany przez FTP będzie burdel - tak już powoli nawet hindusi nie robią.

Pipeliny nie są koniecznością to mogą dodać później jak zaczną normalnie pracować z gitem i branchami i będzie działać wszystko.
Zmiany można zaciągać ręcznie na serwer. Tylko nie kompilować assetsów js/css na serwerze, a normalnie przechowywać w repo i jak puluje się kod, to nie trzeba odpalać nie wiadomo czego, tylko wystarczy pull, jak są migracje to odpalenie migracji, jak nowa paczka to composer install i tyle.
Pipeliny i deployer to jest wyższe dobre, ale bez tego można normalnie pracować na gicie.

Dzięki wszystkim wasze wypowiedzi uświadamiają mnie tylko ze standardowe podejście do pracy z gitem nie pomoże, a jeszcze bardziej może zaszkodzić. Macie racie tu jest potrzeby dobry proces do automatyzacji i dockery.
Tylko fajnie to wygląda w teorii a w rzeczywistości gdzie pracuje się na budżetowych projektach jak WordPress czy Prestashop, gdzie liczy się każda godzina pracy, żeby zarobić na projekcie, ciężko jest wprowadzić jakieś nowe rozwiązanie i przy okazji nie stracić na projekcie.

I tak powstaje błędne koło.

Żadne dockery nie są potrzebne, docker to jest bajer, tak samo jak pipeline, może poprawić flow pracy, ale nie jest koniecznością.
Git sam w sobie to absolutna konieczność, tylko trzeba umieć pracować na branchach chociaż w stopniu podstawowym i rozumieć, że potrzebne są 3 środowiska pracy lokal, dev, prod.

M0D00 napisał(a):

Tylko fajnie to wygląda w teorii a w rzeczywistości gdzie pracuje się na budżetowych projektach jak WordPress czy Prestashop, gdzie liczy się każda godzina pracy, żeby zarobić na projekcie, ciężko jest wprowadzić jakieś nowe rozwiązanie i przy okazji nie stracić na projekcie.

Ale patrząc na patologię jaką teraz odwalacie, to zakładam, że ten projekt jest bardzo słabej jakości. Więc tak czy siak to się kiedyś na Was odbije. Więc lepiej wcześniej starać się rozwiązać problemy niż później.

@serek: Dokładnie, masz 100% racji. Właśnie zaczyna się to odbijać na nas i szukam jakiegoś rozsianego rozwiązania. Tu nie jest problem to że nie chce nam się, tylko czas i stawki godzinne jakie są dla CMS (nie licząc Magento).

Jeśli projekty są małe i zależy wam na czasie to takie minimum to dobrze zaprowadzone repo + ujednolicony proces buildów + ujednolicone środowiska.

To już lepiej zrobić taki najprostszy CD w postaci:

• konfigurujecie ręcznie 2 środowiska master i dev
• piszecie prosty skrypt, który robi to co robicie ręcznie - np. "pull z repo, build assetów itp"
• w Gitlabie robicie prosty pipeline, który po pushu na branch master/dev po prostu odpala ten skrypcik

To podejście ma wiele wad, ale i tak jest lepszy niż deploye ręczne bo wymaga pewnej dyscypliny od devów i repozytorium staje się single source of truth. Kiedyś pracowałem z zespołem z Indii - deploye przez ftp skończyły się tak, że kod niby był w git, ale było sporo bugfixów na produkcji, których nikt do repo nie wrzucił i na końcu to już się wszyscy bali cokolwiek dotknąć aby nie zepsuć... Dlatego serio nawet debilnie prosty automat będzie lepszy niż ręczne deploye.

Tak jak pisałem - póki nie dojdziecie do momentu, że jesteście w każdej chwili pewni, że możecie cały projekt odbudować automatycznie z repozytorium póty będziecie mieli w projekcie bałagan.

Nie chodzi o ręczne przerzucanie plików, tylko pullowanie komendą przez ssh, czyli robienie tego samego co robiłby taki skrypt, ale przez ssh.

Rozmowa o gicie to tak naprawdę wstęp do rozmowy o całym procesie developerskim, który zwykle obejmuje:

1. Prace nad zmianą
2. Testowanie zmiany
3. Code review i wprowadzanie poprawek
4. Releasy

Podstawowe pytanie: jaki problem rozwiązujesz, co nie działa?

Jeżeli np. nie robicie (3), to wystarczy trunk-based development, czyli pracujecie na jednym branchu w gicie i kto pierwszy ten lepszy (tak działa np. wprowadzanie zmian w Confluencie czy Google Docs - nie ma branchy i działa). Bardziej złożone branchowanie jest potrzebne, kiedy chcecie robić code review (Pull/Merge Requesty), albo kisić ficzery na pobocznym branchu, bo nie chcecie tego od razu wdrażać tylko czekacie na release (punkt 4).

Charles_Ray napisał(a):

tak działa np. wprowadzanie zmian w Confluencie czy Google Docs - nie ma branchy i działa

Ale weź nie porównuj procesu tworzenia oprogramowania z używaniem edytora tekstu, trochę różne rzeczy xD Używanie branchy to must have, inaczej szlag wszystko trafi prędzej, czy później.

Ale weź nie porównuj procesu tworzenia oprogramowania z używaniem edytora tekstu, trochę różne rzeczy xD

Dlaczego nie. Jest to problem kontroli wersji. Nie myśl rozwiązaniami, tylko problemem, który chcesz rozwiązać.

Używanie branchy to must have, inaczej szlag wszystko trafi prędzej, czy później.

Nieprawda. Obecnie w skali >10k inżynierów nie używamy branchy.

EDIT: dla uściślenia - każdy pracuje na swojej kopii repozytorium, ale nie tworzymy „trwałych” branchy typu „develop” czy „release”. Wszystko ląduje do „mastera” i nie odbijamy brancha od brancha. Przepraszam za wprowadzenie w błąd :)

Nieprawda. Obecnie w skali >10k inżynierów nie używamy branchy.

Nawet dev i master? Grubo :o
Chociaż pakować wszystko na mastera też można, ale master to też branch :).
Jak pisze swoje apki sam, to ładuje wszystko na master.