[rosso_corsa]

mamy rozkmine w robocie w zwiazku z czym mam pytanie, w jaki sposob prowadzicie brancze u siebie w wypadku gdy jest oprocz prod wyodrebnione ssrodowisko qc. jest qc i master idzie za qc czy qc idzie za masterem? #programowanie #programista15k

[bin-bash]

@bin-bash: chodzi mi o sytuacje, gdy mój kolega pracuje nad ficzerem A a ja nad ficzerem B i obaj zmieniamy ten sam kod. W przypadku TBB jest taka doktryna, że mergujemy do mastera jak najczęściej i jak najmniejsze kawałki kodu przez co ten problem jest minimalizowany.

@Saly: a jak chcecie hotfixa z prod to co robicie?:) wydajecie wtedy z mastera?:D czy revertujecie wasze zmiany? a moze tworzycie nowego brancha z

[Strus]

jak ktoś chce wdrożyć to robi taga (na tagu można kolejny raz puścić testy) i tag jest automatycznie (albo ręcznie) wdrażany i tyle

@mirasKo-Kalwario: Release branch ma tę przewagę, że jak po releasie sie okaze, ze musisz zrobic jakis hotfix, to robisz po prostu cherry pick do release brancha. Jak releasujesz z mastera na bazie tagów i nie chcesz jednocześnie zreleasować wszystkie między ostatnim tagiem a commitem z fixem, to masz

[bin-bash]

@mirasKo-Kalwario: musisz pracowac w bardzo malej firmie albo sam sobie cos klepiesz do githuba :D Merge do mastera robisz dopiero gdy przygotowujesz release a nie na testy, ktore mogra potrwac i miesiac

[bin-bash]

@bin-bash: chodzi mi o sytuacje, gdy mój kolega pracuje nad ficzerem A a ja nad ficzerem B i obaj zmieniamy ten sam kod. W przypadku TBB jest taka doktryna, że mergujemy do mastera jak najczęściej i jak najmniejsze kawałki kodu przez co ten problem jest minimalizowany.

@Saly: no dobra, a rozwiazanie z tym flow co wkleilem w czym to utrudnia? swoje ficzer branche tez mozecie mergowac co godzinke nawet do

[mirasKo-Kalwario]

@Strus: to co masz w masterze jest ready to deploy potrzebujesz zrobic hotfixa robisz na masterze, tagujesz i wdrażas`z

[mirasKo-Kalwario]

@bin-bash: pracuje i pracowałem w dużych firmach poprostu trzeba mieć dobrze poukładane repo i zespoły tak aby każdy zespół utrzymywał produkt który skłąda się z kilku repozytoriów, jak masz burdel w repo to nic nie poradze

[bin-bash]

@Strus: to co masz w masterze jest ready to deploy potrzebujesz zrobic hotfixa robisz na masterze, tagujesz i wdrażas`z

@mirasKo-Kalwario: ale sam mowisz, ze tetsujesz co jest w masterze te swoje ficzery:D a wiesz, ze testy akceptacyjne moga trwac miesiace? mam wrazenie, ze mowisz o jakims swoim prostym projekcie gdzie to ma sens i sprawdza sie w 100% Ile masz srodowisk testowych? ile wersji jednoczesnie oddajesz na UATy?

[mirasKo-Kalwario]

@bin-bash: co? testy mają trwać max kilka minut, kwestia dobrego podziału na repozytoria i mikroserwisy / paczki - testujesz tylko to co zmieniasz i to czego twoja zmiana dotyczy

[Strus]

to co masz w masterze jest ready to deploy potrzebujesz zrobic hotfixa robisz na masterze, tagujesz i wdrażas`z

@mirasKo-Kalwario: To gdzie trzymasz zmiany dla nowej wersji, skoro według Twojego opisu masz tylko mastera i feature branche? Bo według tego opisu to między releasem jednej wersji a tym hotfixem nic nowego nie wejdzie do repo, co jest nierealne w żyjącym projekcie.

Już nie mówię o tym, że rolling release może trwać 2-3

[mirasKo-Kalwario]

@bin-bash: już nie mowie o tym zę jak coś się psuje to mozesz zrobic rollback do działającej wersji i przygotować na spokojnie fixa, jak masz taga praktycznie codziennie albo co feature bo często wdrażasz to jest malo rzeczy ktore mozesz wdrozyc przypadkiem

[bin-bash]

@bin-bash: co? testy mają trwać max kilka minut, kwestia dobrego podziału na repozytoria i mikroserwisy / paczki - testujesz tylko to co zmieniasz i to czego twoja zmiana dotyczy

@mirasKo-Kalwario: lol. A wiesz, ze testy jednostkowe, integracyjne i e2e to nie wszystko :D nadal mam wrazenie, ze mowisz o jakims prostym projekcie. Wiesz co to testy UAT, gdy masz dostac swiatelko od biznesu, ze to wdrazacie? Ty myslisz, ze jak

[mirasKo-Kalwario]

@Strus: no to cos jest nie tak w twojej firmie, pracowalem dla najwiekszych bukmacherów, portalów mediowych, monopolisty aukcyjnego i nigdzie nie bylo tego problemu bo robilismy czeste i male zmiany i wdrozenia

[bin-bash]

@Strus: no to cos jest nie tak w twojej firmie, pracowalem dla najwiekszych bukmacherów, portalów mediowych, monopolisty aukcyjnego i nigdzie nie bylo tego problemu bo robilismy czeste i male zmiany i wdrozenia

@mirasKo-Kalwario: i co, ktos to dopiero klikal na produkcji po Twoich testach integracyjnych?:D ja robilem w kilku bankach i kilka korpo najwiekszych

[Strus]

@mirasKo-Kalwario: To co jest nie tak to Twoje przekonanie, że programowanie to tylko aplikacje webowe/strony. Ja robię desktop, tutaj release są rzadkie, trwają długo, bo są stopniowe, a testy trwają też długo, bo nie zabierzesz niedziałającej aplikacji z komputera użytkownika jak coś zepsułeś, tylko musisz wypuścić nową wersję.

[mirasKo-Kalwario]

@bin-bash: nie mialem projektu gdzie smoke testy, e2e itd trwaly dluzej niz godzine, wystarczy czesc rzeczy zrównoleglić, tak jak mówie pracowalem w firmie z 500 mikroserwisami raczej rzadko zdarzalo się wiecej niz 2-3 merge do mastera w jednym mikroserwisie bo tak dzielilismy sie pracą żeby każdy pracował nad innym kawalkiem i nie było z tym żadnych problemów. Rozumiem że ajk utrzymujesz jakies wielkie BBOM albo wielki monolit w zabetonowanym banku to

[mirasKo-Kalwario]

@bin-bash: mielismy rozne opcje do wdrazania rzeczy ukrytych za feature flagą i po przetestowaniu manualnym ją włączalismy albo rozwiazanie gdzie ustawiasz naglowek i wchodzisz do appki i laczysz się do innego backendu jak wszystko ejst ok to przestawiasz na niego ruch, klucz to male zmiany ktore szybko testujesz a nie wielkie releasy po milion commitow ktore sie testuje miesiacami

[Saly]

no dobra, a rozwiazanie z tym flow co wkleilem w czym to utrudnia? swoje ficzer branche tez mozecie mergowac co godzinke nawet do release brancha, ktorego przygotowujecie

@bin-bash: większy problem widzę w procesie releasu. W TBD release idzie z mastera (czyli developa w nomenklaturze git-flow) i polega on na zwykłym odcięciu ostatniej wersji. Taki branch jest statyczny i nic tam się nie dzieje: jedynym wyjątkiem są hotfixy, który są przeciągane z

[RapIArbuzy]

Ty myslisz, ze jak robisz soft ktory ogarnia miliony $ to idzie na prod ot tak bez weryfikacji zawsze z jakiegos stagingu/qa?

@bin-bash: Akurat praktyka continuous deploymentu oraz chaos engineeringu to jest stosowana przy takie skali że miliony $ to drobne. A tak poza tym co firma, to inny proces releasów i podejścia do testów - nie ma złotego środka.

[rosso_corsa]

po co tak kombinować? robisz feature brancha, przed mergem testujesz

@mirasKo-Kalwario: tylko ze mamy kilkadziesiat mikroserwisow i tako sobie nie przetestuje lokalnie jakiegos jedneo projektu. musi byc testowany na qc, ktory chyba dziala rownolegle do prod, do konca nie wiem jak to dziala

[mirasKo-Kalwario]

@rosso_corsa: jak masz dobrze infrę zrobioną to przetestujesz tak czy siak merge do master = automatyczny deploy na stage / preprod czy jak tam to nazywasz i tam mozesz psuc i testować do woli

Ja robię desktop

@Strus: tutaj się zgodzę desktop i appki mobilne to troche bardziej skomplikowany biznes i rzeczywiście tutaj pasuje robić release branche i ciągnąć kilka gałęzi z fixami mam nadzieje że przynajmniej dobrze ci płacą