Jak posunout vývojáře k CI/CD

Ink

  • ****
  • 323
    • Zobrazit profil
    • E-mail
Re:Jak posunout vývojáře k CI/CD
« Odpověď #45 kdy: 28. 01. 2021, 20:52:25 »
Pokud programuje, pořád je to programátor, byť na part time. A furt je to zaměstnanec, takže má sklapnout krovky a dělat práci pořádně, pokud ho k tomu někdo vyzve.
Zkuste podobnou logiku aplikovat třeba na pozici "údržbář" versus kvalifikace "instalatér", "truhlář", "elektrikář", "čalouník", "pokrývač", "zedník", "štukatér" - abyste viděl jakou absurditu píšete.

Nebudu nic na nic aplikovat. Zfušovaná práce je zfušovaná práce.


Kit

  • *****
  • 594
    • Zobrazit profil
    • E-mail
Re:Jak posunout vývojáře k CI/CD
« Odpověď #46 kdy: 28. 01. 2021, 22:04:11 »
Ako som precital diskusiu tak ja som situaciu takto pochopil:

To nie su programatori. To su ludia ktorych napln prace je nieco ine a su schopny nejake percento casu dajme tomu 30% (alebo nedajboze dokonca vo volnom case) venovat programovaniu a napisat nejaku utilitu pre firmu. Ak je to takto tlacit ich do gitu ked to nechcu imho nema zmysel. Ak chcete git,ci/cd najdite si fulltime vyvojara.

Verzování používají i spisovatelé, kteří programování neviděli ani z dálky.

Re:Jak posunout vývojáře k CI/CD
« Odpověď #47 kdy: 28. 01. 2021, 22:53:15 »
"Verzování používají i spisovatelé, kteří programování neviděli ani z dálky."

no byl jsem nucen do gitu verzovat i binarni soubory (dll), neni to pekne, ale jde to a clovek
se muze vratit ke vsem verzim.

Re:Jak posunout vývojáře k CI/CD
« Odpověď #48 kdy: 28. 01. 2021, 23:20:56 »
Uz to tu niekto pisal. Ti programatori si urcite uvedomuju uzitocnost gitu a CI tam problem nebude. Problem je, ze nechcu aby niekto videl ako moc (ne)pracuju.
Toto je problem vo firmach kde programovanie nieje hlavnou cinnostou takze do toho nikto nevidi a "programator" moze bastlit nejaky svoj PHP skript s reportom mesiac a tvrdit ze "na tom pracuje", "vyskytli sa problemy bude to trvat dlhsie" a podobne.

Kit

  • *****
  • 594
    • Zobrazit profil
    • E-mail
Re:Jak posunout vývojáře k CI/CD
« Odpověď #49 kdy: 29. 01. 2021, 00:07:28 »
Uz to tu niekto pisal. Ti programatori si urcite uvedomuju uzitocnost gitu a CI tam problem nebude. Problem je, ze nechcu aby niekto videl ako moc (ne)pracuju.
Toto je problem vo firmach kde programovanie nieje hlavnou cinnostou takze do toho nikto nevidi a "programator" moze bastlit nejaky svoj PHP skript s reportom mesiac a tvrdit ze "na tom pracuje", "vyskytli sa problemy bude to trvat dlhsie" a podobne.

Na mne to funguje obráceně. Commit je pro mne výkazem práce, který nemusím vymýšlet. Prostě uvedu, co jsem v tom konkrétním případě udělal. Klidně si předtím udělám i diff. Nějak mě to víc baví, když si udělám takovou retrospektivu.


Re:Jak posunout vývojáře k CI/CD
« Odpověď #50 kdy: 29. 01. 2021, 07:52:21 »
U nás ve firmě to vypadalo při mém příchodu takto:
- polovina firmy (ta starší) nepoužívala žádný verzovací systém
- druhá polovina používala SVN šíleným způsobem
- CI/CD v podstatě neexistovalo, pár projektů bylo v tehdy už brutálně zastaralé verzi Hudson

Byl to tvrdý a těžký boj. Vyhodil jsem SVN a nasadil self-hoste Gitlab. Vyhodil jsem Hudson a nyní máme pravidelně aktualizovaný Jenkins.

Naučit pár starších kolegů základní Git workflow a vůbec to myšlení byl boj. Někteří dělali zálohování prostým kopírováním zdrojáků, když se objevil neřešitelný problém, obnovil kolega zálohu daného souboru, kterou našel atp.

Masakr byl, že po nasazení Gitu kolega stále dělal i své souborové copy-paste zálohy a když se mu něco v pracovní kopii nezdálo, prostě soubor přepsal svou chytrou zálohou, což dělalo strašné harakiri při různém mergování atp. Už se zlepšil.

V podstatě neexistovala rozumná "štábní kultura" ohledně formátování kódu, konvencí pojmenování proměnných atp. Neexistovala standardizovaná cesta, jak generovat instalátory našich produktů, neexistovala cesta, jak nové verze dostávat spolehlivě k zákazníkům.

Firemní web byl šíleně napsán v Silverlightu -> přešlo se na ASP.NET a máme funkční web za který se nemusíme moc stydět.

Nyní jdou dělat věci, co předtím kolegové dělat nemohli. Můžeme přesně dohledat každou individuální změnu, zavedl se ticketovací systém (v Gitlabu), každý má 100% přehled o tom, jaké bug-fixy po něm ostatní chcou.

Celá tahle epopej byla osvobozující.

Re:Jak posunout vývojáře k CI/CD
« Odpověď #51 kdy: 29. 01. 2021, 08:03:11 »
Jenže on tu svou práci nechce přehodit na lidi, ale na stroje. S tím, že i ti lidé z toho budou mít užitek.
Tak když to budou dělat stroje tak proč je tím obtěžuje. Pokud MUSÍ věnovat tomu navíc 1 sekundu je to něco NAVÍC co předtím nedělali. SÁM AUTOR PŘIZNÁVÁ, ŽE SI CHCE ULEHČIT PRÁCI A POKUD DRUZÍ BUDOU KVŮLI TOMU DĚLAT I 1 SEKUNDU NAVÍC A TO SAMOZŘEJMĚ ZABERE MNOHEM VÍCE ČASU PAK JEDNODUŠE CHCE SVOU PRACÍ PŘESUNOUT NA NĚ.Je to skutečně tak jednoduché. A ty technobláboly jsou jenom kecy okolo. Možná to je ten důvod proč já podnikám a ty jsi zaměstnancký otrok, protože s tebou každý vyjebe za pomocí těchto bullshit keců.

Pokud použiji analogii, pak je to stejné jako kdybych po každém v kolektivu chtěl 5000 kč a obhajoval to, že se všichni budeme mít lépe, což je lež neboť JÁ se budu mít lépe, a ostatní o peníze přijdou.

Kdyby tazatel nebyl slaboduchý blbec vymyslel by efektivnější řešení bez nutnosti zbytečně práce lidí okolo se stejnými výsledky. Smyslem IT bylo vždy ulehčit, ušetřit čas a nikoliv věnovat tomu více času. POKUD NA TO MUSÍ NĚKDO MYSLET A VĚNOVAT TOMU 1 a více sekund je to ŠPATNÉ(NEVHODNÉ) ŘEŠENÍ. Tak jsme to vždycky dělaly a měli úspěch.

Myšlenka sdílených zdrojových kódů na centrální, lokálním uložišti (s dalšími funkcemi : verzovaní,zálohování apod..) není špatné ale její implemtace blbcem nemusí být vždy kvalitní. A tato implementace tazatelem, zjevně špatné řešení je neboť vyžaduje od starších kolegů práci navíc a té se pochopitelně brání. Jejich postupy mohou být třeba vhodnější(efektivnější) pro jejich způsob práce.

Ink

  • ****
  • 323
    • Zobrazit profil
    • E-mail
Re:Jak posunout vývojáře k CI/CD
« Odpověď #52 kdy: 29. 01. 2021, 08:18:10 »
U nás ve firmě to vypadalo při mém příchodu takto:
- polovina firmy (ta starší) nepoužívala žádný verzovací systém
- druhá polovina používala SVN šíleným způsobem
- CI/CD v podstatě neexistovalo, pár projektů bylo v tehdy už brutálně zastaralé verzi Hudson

Byl to tvrdý a těžký boj. Vyhodil jsem SVN a nasadil self-hoste Gitlab. Vyhodil jsem Hudson a nyní máme pravidelně aktualizovaný Jenkins.

Naučit pár starších kolegů základní Git workflow a vůbec to myšlení byl boj. Někteří dělali zálohování prostým kopírováním zdrojáků, když se objevil neřešitelný problém, obnovil kolega zálohu daného souboru, kterou našel atp.

Masakr byl, že po nasazení Gitu kolega stále dělal i své souborové copy-paste zálohy a když se mu něco v pracovní kopii nezdálo, prostě soubor přepsal svou chytrou zálohou, což dělalo strašné harakiri při různém mergování atp. Už se zlepšil.

V podstatě neexistovala rozumná "štábní kultura" ohledně formátování kódu, konvencí pojmenování proměnných atp. Neexistovala standardizovaná cesta, jak generovat instalátory našich produktů, neexistovala cesta, jak nové verze dostávat spolehlivě k zákazníkům.

Firemní web byl šíleně napsán v Silverlightu -> přešlo se na ASP.NET a máme funkční web za který se nemusíme moc stydět.

Nyní jdou dělat věci, co předtím kolegové dělat nemohli. Můžeme přesně dohledat každou individuální změnu, zavedl se ticketovací systém (v Gitlabu), každý má 100% přehled o tom, jaké bug-fixy po něm ostatní chcou.

Celá tahle epopej byla osvobozující.

Dobrá práce, gratuluju. Překonat mentální lenost a pitomé kecy, proč něco nejde a proč je to zbytečné, to vyžaduje dost energie.

Ink

  • ****
  • 323
    • Zobrazit profil
    • E-mail
Re:Jak posunout vývojáře k CI/CD
« Odpověď #53 kdy: 29. 01. 2021, 08:21:49 »
Myšlenka sdílených zdrojových kódů na centrální, lokálním uložišti (s dalšími funkcemi : verzovaní,zálohování apod..) není špatné ale její implemtace blbcem nemusí být vždy kvalitní. A tato implementace tazatelem, zjevně špatné řešení je neboť vyžaduje od starších kolegů práci navíc a té se pochopitelně brání. Jejich postupy mohou být třeba vhodnější(efektivnější) pro jejich způsob práce.

Nic ve zlém, ale tohle je přesně vohnoutská mentalita, která v rozumně řízené firmě nemá místo. Naučit se pracovat s Gitem není pro průměrně inteligentní opici žádná velká práce a tu produktivitu, kterou naruší pár minut denně věnovaných správě verzí, bych chtěl fakt na vlastní oči vidět. Klidně si na to vezmu i dovolenou, abych spatřil ty efektivní postupy "starších kolegů".

Re:Jak posunout vývojáře k CI/CD
« Odpověď #54 kdy: 29. 01. 2021, 08:37:42 »
...

Nyní jdou dělat věci, co předtím kolegové dělat nemohli. Můžeme přesně dohledat každou individuální změnu, zavedl se ticketovací systém (v Gitlabu), každý má 100% přehled o tom, jaké bug-fixy po něm ostatní chcou.

Celá tahle epopej byla osvobozující.

Díky za trochu naděje ... ;-)

xPoli

Re:Jak posunout vývojáře k CI/CD
« Odpověď #55 kdy: 29. 01. 2021, 09:06:57 »
POKUD NA TO MUSÍ NĚKDO MYSLET A VĚNOVAT TOMU 1 a více sekund je to ŠPATNÉ(NEVHODNÉ) ŘEŠENÍ.

Jejich postupy mohou být třeba vhodnější(efektivnější) pro jejich způsob práce.

Dosud se celá debata odvíjela celkem správným směrem, ale výše citovaný příspěvěk jako celek je podle mě agresivní útok hlupáka. Nejde pro jeden dílčí krok zahodit přínos celé pipeline. Udělat commit v gitu, zvlášť aby k něčemu byl dá určitě víc práce, než na složce se zdrojáky udělat alt+f5 a odzálohovat to někam na server. Git workflow je třeba se trochu naučit, nedělat commit 1x za měsíc, ale ideálně vždy po uzavření nějaké nové/upravené funkcionality, případně i v mezikrocích ("WIP: ..."). To je ta práce navíc. Na druhou stranu to ale lidem může ušetřit spoustu času. Proč se dělala tahle změna? git blame, git log, git diff - aha, proto. A není potřeba se někde prohrabovat zip souborama na sdíleném disku ve firmě a hledat, kdy se tam tohle vlastně dostalo, pokud to vůbec někde je.

Vysvětlit přínos téhle práce navíc jednak vedení a jednak těm vývojářům může být náročný úkol, ale je potřeba argumentovat právě případy, kdy kvůli nějakému pochybení v deploy procesu to ty lidi/majitele stojí násobně víc času. Takhle potom jde třeba odpovědět - nevím, teď nemám čas ti to hledat, najdi si to v gitu a mám klid na další práci.

Z vlastní zkušenost znám případ, kdy majitel firmy vzal notebook nemocného zaměstnance a vezl mu ho domů, aby se dostali k aktuálním zdrojákům a překladu.
Jiná (odstrašující) zkušenost: Zaměstnanec v pracovní době vytvoří něco, co bere jako svoje know-how a nechce ho předat dál. Jakkoliv strastiplnou cestu musel projít a mentální úsilí vyvinout, pořád je to práce zaměstnance pro zaměstnavatele a tak by s tím mělo být nakládáno.

Vztaženo na původní dotaz za mě takto:
Krok jedna - všechny zdrojáky musí do repozitáře, bez debaty, klidně befelem. V první fázi tak jak jsou, klidně i s různými balasty typu vcproj.sln, .cproject a podobně. V tomhle by měl mít tazatel podporu vedení, je to práce zaměstnanců firmy v pracovní době, tedy majetek zaměstnavatele a zaměstnavatel by k tomu měl mít přístup. Částečně se tím eliminuje bus faktor.
Krok jedna a půl - vysvětlit základní git workflow. Návod velkým písmem na A5 max, na to klíčové to stačí. Musí tam být init, add, .gitignore, remote add, commit, reset, push, s velkým varováním commit --amend (pro situace a ještě jsem zapomněl upravit tenhle řádek v readme) s tím, že commit --amend nelze po push, pak už je třeba nový commit a případně stash. S tim si lze běžně vystačit. Podrobnější návod může být k ruce, kde bude návod na řešení dalších základních situací (branch, checkout, clone, pull, merge), ale git cook book na začátek je moc.
Krok dva - tazatel bude postupně automatizovat build systém tak, aby se buildovalo z toho, co je v repozitáři. Ideálně přes dvě větve, kdy do master větve jde jen to, co jde mergovat a zkompilovat, ale jde to i tak, že vše může být v masteru, ale pokud commit message nezačíná "WIP:" musí to jít kompilovat. Následně se nasazují jen verze, které splňují výše uvedené pravidlo, ideálně v help-u těch aplikací je uveden commit (např.
Kód: [Vybrat]
git describe --match=NeVeRmAtCh --always --dirty=M), ze kterého se to sestavilo. Tím se předejde pěti různým verzím aplikace, shodně označeným 1.2. Podmínka kompilovatelnosti zabrání tomu, že se např. v commitu zapomene na nově vyvořené soubory.
Krok tři - postupovat v automatizaci - ideálně každý problém v produkci přetavit v další test, automatizovat reportování chyb z testů zpět vývojářům, zpřísňovat parametry překladu např. -Werror atp.

Štábní kultura zdrojáků s tím sice souvisí taky, ale pokud jsou jednotlivé projektíky one-man-show, pak bych to případně tlačil až v pozdějších fázích.

Jo a nezapomenout na zálohování repozitáře!

Re:Jak posunout vývojáře k CI/CD
« Odpověď #56 kdy: 29. 01. 2021, 09:25:10 »
Kdyby tazatel nebyl slaboduchý blbec vymyslel by efektivnější řešení bez nutnosti zbytečně práce lidí okolo se stejnými výsledky. Smyslem IT bylo vždy ulehčit, ušetřit čas a nikoliv věnovat tomu více času. POKUD NA TO MUSÍ NĚKDO MYSLET A VĚNOVAT TOMU 1 a více sekund je to ŠPATNÉ(NEVHODNÉ) ŘEŠENÍ. Tak jsme to vždycky dělaly a měli úspěch.

Děkuji za chválu, moc potěšila. Doufám, že i Vám udělala hodně dobře.

Já to vidím takto:
Že sjednocení správy zdrojových kódů přinese nějakou práci i vývojářům je jasné. Prostě ten kód musí pushnout do repository (odhad 1-3 min. denně).
Výhodu pro ně samotné to moc mít nebude .... alespoň ze začátku. Pokud jim verzování kódu nepřipadá užitečné teď proč by mělo být v budoucnu jinak, že ...

Pro mne jako toho kdo ty aplikace nasazuje a následně spravuje to bude mít výhodu, že budu moci s aktuálními verzemi dělat testovací instalace a dopředu si testovat (pokud možno automaticky) jestli aplikace se změnou kódu náhodou nepotřebuje jiné nastavení prostředí ... protože když na tohle narazíte při ostré instalaci tak má jak programátor, tak já o práci postaráno, někdy i na několik hodin (vrátit starou instalaci, zjišťovat kde je problém v nové program/prostředí, další pokus-omyl ...). Určitě to neodhalí vše, ale i 30% bude super.
Následně bych chtěl testovat samotný kód jak co do syntaxe tak statickou analýzou a pomáhat/psát pro vývojáře testy, to pomůže nám oběma ...

Pro firmu to má tu výhodu, že znalosti uložené ve zdrojácích jsou pod kontrolou. A pokud se testování pozitivně projeví na spolehlivosti nebo rychlosti nasazení, tak to je jen další plus ...

Re:Jak posunout vývojáře k CI/CD
« Odpověď #57 kdy: 29. 01. 2021, 09:30:50 »
Vlastní zkušenost,
základem je začít používat git, stejně se musí nějak synchronizovat a bez gitu to bude jistě peklo,
pokud se nesynchronizuji a každý jede vlastní projekt tak git jim nijak život nestíží, navíc jeho podpora je dnes v mnoha IDE, a je to jen o tom vysvětli co je ten commit a že když se zavedou commity nemusí se pak vyplňovat v ideálním případě další reporty, případně se už jen sesumíruje to co je v commitech.

CI/CD je tvoje věc jakmile je vše v gitlabu tak tam testy a deploy nastavíš za ně, časem zjistíš že to zkusí skopírovat nebo doplňovat a třeba jim to nejde a zeptají se kde dělají chybu a jak na to aby se jim taky spouštěli testy v novém projektu.

Spousta lidí se toho bojí, ale ono to prostě může běžet bez nich jen ten git stačí používat.



Re:Jak posunout vývojáře k CI/CD
« Odpověď #58 kdy: 29. 01. 2021, 09:38:39 »
Nyní jdou dělat věci, co předtím kolegové dělat nemohli. Můžeme přesně dohledat každou individuální změnu, zavedl se ticketovací systém (v Gitlabu), každý má 100% přehled o tom, jaké bug-fixy po něm ostatní chcou.
My pouzivame bitbucket+jira. Je to sice drahe riesenie, ale vsetky poziadavky idu do jiry, a potom len staci len pri commite dat cislo jiry a system si to prepoji. takze jednym klikom vidime co sa v danom commite riesilo, kto to pozadoval, poziadavky, popis a kedy to chcel.

Pokud MUSÍ věnovat tomu navíc 1 sekundu je to něco NAVÍC co předtím nedělali....
Toto moze napisat len niekto, kto si o sebe mysli, ze vie vsetko najlepsie. Ty vidis len ten 1 commit, nomalny clovek vidi to, ze v pripade problemov vies presne kto, kedy a preco upravoval zdrojak. A nestracas zbytocne cas patranim, ked ti padne produkcia a ty netusis preco.
cize par sekund denne, ked urobis rano pull a vecer push ti v konecnom dosledku usetri hodiny prace a co je podstatnejsie, vies problem odstranit podstatne rychlejsie a neprichadzas tak o zisk, ked ti firma stoji.
Dalsia vec, pokazi/zaviri sa pocitac, tak co potom? budem hladat kade-tade nejaku zalohu zpred xx dni a rozmyslat co som odvtedy robil, alebo sadnem za iny pocitac a stiahnem si behom par sekund posledne zdrojaky a pokracujem dalej.
Pouzivanie git a automaticky deploy odlisuje amatera od profesionala. Navyse zdrojaky patria firme, takze ona rozhoduje  kde sa budu archivovat a ako.
neviem si predstavit situaciu, ako napr. u nas, ked sa pracuje na niekolkych veciach v ramci jedneho projektu, ako si v tom udrzat poriadok a nasledne nasadzovat len urcite dokoncene veci.

Na mne to funguje obráceně. Nějak mě to víc baví, když si udělám takovou retrospektivu.
My sme nasli taku vizualnu blbinku, kde si dal nazov repa a on ti urobil take video, ako sa menili subory. Bola to sranda sledovat tak 2-3 roky prace, ako tam behaju postavicky a objavuju/miznu rozne branche, subory. v rychlosti si ale nespomeniem na nazov.

Re:Jak posunout vývojáře k CI/CD
« Odpověď #59 kdy: 29. 01. 2021, 10:16:09 »
Překvapuje, že by někdo, kdo opakovaně pracuje se zdrojáky, vůbec uvažoval o nepoužití nějaké formy verzování, byť i jen lokálního.