[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

[bareron]

@rosso_corsa: język mordoru :)

[Saly]

@rosso_corsa: nie robisz brancha per środowisko. Robisz jeden główny branch i tyle. Ewentualnie można robić branch per wersja/release, jeśli uważasz, że rozwijanie konkretnej wersji ma sens np. w przypadku bugfixa nie chcesz wrzucać commitów z nowymi ficzerami pomiędzy master a punktem odcięcia tylko same bugfixy

[Saly]

@rosso_corsa: a co do pytania o nadrzędność brancha i co za nim idzie to oczywiście master, gdzie są najnowsze commity

[rosso_corsa]

nie robisz brancha per środowisko. Robisz jeden główny branch i tyle.

@Saly: no to jak a gdzie testy

[Saly]

@rosso_corsa: widzę dwie sensowne strategie:
* masz szybkie i bardzo dobre testy: wtedy odpalasz je dla mastera, jak wszystko działa to idziemy na produkcję, jak się coś zepsuło na prodzie to robimy fixa na mastera i jedziemy od początku
* wolne/słabe testy: robisz brancha z mastera, na nim puszczasz testy, jak wszystko działa to idziemy na produkcję, jak się coś zepsuje to wrzucam fixa na mastera i testuję, potem jakoś próbuję

[S.....i]

@rosso_corsa: feature branch <> RC/QA > prod

[KORraN]

@rosso_corsa: No testy na głównym branchu. U mnie jest sobie np. branch release/2.2.0, do niego jest wszystko mergowane, wersja 2.2.0 wydana - leci merge release/2.2.0 -> master.

[f.....n]

@rosso_corsa: Testy na kodzie, który pójdzie na produkcję. A żeby testy miały sens, to musisz mieć ten sam kod na środowisku testowym co na produkcyjnym. Nie ma sensu robić innego brancha, kiedy kod się nie zmienia.

[rosso_corsa]

Testy na kodzie, który pójdzie na produkcję

@fazonun: no ale wlasnie gdzie te testy

[bin-bash]

@rosso_corsa:

[f.....n]

@rosso_corsa: Na środowisku testowym. Co ma do tego zarządzanie wersjami?

[Saly]

@bin-bash: git flow to IMO przeszłość, nawet dołączony link do tego obrazka mówi, żeby użyć czegoś prostrzego

[bin-bash]

@bin-bash: git flow to IMO przeszłość, nawet dołączony link do tego obrazka mówi, żeby użyć czegoś prostrzego

@Saly: ale co tam jest skomplikowanego? najbardziej przejrzysty dla mnie sposob :-) no chyba, ze ktos ma posty projekt i sam sobie cos klepie to spoko, wystarczy master tylko i ficzer branche.

czesto tak mam, ze zaczynam robic wersje np 1.5 i zanim przejdzie UATy to juz zaczynam 1.6, czyli osobne release branche

[Strus]

@rosso_corsa: master + release branche. Testy są na relese branchu po jego wyodrębnieniu i tyle.

Testy automatyczne to oczywiście do każdego PR + dłuższe po każdym merge do mastera + nocne długie też z mastera.

[Saly]

ale co tam jest skomplikowanego? najbardziej przejrzysty dla mnie sposob :-) no chyba, ze ktos ma posty projekt i sam sobie cos klepie to spoko, wystarczy master tylko i ficzer branche.

@bin-bash: generalnie krytyka jaką słyszałem to dużo branchy i narzut związany z mergowaniem/rozwiązywaniem konfliktów. No i największa IMO wada to brak jednego single source of truth w postaci mastera tak jak to jest TBD. Oczywiście taka strategia to też inne

[bin-bash]

@bin-bash: generalnie krytyka jaką słyszałem to dużo branchy i narzut związany z mergowaniem/rozwiązywaniem konfliktów. No i największa IMO wada to brak jednego single source of truth w postaci mastera tak jak to jest TBD. Oczywiście taka strategia to też inne pisanie kodu, bo np. trzeba się posiłkować feature togglami ale z dwójki złego to chyba wolę iść w tą stronę

@Saly: przeciez wydania sie robi zawsze z mastera, jaki wiec

[Saly]

@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.

[mirasKo-Kalwario]

@KORraN: @bin-bash: @Strus: @Saly: @rosso_corsa: po co tak kombinować? robisz feature brancha, przed mergem testujesz, mergujesz do mastera, po mergu testujesz to co jest w masterze, 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, strategia robienia tagów może być różna albo po każdym mergu do mastera albo gdy ktoś potrzebuje (np na