ANT_39: Když dá "request changes", tak žádný další approval ho nepřebije.

AMBIENTIUM: Dava smysl. Napsal jsem programator, ale samozrejme to muze byt uz nekdo driv, kdo rozhodne, co je atomicky z hlediska mergovani. Programator pak resi jen rozdeleni na commity, logickou progresi commitu k nejakymi vysledku, atd.

Ad to CI, muze byt zadouci, aby CI dokazal projit kazdej prefix toho merge requestu. (Jen prvni patch, prvni plus druhy, to plus treti, atd.) Aby pak pri bisekcich nevznikaly ruzny nefunkcni bazmeky co nejdou testovat. Asi zalezi na projektu, u nas bisekce pouzivame celkem pravidelne, tak na to dost dbame.

VOY: Jo, rozbita kultura je prusvih. Nejhorsi jsou code review po telefonu, kdy si dotycni dva neco povykladaji, vysledkem je approval, a nikdo nevi, v cem byl problem, a jak ho autor odargumentoval. V kodu to stopu nezanecha, v mailech / mergovacim nastroji taky ne.

Co se tyce tech testu, nechapu, jakou to tu hraje roli. OK, mate noisy testy, to prece nikoho neomezuje v tom, co vrazi do merge a jak ho rozdeli na commity, ne?

VOY: To je kec, já taky dělám na frontendu. Práce samozřejmě rozdělit na commity lze stejně jako kdekoliv jinde. Je pravda, že nějakou feature pak mezi větvema merguju jako velký balík, ale mám ji stejně rozdělenou do zvládnutelných commitů.
Nerozumím souvislosti s e2e testy. Ano, jsou drahý, ale pokud je máš nespolehlivý, tak je rovnou zahoď. Na rozdělanou práci logicky nepíšeš e2e testy. Pokud máš nějaké náhodné pády v E2E testech, je to typicky buď chyba spojení (nám se stává poměrně málo, máme i retries) nebo máš chybu v testech.

ANT_39: u nás jsou malý PR daný už při analýze, kdy ty tasky tvoříme a zapisujem do Jiry. Snažíme se jet metodou jeden task = jeden PR. Občas jsou subtasky a PR se dělá na každej subtask. Děláme to tak, aby po zamergování se to mohlo ihned releasnout, tzn. musí projít komplet CIčko. Pullrequesty jsou pak fakt docela malý. Obvykle se vejdeme do 300 řádků změn nebo novejch. Ano, trávíme víc času na analýze a promýšlíme to docela do detailu, ale osvědčilo se to.

ANT_39: Zcela s tebou souhlasim, ale bohuzel v praxi tam kde pracuji ja (na frontendu) tohle neni casto dost dobre mozny zajistit, protoze jednak smysluplna zmena je casto dost velka a i kdyz by se principielne rozdelit dala, tak te treba muzou brzdit drahy a nespolehlivy E2E testy. Dalsi vec je, ze kdyz na to approval nedam ja tak on se nekdo jiny uz najde a to je valka co nevyhrajes.

Samozrejme na cokoliv se da namitnout, ze proces se da zlepsit, ale to je jednak ve velky firme beh na dlouhou trat, druhak sem jeste ve svem zivote nevidel ani neslysel o firme, kde by frontendovy integracni testy fungovaly rychle a bez nutnosti je sem tam restartovat, aby prosly.

Ale jak rikam, mluvim ze svoji specificky perspektivy na frontendu, v zavislosti na tom v jake oblasti delas to muze byt lehci.

VOY: no ale v takovým případě pak už ani nemá smysl dělat peer review u těch malých změn ;)

KOLCON: Tady podle me hodne zalezi v jaky zemi a mezi jakejma subjektama, v mym sektoru se pojisteni b2b skod dela bezne a naopak korporaty od dodavatelu to pojisteni dost casto vyzadujou

E2E4: To nevím... Když jsem kdysi zjišťoval to pojištění v b2b, byl to problém. Pojišťovny v tom viděly velké riziko, že se firmy mezi sebou domluví. Možná se situace změnila a jak to je u fyzických osob netuším.

Řešil jsem to pro situace v automotive kde když zastavíš linku, může být každá minuta drahá.

KOLCON: čéče nevím, nexistuje pojištění statutárních orgánů fyzických osob za totéž?

DWICH: Na byznys škody (druhotné) tě imho nikdo nepojistí.