Wdrażanie zmian na produkcje przy 20 osobowym zespole

Witam! Pracuje w PHPowym projekcie. Nad tym samym projekcie pracuje nas prawie 20 PHP programistów. Zastanawiam sie jaki będzie odpowiedni proces wdrażania zmian do produkcji. Mamy bardzo duzo gałęzi dziennie do polaczenia z galezia master. Dziennie coś pomiędzy 10-20 biletów. Jak je połączyć?

Zastanawiam się czy np jeżeli będziemy je łączyć pojedynczo czy nie będzie problemów z konfliktami. CI/CD build trwa okolo 30 min. Wiadomo, na początku test, po testach buduje sie image i na sam koniec deploy.

Co jeśli będzie taki deploy kilka np jeden po drugim w odstępie 3-5 minut? Jakie jest ryzyko? My używamy Gitlab'a. Wydaje mi się, że od razu po kliknieciu merge kod zostaje połączony z gałęzią master i dopiero po 30 minutach jest wdrażany do produkcji. Czy takie podejście jest?

poniatowski napisał(a):

Zastanawiam sie czy np jezeli bedziemy je laczyc pojedynczo czy nie bedzie problemow z conflictami.

A jaka alternatywa? Przecież łączyć się grupkami, np po cztery, nie da.

BTW żeby rozwiązać takie problemy wymyślono rozpraszanie monolitu. Jakbyś miał 4 aplikacje zamiast jednego monolitu byłoby prościej. Z drugiej strony jak aplikacja jest duża i nie jeżdzicie po tych samych plikach to ryzyko konfliktu jest niskie. Tylko refaktorów nie można robić :( Pracowałem w takim monolicie w kamsofcie. Każdy pokój-team miał swój pakiet-folder i nawet nie zaglądało się do cudzych folderów :D

Projekt, w sumie moze jest bardzie mid size. Nie jest az taki duzy. Nie prowadziamy duzo refaktoryzacji. Czesto zdaza sie, ze pracujemy na tych samych plikach.

Obecnie, mamy 1 godzinne okno w ktorym wdrazamy zmiany na produkcje. Zaleznie ile jest tickow, po kolei klikamy merge. Na koniec jak wszyskie galezie zakoncza testy etc to wszsytkie te tickety na raz sa mergowane do master. 1 obraz. Z tego co rozumiem, to chyba cos takiego jest.

Czesto zdaza sie, ze pracujemy na tych samych plikach.

Dlaczego się to zdarza często?

yarel napisał(a):

Czesto zdaza sie, ze pracujemy na tych samych plikach.

Dlaczego się to zdarza często?

Moze nie az tak czesto. Kila razy na caly miesiac pracy. Nie jest to codziennie. Pliki z PHP sa dosc male. Male klasy, ale jest ich cholernie duzo.

poniatowski napisał(a):

Obecnie, mamy 1 godzinne okno w ktorym wdrazamy zmiany na produkcje. Zaleznie ile jest tickow, po kolei klikamy merge. Na koniec jak wszyskie galezie zakoncza testy etc to wszsytkie te tickety na raz sa mergowane do master. 1 obraz. Z tego co rozumiem, to chyba cos takiego jest.

Dobra, chyba widze problem. Normalnie merdzuje się wszystko wcześniej i wdraża na serwer testowy zanim wgra się na produkcję. Wgranie na produkcje to już nie powinny być zadne merdze tylko przesunięcie zbudowanej wcześniej paczki.

Podsumowując - brakuje wam środowiska testowego na którym moglibyście w spokoju merdzować

Owczywiście można też tak jak mówisz od razu merdzować do mastera i mastera od razu na produkcję tylko zwykle wtedy jest klaster i podmianka na proda idzie w dowolnym momencie a nie w oknie. Takie okno się zwyczajnie nie skaluje i niedługo zacznie się wam wydłużać w coraz bardziej nerwowym stylu

@KamilAdam Wlasnie te godzine okno nie ma dla mnie wiekszego sensu. Tzn nie krytykuje. Staram sie zrozumiec, odnalezc sens. Nigdy nie pracowalem z tak duza iloscia devow na tym samym projekcie. Wiec podejrzewalem, ze moze chodzi o konflikty w plikach czy cos. Pracowalem w mniejszych team'ach po 4-6 osob. I wtedy mergowalismy jak ticket zostal przetestowany. Pojedyncze tickety byly wdranzane do produkcji. Tutaj jak mam 10 ticketow to jest budowany jeden obraz i ten obraz jest na koniec wdranzany do produkcji. Czy dobrze czy zle nie wiem? Co jak te 10 tickwtow wprowadzi np 2-4 bledy? Skad bede wiedzial, ktory commit / galez mam usunac z produckcji? I w jednym czasie zmiany na x plikach, to mnie przeraza. Ja lubie duzo zmian w plikach robionych malymi krokami.

Nigdy nie pracowalem z takim podejscie. I szczerze rozbilo mnie takie podejscie.

@KamilAdam:

BTW żeby rozwiązać takie problemy wymyślono rozpraszanie monolitu. Jakbyś miał 4 aplikacje zamiast jednego monolitu byłoby prościej.

Najgorsza chyba rada. Skończyć z rozproszonym monolitem i mieć jeszcze więcej problemów. OP wyraźnie pisze że ich największym problemem jest że wiele osób pracuje na tych samych plikach z kodem. Więc jak zrobią 4 aplikacje to zamiast robić zmiany w jednej wszyscy będą robić w 4 aplikacjach i potem to synchronizować ze sobą :D

@poniatowski:
Z tego co piszesz to najlepiej moim zdaniem by się wam sprawdziło podejście w stylu starego dobrego GitFlow zamiast trunk-based development. Macie swoją gałąź dev do której mergujecie swoje zmiany i jak wszystko jest przetestowane na środowisku developerskim to robicie merge z dev do main i na produkcję.

markone_dev napisał(a):

@poniatowski:
Z tego co piszesz to najlepiej moim zdaniem by się wam sprawdziło podejście w stylu starego dobrego GitFlow zamiast trunk-based development. Macie swoją gałąź dev do której mergujecie swoje zmiany i jak wszystko jest przetestowane na środowisku developerskim to robicie merge z dev do main i na produkcję.

I skutek taki, że zamiast 20 lekkich irytacji, że ktoś coś zmienił i trzeba rozwiązać konflikty będzie 1, ale potężny wk....w za każdym razem.

poniatowski napisał(a):

Co jeśli będzie taki deploy kilka np jeden po drugim w odstępie 3-5 minut? Jakie jest ryzyko? My używamy Gitlab'a. Wydaje mi się, że od razu po kliknieciu merge kod zostaje połączony z gałęzią master i dopiero po 30 minutach jest wdrażany do produkcji. Czy takie podejście jest?

Ile trwa niedostęność produkcji w momencie robienia deploy'a? Co jak 20 gości wypchnie błędne zmiany w piątek o 16? Ogólnie, jeżeli macie testy, którym ufacie, CD, które potrafi podmienić aplikację bez przerwy w jej działaniu, to nie ma nic złego w podejściu, że każdy commit leci z automatu na produkcję. Natomiast nawet w takim przypadku warto mieć te okna deploymentu, żeby nie zrąbać sobie wieczoru/weekendu.

piotrpo napisał(a):

markone_dev napisał(a):

@poniatowski:
Z tego co piszesz to najlepiej moim zdaniem by się wam sprawdziło podejście w stylu starego dobrego GitFlow zamiast trunk-based development. Macie swoją gałąź dev do której mergujecie swoje zmiany i jak wszystko jest przetestowane na środowisku developerskim to robicie merge z dev do main i na produkcję.

I skutek taki, że zamiast 20 lekkich irytacji, że ktoś coś zmienił i trzeba rozwiązać konflikty będzie 1, ale potężny wk....w za każdym razem.

poniatowski napisał(a):

Co jeśli będzie taki deploy kilka np jeden po drugim w odstępie 3-5 minut? Jakie jest ryzyko? My używamy Gitlab'a. Wydaje mi się, że od razu po kliknieciu merge kod zostaje połączony z gałęzią master i dopiero po 30 minutach jest wdrażany do produkcji. Czy takie podejście jest?

Ile trwa niedostęność produkcji w momencie robienia deploy'a? Co jak 20 gości wypchnie błędne zmiany w piątek o 16? Ogólnie, jeżeli macie testy, którym ufacie, CD, które potrafi podmienić aplikację bez przerwy w jej działaniu, to nie ma nic złego w podejściu, że każdy commit leci z automatu na produkcję. Natomiast nawet w takim przypadku warto mieć te okna deploymentu, żeby nie zrąbać sobie wieczoru/weekendu.

Nie rozumiem twojego postu. Co masz dokladnie na mysli. Podasz przyklad?

Nie mamy testow jednostkowych, praktycznie w ogole nie mamy testow. Powiedzmy, ze one nie istnieja.

Piszesz o bledach, ktore maga byc w pojedynczych commitach. A to co jak puszcze 10-20 galezi na raz to tych bledow juz nie bedzie? Przeciez lepiej wylapac bledy w oknie 8 godzinnym nizeli jak sie puszcza wszytko na raz. Nie rozumiem zupelnie twojego postu.

KamilAdam napisał(a):

poniatowski napisał(a):

Zastanawiam sie czy np jezeli bedziemy je laczyc pojedynczo czy nie bedzie problemow z conflictami.

A jaka alternatywa? Przecież łączyć się grupkami, np po cztery, nie da.

Technicznie to się da.

Jest coś takiego jak octopus-merge w gicie, czyli po prostu merge-commit który ma więcej niż 2 parenty. Możesz w ten sposób jednym commitem połączyć 10 branchy.

poniatowski napisał(a):

Witam! Pracuje w PHPowym projekcie. Nad tym samym projekcie pracuje nas prawie 20 PHP programistów. Zastanawiam sie jaki będzie odpowiedni proces wdrażania zmian do produkcji. Mamy bardzo duzo gałęzi dziennie do polaczenia z galezia master. Dziennie coś pomiędzy 10-20 biletów. Jak je połączyć?

Zastanawiam się czy np jeżeli będziemy je łączyć pojedynczo czy nie będzie problemów z konfliktami. CI/CD build trwa okolo 30 min. Wiadomo, na początku test, po testach buduje sie image i na sam koniec deploy.

Co jeśli będzie taki deploy kilka np jeden po drugim w odstępie 3-5 minut? Jakie jest ryzyko? My używamy Gitlab'a. Wydaje mi się, że od razu po kliknieciu merge kod zostaje połączony z gałęzią master i dopiero po 30 minutach jest wdrażany do produkcji. Czy takie podejście jest?

No to moim zdaniem główny problem jaki masz to właśnie to że deploy trwa 30 minut i macie tak dużo ludzi którzy nad tym pracują.

Ja po pierwsze chciałabym skrócić czas wdrażania, po to żeby te wdrożenia przebiegały szybciej i miały mniejszy feedback loop.

A co do problemu z wieloma programistami, to najlepsze by było continuous integrstion - malutkie commity wrzucane do mastera i ciągle łączenie lokalnych gałęzi z główną.

poniatowski napisał(a):

Nie rozumiem twojego postu. Co masz dokladnie na mysli. Podasz przyklad?

Dla mnie jakaś sensowna konfiguracja to:
Jest branch trunk. Jak zaczynasz robić jakiś ticket, to robisz sobie własny branch na zrobienie zmiany. Jak zrobisz zmianę, to pobierasz zmiany z trunka na ten własny branch, rozwiązujesz konflikty, robisz pull request do trunka.
W ramach PR, CI robi artefakty, zapuszcza testy, żeby sprawdzić czy wszystko jest OK, wrzuca zmiany do trunka, ubija branch z ficzerem.
W wybranych momentach, ostatni zbudowany artefakt, poprzez CD jest wrzucany na produkcję.

Zwykle nie robi się zmian na produkcji w losowych momentach, bo:

• Zmiana na produkcji oznacza, że aplikacja przez chwilę nie działa. Jeżeli tych zmian jest dużo, to aplikacja na produkcji nie działa bardzo często.
• Zmiana na produkcji z założenia jest obarczona ryzykiem, że coś się wyrypie. Jeżeli coś ma się wyrypać, to wolę mieć taki incydent w poniedziałek rano, zamiast w piątek po południu.

Natomiast co do samego problemu, który opisujesz, czyli zbyt dużej liczby konfliktów w kodzie, to możliwe przyczyny są następujące:

• macie źle podzielone odpowiedzialności w kodzie
• źle planujecie i wielu ludzi grzebie w tych samych rejonach systemu
• zbyt rzadko robicie merge
• jest was za dużo w stosunku do wielkości projektu

I co chyba ważne, dla mnie merge do master/trunk nie jest jednoznaczny z deployem na produkcję.

Problem nr 1 sam opisałeś: "Generalnie, jak ticket jest wdrozaony na produkcji to developer testuje zmiany na produckji i dopiero na koniec oznacza ticket jako ukonczony". Zgadzam się, że można w systemie ticketowym tak sobie flow zaplanować, że task jest zamykany dopiero kiedy wejdzie na proda i mamy potwierdzenie że jest ok, biznes ma prawo tak chcieć. Ale to nie znaczy, że w tym celu wrzucamy bezpośrednio na proda kod, który dopiero jest do przetestowania! Pomijając szczególne przypadki, że produkt jest mało istotny, albo jego awaria nic nie kosztuje, bo są takie, ale chyba nie o tym mowa.

Słusznie zauważyłeś, że jak pójdzie kilka deployów na raz, to de facto testujecie nie swoją zmianę, tylko swoją i losowe kilka innych. Środowisko testowe mogło by pomóc - wrzucamy "jak leci" to co jest, licząc się z konsekwencjami, ale też nie ryzykując rozwałki na prodzie, a jeśli wszystko działa, to wtedy "odcinamy" wersję (np. tag) i wrzucamy ją dalej.

Problem nr 2: build trwa 30 minut? Coś mi tu śmierdzi. Pracowałem w monolitach Javowych gdzie były 2 rodzaje testów, Docker, generowanie dokumentacji, i build/push/restart trwał może 10. Pogadaj z opsami czy kto tam wam to ogarnia - może dałoby się to skrócić, puszczać testy równolegle, jakiś cache dla zależności - warto o to zawalczyć.

piotrpo napisał(a):

poniatowski napisał(a):

Nie rozumiem twojego postu. Co masz dokladnie na mysli. Podasz przyklad?

Dla mnie jakaś sensowna konfiguracja to:
Jest branch trunk. Jak zaczynasz robić jakiś ticket, to robisz sobie własny branch na zrobienie zmiany. Jak zrobisz zmianę, to pobierasz zmiany z trunka na ten własny branch, rozwiązujesz konflikty, robisz pull request do trunka.
W ramach PR, CI robi artefakty, zapuszcza testy, żeby sprawdzić czy wszystko jest OK, wrzuca zmiany do trunka, ubija branch z ficzerem.
W wybranych momentach, ostatni zbudowany artefakt, poprzez CD jest wrzucany na produkcję.

Zwykle nie robi się zmian na produkcji w losowych momentach, bo:

• Zmiana na produkcji oznacza, że aplikacja przez chwilę nie działa. Jeżeli tych zmian jest dużo, to aplikacja na produkcji nie działa bardzo często.

• Zmiana na produkcji z założenia jest obarczona ryzykiem, że coś się wyrypie. Jeżeli coś ma się wyrypać, to wolę mieć taki incydent w poniedziałek rano, zamiast w piątek po południu.

  Natomiast co do samego problemu, który opisujesz, czyli zbyt dużej liczby konfliktów w kodzie, to możliwe przyczyny są następujące:

  • macie źle podzielone odpowiedzialności w kodzie
  • źle planujecie i wielu ludzi grzebie w tych samych rejonach systemu
  • zbyt rzadko robicie merge
  • jest was za dużo w stosunku do wielkości projektu

  I co chyba ważne, dla mnie merge do master/trunk nie jest jednoznaczny z deployem na produkcję.

Tych koflikotow w kodzie az tak duzo nie ma. Troche moze przesadzilem.

Dlaczego uwazasz ze deployment moze zaklocic prace aplikacji? Chodzi Ci o ten moment kiedy zmiany kodu czy migracja jest wdranzana? Chyba nie dokonca rozumiem tego punktu. Moglbys wyjasnic? Dzieki.

Dlaczego codziennie łączycie 10-20 gałęzi? Zgaduję, że dlatego, że każdy programista ma swoją? Może lepiej żebyście tworzyli gałęzie dla danego taska, zamiast dla osoby?

Może jest jakiś program do pokazywania online kto na jakich plikach pracuje? Fajne by to było - automatyczne wykrywanie kto zmienia jaki plik i jeśli dwie osoby mają w IDE zmiany w tym samym pliku to włącza się budzik i można obgadać czy będzie konflikt w pliku czy nie. :D

To wszystko zależy od razmiaru projektu, bo jeżeli 20 osób codziennie pracuje na tych samych 20 plikach to konflikty będą, choćby skały srały.

Ogólnie w miarę podoba mi się wasze flow bo często się łączycie więc zakładam, że nie macie branchy, które długo żyją i są potem problemem. Pierwszą kwestia do poprawy (nie zależnie w jakim kierunku byście chcieli iść) to dodanie chociaż kilku krytycznych testów (najważniejsze funkcjonalności bez których appka nie ma sensu i nie zarabia). Oraz poprawienie pipeline bo 30 minut to jest bardzo dużo nawet na ogromne aplikacje, które rozwija ponad 100 osób

Tak z ciekawości, to na czym polega "build" w PHP? Kiedyś był to język interpretowany i nie za bardzo było co tam budować.