Rozdělení úloh v týmu: vývoj, testování, CI/CD

[xPoli]

Testy by mali prebehnut po merge requeste. Ak nedopadnu dobre, tak to nejde mergnut a autor to musi opravit.

PRED. Testy musi kompletne projit PRED mergem. To co jsi napsal nedava smysl.

Povedz si to este raz pomaly nahlas - "merge request" - "merge". Ak stale ostane zhasnute, tak opakuj...

Moje zkušenost ve "formálnějším" prostředí je taková, že aby vůbec bylo možné udělat merge request, musí být splněný checklist. Checklist obsahuje mimo jiné to, že to projde testy, že to prošlo přes code review atd. Připomínka od to_je_jedno je v tomto rámci naprosto namístě. Setkal jsem se i s tím, že checklist nebylo třeba splinit u commitů, jejichž message začíná na "WIP:", kde se větší featura rozdělí třeba na více commitů, aby byla v několika commitech zdokumentovaná cesta a důvod velkých změn. Jenže na takový commit zase není možné uvalit merge request...

[Reklama]

[L..]

.. aby vůbec bylo možné udělat merge request, musí být splněné ... že to prošlo přes code review ...

Eh?!?!?! Vždyť to code review se dělá právě v tom merge requestu. To je nějaká korporátní Hlava XXII, že aby mohl být merge request, musí být hotové code review, ale aby se mohlo dělat code review, musí být merge request, takže nikdo nemůže nic zamergovat (a je to super bezpečné!!!)?

Možná by bylo dobré si ujasnit, o jakém systému se tu bavíme. Ale klasicky v GITu se merge requesty dělají z (feature / bugfix) branche do nějaké jiné branche (release / main / master / ...), ne z commitů. Do své branche si mohu commitnout, co chci - někdy jsou nastavené git hooky, které nepovolí commitnout kód, co neprojde lintem / testy, ale to je spíš convenience pro vývojáře, aby se nestávalo, že commitnou a pushnou kód a o půl dne později zjistí, že jim vlastně neprochází testy. Ty hooky se dají když tak při commitu vypnout, aby bylo možno pushnout kód a ten nehnil rozdělaný na vývojářově stroji.

[Death Walker]

Moje zkušenost ve "formálnějším" prostředí je taková, že aby vůbec bylo možné udělat merge request, musí být splněný checklist. Checklist obsahuje mimo jiné to, že to projde testy, že to prošlo přes code review atd. Připomínka od to_je_jedno je v tomto rámci naprosto namístě. Setkal jsem se i s tím, že checklist nebylo třeba splinit u commitů, jejichž message začíná na "WIP:", kde se větší featura rozdělí třeba na více commitů, aby byla v několika commitech zdokumentovaná cesta a důvod velkých změn. Jenže na takový commit zase není možné uvalit merge request...

K akemu ucelu potom vo vasom "formalnejsom" prostredi sluzi "merge request"?

Pri merge requeste nejde o fyzicke zlucenie vetvi. Je to zalezitost gitlabu (github, bitbucket ma pull request), nie samotneho gitu. Aby to bolo funkcne tak ten merge request musi reflektovat aj commity poslane do branche po vytvoreni merge requestu (opravy, upravy, etc), a aj tie musia prejst checklistom. Ak je check list splneny, tak ten kto ma na to prava merge request dokonci - prebehne samotne merge.  Dokonca v niektorych pripadoch mozu testy v CI fronte prebehnut aj po merge, realne hotovo je az vtedy, ked sa zavola push.

[kanoe22]

xpoli si tu podla mna myli merge request a merge samotny.

Merge request je proste kolekcia vsetkych aktualnych zmien na branchi voci branchi do ktorej sa to bude mergovat plus v zavislosti od pouzivaneho systemu su tam rozne dalsie veci, ale minimalne je tam moznost davat review komenty, je moznost vidiet jednotlive commity a je tam nejaky ci/cd tab kde vidno ci zbehla kompilacia, testy, ....,  v pohode.

Merge samotny je akcia, vykonava sa (vo webovom rozhrani) kliknutim na tlacidlo merge a zluci dve branche do jednej a vacsinou znovu pusti celu ci/cd paradu, nech sa vidi ci to zbehlo OK.

[to_je_jedno]

asi jsem to trochu zamotal ja protoze rozdil "pred MR" vs "pred mergnutim MR"

[Reklama]

[mark42]

Toto je podstatna cast:

Vedenie sa uz zacina ozyvat, ze nam to dlho trva. Obom nam to prerasta cez hlavu, v teame nieje nikto, kto by nas zorganizoval, "orchestroval", obidvaja mame viacmenej programatorske skusenosti. S devops, automatizaciou a trochu aj s aws sa trapime.
Na jednej strane je to dobra prilezitost rozsirit si znalosti, ale momentalne mam pocit, ze je to nad ludske sily zvladat toto vsetko v jednej osobe.

Riesenie:

• Zodpovednosti - musite mat jasne urcene, kto za vas SW zodpoveda v suvislosti s "vedenim". Zvycajne je to vas priamy nadriadeny, pripadne niekto urceny samotnym vedenim. Asi za vami nechodi CIO/CEO s otazkou, ci to uz mate hotove a kedy to bude. Ak nahodou ano, pri dalsej navsteve si vypytajte projektoveho veduceho alebo scrum mastera alebo niekoho, kludne len na 20% casu. Argumentujte, ze o tento neproduktivny cas budete rychlejsi vo vyvoji aplikacie. Co sa tyka samotneho timu, bud si rozdelite roly alebo pojdete do toho agilne, v mensom pocte ludi je podla mna lepsia ta agilita. Proste zo zoznamu taskov si kazdy vytiahne, co bude robit a ak sa zasekne, tak poziada o pomoc, vid dalsi bod.
• Komunikacia - musite mat plan, co idete robit (ci v nejakom agilnom taskovniku ako Jira, v tabulke alebo v zdielanom TXT subore, to je jedno), musite mat zoznam toho, co ste urobili a ukazovat zodpovednemu z prveho bodu. Dalej vnutro-timova komunikacia + poziadavky na okolite timy - ak potrebujete pomoct s nastavenim CI/CD alebo AWS zavolajte si na par hodin niekoho, kto vam pomoze sa z toho vyhrabat. Hlavne necakat, kym problem necinnostou vykvasi na nieco skarede. Zodpovedny z prveho bodu vam s tymto pomoze. Komunikujte, co ste urobili za aktualny tyzden a co planujete buduci tyzden.
• Zadanie - plan v predchadzajucom bode vznika na zaklade zadania, resp. nejakych uloh, ktore mozu postupne pribudat. Treba ich mat rozdelene na zaklade obtiaznosti a priority, aby ich zodpovedny z prveho bodu vedel prehladne komunikovat a hlavne aby ste si ich vedeli medzi sebou rozdelit.
• Vyvoj  a testy - ak je to len trochu mozne, vyvojar pre nejaku cast zadania urobi na zaklade zadania najprv unit testy, ktore samozrejme neprejdu, lebo dana cast kodu este neexistuje. Okrem standardneho spravania treba pokryt aj rozne chybove alebo hranicne stavy - tu sa moze stat, ze bude potrebne spresnit zadanie. Nasledne vyvinie kod, ktory bude funkcny + prejde testami. Na integracne a akceptacne testy je vhodne mat separatneho testera, ktory ten kod nevytvoril, ale vie podla rozhrani vasu aplikaciu prepojit s okolim. Ak vam okolnosti neumoznuju toto urobit, minimalne si vytvoreny kod navzajom revidujte a testujte. A nebojte sa vytvoreny kod prepisovat casto - aby bol lepsi a zrozumitelny.