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

[L..]

Už to tu párkrát v různých obměnách zaznělo, ale klidně to zopakuji: Podstatný je business důvod, proč by k té změně mělo dojít. Například:

- Zavedením CI/CD se zkrátí doba vývoje o 20% a čas potřebný na deploy o 80%
- Nebudou se stávat situace, kdy někdo vymaže kód aby následně zjistil, že ho vlastně potřeboval a musí ho složitě lovit po zálohách nebo psát znovu.
- Nebudou se stávat situace, kdy člověk, co dělal projekt onemocní a nikdo to po něm nemůže převzít, protože rozumně aktuální verze zdrojáků je jen na jeho počítači.
- Nebudou se stávat situace, kdy nasazení projektu trvá tři dny, protože u programátora to funguje, ale na serveru ne.

A tak podobně.

Naopak důvody "prostě se to tak dělá" nebo "chci si hrát s CI/CD" nejsou pro business relevantní. Pokud si to budeš dělat sám ve volném čase, tak asi cajk, ale investovat do toho prostředky dalších lidí bez přínosu pro firmu je bláhový požadavek.

Pokud pro to business důvody jsou, tak je vysvětlit managementu, pak nadřízenému těch vývojářů, sestavit s ním plán zavedení a vysvětlovat programátorům. Pro mě jako pro programátora je verzování přínos i když dělám sólo, právě kvůli snadnému chození tam / zpět, vidím, do kterých souborů jsem aktuálně sahal atp. Ale pokud ti lidé nemají s VCS zkušenosti, tak tyhle výhody nevidí, to je jasné, musí se jim vysvětlit.

[Reklama]

[tomas88]

Kolik vas (jich) vyvojaru je? Nenajde se mezi nima alespon jeden, ktery by si to od tebe nechal vysvetlit a pak byl inspiraci pro ostatni? Pripadne by ti je pomahal presvedcovat. Protoze pokud ses sam, tak to muzes rovnou vzat. Pises ze mas podporu vedeni. Pokud ses sam ale mas opravdu podporu vedeni, tak bych sel klidne "na silu". Usetris si hromadu starosti. Chapu tvoji flustraci. Taky ve firme neco resime v ramci internich procesu.

[redustin]

Upřímně nedovedu si představit, že by se dalo efektivně a kvalitně vyvíjet bez nějaké formy verzování zdrojáku. I staré CVS je lepší než nic. Jak vidí, co v dané iteraci změnili?

[Kit]

Pro mě jako pro programátora je verzování přínos i když dělám sólo, právě kvůli snadnému chození tam / zpět, vidím, do kterých souborů jsem aktuálně sahal atp. Ale pokud ti lidé nemají s VCS zkušenosti, tak tyhle výhody nevidí, to je jasné, musí se jim vysvětlit.

Do kamene tesat. Kdyby tady byly lajky, tak ho dám.

[nehalem]

Co to znamená? Že zdrojáky nejsou verzovány vůbec?

Jo přesně tohle to znamená ... Super co?

Já jim nějak nedokážu vysvětlit, že to je špatně. Programátoři asi mluví jinou řečí.

Odíď. Načo strácaš čas s neschopnými a lenivými debilmi?

[Reklama]

[Jakub Štech]

Tohle bohužel není ojedinělý úkaz, jistá pražská telco firma s obratem ve vyšších stovkách milionů používá jako version control Samba share, do kterého ct. vývojáři občas "commitnou" svoje dílo. Výpis souborů pak vypadá v duchu:

Kód: [Vybrat]

projektxxx uprava leden pokus.zip
projektxxx uprava leden final.zip
projektxxx uprava leden final (1).zip
projektxxx uprava leden final (1) oprava.zip
projektxxx uprava leden fix.zip
projektxxx uprava leden fix (1) kolaudacni.zip
projektxxx ostra nemenit.zip
projektxxx ostra nemenit (kopie).zip

a obsahem ZIPů bylo cokoliv. Někdy pár souborů s .NET zdrojákem, jindy celý VS projekt i s build artefakty. Někdy jen delta, např. pár upravených souborů. Nad tímto vývojový team dělal "agile" porady, které trvaly obvykle od prvního kafe až do oběda. Já jsem se tam motal v jiném oddělení, kde jsme takovou anarchii netrpěli, při jednom setkání jsem se na důvod jejich systému zeptal. Bylo mi tím nejnadřazenějším způsobem vysvětleno, že v businessu git ani jiný amatérský freeware nemá co dělat :-)

Byla to přesně taky firma, jejímž primárním zaměřením není vývoj (čehokoliv), a tak vedení neznalo a neřešilo směr, kterým by to měli vést. Jen co odkoukali od kamarádů ve vedení jiných firem.

[lazywriter]

Možná bych šel ještě dál a nabídl jim kompletní prostředí i s IDE. Verzovací systémy používám běžně od dob CVS. Ale musím uznat, že  integrací do VScode se to dostává na další úroveň.
Doporučím třeba pluginy GitLens (pro každý řádek kódu ukazuje hned blame a informace o commitu, který jej editoval), nebo GitLab Workflow (po commitu, pochopitelně přímo z VSc, se za chvílí objeví ve status baru fajfka, že CI pipeline prošla apod.). Plus pluginy pro linting atd.
Takže nakonec zjistí, že vlastně nemusí ani opouštět IDE a všechno se stane "samo".

[Andrej Kvasnica]

git: ak su to one man show projekty tak verzionovanie juniorom (naschval nepisem zaciatocnikom) moze pripadat zbytocne. V polovici 90-tych rokov som takto na malych projektoch pracoval aj ja. Na vyske sa to neucilo a v prvej praci som k tomu samostatne nedospel.

Nedavno som nasiel zdrojaky jedneho mojho viacrocneho produkcneho projektu z roku 1997 (webovy eshop s kosikom a multitenant editorom kategorii a tovarov pre predajcov napisany v C na linuxe, na rok 1997 celkom scifi, obchodne to ale zlyhalo na presvedceni kritickej masy predajcov ze je to dobry napad. Ani technologie klienta naboli dostatocne, AJAX vznikol az o 2 roky a pridanie do kosika robilo na pomalom modemovom 33600Bd internete reload stranky). "Verzionovanie" som robil v tar.gz obrazoch celej zlozky so zdrojakmi, db skriptami a konfigmi. Z dnesneho pohladu nocna mora, ale v tych casoch to bolo celkom bezne.

ci/cd: jednou z ciest moze byt zobrat im kluce od miesacky a deployment robit vyhradne z buildovacej masiny. Dobrym dovodom moze byt audit zmien alebo zastupitelnost (napriklad aj v tomto divnom case). A na buildovaciu masinu sa zdrojaky dostanu z gitu.

[MalyTomi]

Kedze uz vieme viac detailov, tak na tvojom mieste by som navrhoval jednoduchu vec. Kedze zdrojaky patria firme, tak jednoducho sa budu spravovat centralne a nech si "programatori" hovoria co chcu. Mozno by stacilo na zaciatok nieco jednoduche, napr. svn, kde na one man show staci len push/pull. Aby ste mali aktualne zdrojaky k dispozicii.
Pripadne rovno dat git a pre kazdy projekt 2 branch-e. master a dev. V dev nech si robia co chcu, ale to, co ma ist do produkcie bude v master. a odtial to bude jedna osoba nasadzovat do produkcie.
Cize nemusia robit takmer nic, len udrzovat aktualne zdrojaky a raz za cas urobit merge.
A hlavne odpadnu pripadne problemy typu: kto a kedy zmenil funkcionalitu a preco.

[Ink]

Jestliže "máš podporu vedení", tak by ta podpora měla být někde vidět a výsledkem by měl být plán přechodu, ať si zaměstnanci brblají jak chtějí. Problém vidím v tom, že managementu zřejmě současný stav zase tak moc nevadí. Každá změna musí být dobře "prodaná", to znamená, že musíš sehnat podporu od lidí, kteří si myslí, že stávající stav je neutěšený.

Prosazování změny ve firmě je poměrně náročná disciplína, zvážil bych pro začátek fakt alespoň zavedení Gitu. Zřejmě nejsi v pozici, ve které bys mohl celý proces obrátit zcela jiným směrem na první dobrou.

[alex6bbc]

nebo sehnat podporu aspon jednoho seniorniho programatora, ktery by evangelizoval zbytek kokotu.

[MalyTomi]

Jestliže "máš podporu vedení", tak by ta podpora měla být někde vidět a výsledkem by měl být plán přechodu, ať si zaměstnanci brblají jak chtějí.

Kedze viem, ako to chodi v roznych firmach, tak podla mna ta podpora vedenia je asi taka ze: kolko to bude stat firmu? nic? ok, tak to mozme urobit.
Vedenie casto nema ani len tusenia, ako prebieha vyvoj. Ich len zaujima kolko to stoji firmu. Nezaujima ich nejaky prinos, ktory nie je vidiet. tak ako zalohy, pripadne zastupitelnost sa riesi, az ked je pruser, a hned po uhaseni problemu sa na to zabudne.
Tiez som niekolkokrat hasil prusery typu: zosypala sa produkcia, lebo nieco bolo odflaknute, a ked som ich povedal, ze na toto som ich pol roka upozornoval, tak stale iba ano, budeme to riesit. Ked som to ako-tak dal dokopy, tak zase vyhovorky, ze na tu prerabku nie je cas. a o par mesiacov zase to iste. A to nebola nejaka mala spolocnost, a ten vypadok znamenal stratu tisice eur.

[Ink]

Jestliže "máš podporu vedení", tak by ta podpora měla být někde vidět a výsledkem by měl být plán přechodu, ať si zaměstnanci brblají jak chtějí.

Kedze viem, ako to chodi v roznych firmach, tak podla mna ta podpora vedenia je asi taka ze: kolko to bude stat firmu? nic? ok, tak to mozme urobit.
Vedenie casto nema ani len tusenia, ako prebieha vyvoj. Ich len zaujima kolko to stoji firmu. Nezaujima ich nejaky prinos, ktory nie je vidiet. tak ako zalohy, pripadne zastupitelnost sa riesi, az ked je pruser, a hned po uhaseni problemu sa na to zabudne.
Tiez som niekolkokrat hasil prusery typu: zosypala sa produkcia, lebo nieco bolo odflaknute, a ked som ich povedal, ze na toto som ich pol roka upozornoval, tak stale iba ano, budeme to riesit. Ked som to ako-tak dal dokopy, tak zase vyhovorky, ze na tu prerabku nie je cas. a o par mesiacov zase to iste. A to nebola nejaka mala spolocnost, a ten vypadok znamenal stratu tisice eur.

Rozumím, každá ryba smrdí od hlavy. Ale i tak se dá leccos prosadit, pokud se člověk trochu snaží. Možná by občas stačilo managementu naznačit, že je záhodno, aby kód firemního software přečkal případný odchod jeho autorů a že spolehlivý SW pro správu verzí je v tomhle základ.

[Makovec]

Postupně a ukázat k čemu to těm vývojářům může být dobré a pomoct jim v jejich práci.

Tj. začít Gitem, ale ne tak že "tady máte Pro Git book, si to nastudujte a od pondělka jedem" ale elementárními praktickými příklady. Vzít to tak že to je vlastně jenom takové chytřejší strukturované archivování verzí, inspirovat se třeba Git Flow jako praktickým přístupem (z popisu to vypadá že jde o malé one-man-show projekty, takže nemá smysl plašit s pull requesty, code review apod). Hlavně nedovolit managementu aby se toho chopil a začal počítat commity a dělat statistiky.

Pak zkusit zavést nějakou štábní kulturu do testování, ze začátku manuálně spouštěnými skripty bez nějakých automatizací.

Automatizace bych nechal až úplně na konec pokud vůbec, protože se snadno stanou akorát zdrojem opruzu a práce navíc (na něčem co navíc není smyslem toho vývoje) když se v jejich toolchainu cokoli rozbije.

[jouda2]

Kedze uz vieme viac detailov, tak na tvojom mieste by som navrhoval jednoduchu vec. Kedze zdrojaky patria firme, tak jednoducho sa budu spravovat centralne a nech si "programatori" hovoria co chcu.

Pokud jsou placení míň než případná náhrada (a nedej bože potřebují nějaké další netriviální znalosti), tak tenhle postup může dost narazit ainiciátor změn bude první na ráně. Po zlém to opravdu není dobrý nápad.

Na druhou stranu, často pomůže počkat v takové situaci na nějakej prů..r na produkci, a pak je mnohem snadnější vysvětlit, že něco (verzování jako základ, alespoň nějaká sadu základních testů taky nikoho nezabije) je mezi notes a produkci vetknout prostě potřeba.

Edit: Jak píše Makovec - případně ukázat na reálném příkladu - tady mám hobby projekt xyz, tady vidíš co jsem kdy dělal, tady jsem to před rokem trochu pokazil a hele, koukni na ten diff, dávat z hlavy co tam bylo bych už nedal.