Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: mmcc 19. 10. 2022, 21:39:50
-
Mozno trochu zaciatocnicka otazka. Na korporatny team (v tom teame som par mesiacov), ktory sa zaobera hlavne operations a SRE, prisla poziadavka spravit mensiu, jednoduchsiu app s rest api, v pythone, beziacu na AWS services. Na tento task sme dvaja, mame to viacmenej "na kolene" funkcne. Ale okrem toho je v tom aj komunikacia so zakaznikom (s inym teamom), analyza, navrh infrastruktury na AWS, cely CI/CD pipeline (unit testing, gitlab-ci, terraform pre automaticky deployment, dokumentacia).
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.
Ako mate podelene ulohy v teamoch? Unit testy pisete sami na svoj kod, alebo ich pise kolega, iny team? tak isto aj gitlab-ci, terraform a vsetko vyssie spomenute.
-
tay jsem v 3 clenem tymu, 2 prgaci a jeden tester. s takovym poctem lidi zakaznik nemuze cekat zadne rychle zazraky.
nemuzete z vedeni vymamit aspon nejakeho manazera/scrum majstra/komunikatora co pomuze se zakaznikem? je uloha vedeni mit plan zajistit dohled nad projektem obecne prgac neni manazer.
prgaci zvladnou prgani i devops, ale prace se zakaznikem, to uz by me nebavilo.
-
Jsme větší korporace a v týmu máme 6 lidí:
1 product owner
1 vývojář
1 sre
1 data guru
1 software analytik
1 tester
Bez sre to vázlo, protože devops dělal vývojář a jelikož infrastruktura byla dost poruchová, tak na skutečný vývoj nezbývalo dost kapacity.
IMHO pokud nemáte kapacity a kompetence na všechny oblasti, tak byste měli poptávat expertýzy od zkušenějších skupin v korporaci. Částečná komunikace vývojáře se zákazníkem IMHO nevadí, ale jen tam kde si mají co říct (vývojář by neměl dělat management).
-
a jako prgaci to hrotte k vedeni, aby videli, ze je to pruser a aby samo vedeni bylo nuceno neco delat. treba kdo zajisti ucty na cloudu, kdo urci jake instance se objednaji, jaky vykon muzeme zadat, co je pro zakaznika priorita, to vubec neni starost prgacu a musite vedeni v tom vymachat pysk.
-
Jsme větší korporace a v týmu máme 6 lidí:
1 product owner
1 vývojář
1 sre
1 data guru
1 software analytik
1 tester
A mate to v tomto pomeru? Moje zkusenost je jina, spis blize k necemu
0,25 PO
0,15 scrum master
4,00 DEV
1,00 tester
....
-
Jsme větší korporace a v týmu máme 6 lidí:
1 product owner
1 vývojář
1 sre
1 data guru
1 software analytik
1 tester
A mate to v tomto pomeru? Moje zkusenost je jina, spis blize k necemu
0,25 PO
0,15 scrum master
4,00 DEV
1,00 tester
....
vyvojar, data guru, analytik v tak malem tymu proste musi prgat.
-
a jako prgaci to hrotte k vedeni, aby videli, ze je to pruser a aby samo vedeni bylo nuceno neco delat. treba kdo zajisti ucty na cloudu, kdo urci jake instance se objednaji, jaky vykon muzeme zadat, co je pro zakaznika priorita, to vubec neni starost prgacu a musite vedeni v tom vymachat pysk.
Predplatenych systemovych zdrojov na AWS je viac nez dost. Na tak malom projekte su naklady zanedbatelne, tato tema odpada.
Z ostatnej debaty som usudil, ze unit testing, pripadne gitlab-ci je v kompetencii dev prog. Terraform(S3,Lambda,Glue,Athena,API GW, IAM,..) nechce sa mi este aj do toho.
Teraz este otazka z pohladu testera (s testovanim sa tiez len zoznamujem). Ako mate nastavene pravidla pre odovzdavanie kodu testerom? Npr kolega mi dal jeho kod na napisanie unit testov, ale bez dokumentacie vstupov, vystupov, ze "to ti vysvetlim". Kod vo velkej miere netestovatelne "spaghetti", vratil som mu to nech to upravi do testovatelnej podoby, rozbije do mensich metod. Nebol z toho nadseny :)
Tester doslova lusti kod a algoritmy aby vedel co ma byt na vstupe, co na vystupe? Ci vsetci pisete tak cisty, jednoduchy kod, ze je to z neho hned jasne? Tiez je vo zvyku, ze tester upravuje/preraba kod po programatorovi, ci len mu ho vrati s reportom z testu?
-
Tester doslova lusti kod a algoritmy aby vedel co ma byt na vstupe, co na vystupe? Ci vsetci pisete tak cisty, jednoduchy kod, ze je to z neho hned jasne? Tiez je vo zvyku, ze tester upravuje/preraba kod po programatorovi, ci len mu ho vrati s reportom z testu?
Tak testy by mali vychadzat zo zadania, nie z implementacie, inak su zbytocne. Casto su napisane este pred implementaciou zadania.
Testy by mali prebehnut po merge requeste. Ak nedopadnu dobre, tak to nejde mergnut a autor to musi opravit.
Ale chce to v teame niekoho kto by bol realne schopny robit analytika/architekta a rozumie tomu.
-
testera by lo zajimat jen api na napsani testu, jak si to zkazili uvnitr je vec code review.
-
Unit testy jsou odpovednost programatoru. Tester pise automatizovane integracni / E2E testy.
-
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.
-
Programuju komerčně už přes 25 let, ale že by unit testy dělal jiný člověk, než ten kód, s tím jsem se ještě nesetkal. V určitých případech by to smysl dávat mohlo - například když by zadání bylo tak jasné, že by se daly napsat předem. Pak by je třeba mohl napsat zadavatel/senior a následně nechat na juniorovi, ať napíše implementaci. Nicméně aby unit testy dělal někdo jiný ex-post podle kódu, to mi nedává vůbec smysl.
Co se týče původního dotazu: Za mě jsou vývoj a operations (včetně devops) dva obory. Je samozřejmě možné, aby je dělal jeden člověk, ale je to skoro vždy na úkor kvality obou. Podobně, jako když je někdo fullstack programátor.
-
Jsme větší korporace a v týmu máme 6 lidí:
1 product owner
1 vývojář
1 sre
1 data guru
1 software analytik
1 tester
A mate to v tomto pomeru? Moje zkusenost je jina, spis blize k necemu
0,25 PO
0,15 scrum master
4,00 DEV
1,00 tester
....
Nemáme to 1:1 Podstatné ale je, že tam jsou ty role vůbec zastoupeny.
-
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...
-
Jsme dva vývojáři, senior a junior. Plus tester. Plus ještě máme nad sebou člověka, který prioritizuje a komunikuje s vedením.
Jako vývojáři děláme všechno od kódu, po architekturu a správu serveru, nasazení, etc. Když vedení něco nutně potřebuje, snažíme se vyhovět. Po nasazení na test a na produkci tester testuje. (Ne unittesty samozřejmě. Ty jsou naše práce.)
Nemáme to nijak striktně rozdělený - maximálně v tom, že junior dělá tu hrubější práci, a senior vymejšlí extrabuřty. Sedlo si to samo.
Vedení chápe, že jde co jde. Bylo jim to vysvětleno. Je soudné.
Přímo k otázce:
Může to mít výhody, kde se specializuje. Ale jde to klidně i v jednom ve dvou. Problém obvykle bývá skill a čas.
Nepřímo k problému:
Dělat na aplikaci měsíc a nemít žádné výsledky je psychologická chyba. Nemůžeš mít vedení za zlé, že je nervózní. Udělejte pre-verzi, a tu nasaďte, ať vidí, že se neflákáte. Každý měsíc nasazujte novinky. Krmte je podrobnostmi, co jste řešili, jaké velké překážky se objevily, a jak jste je řešili, co vás aktuálně čeká. Pokud chtějí krmte je každé pondělí. Pokud nechtějí krmte je měsíčně.
-
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...
-
.. 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é!!!)? :D
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.
-
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.
-
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.
-
asi jsem to trochu zamotal ja protoze rozdil "pred MR" vs "pred mergnutim MR"
-
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.