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

[Petr Klíma]

Dobrý den,
nejsem programátor (pouze cca 10% času), spíš se starám o provoz.

Snažím se si ulehčit dokumentaci a práci automatizací (vlastní GitLab, Ansible ...) a rád bych do toho vtáhnul ostatní.
Bohužel narážím na to, že vývojáře tyhle věci nezajímají, "otravujou je" ...

Mám v tom podporu vedení, ale nikdy není dobré dělat věci "na sílu" pokud to jde jinak.

Když napíšu, že jsem zatím neuspěl ani s tím, že budou zdrojáky našich aplikací verzovány v GitLabu asi to bude k smíchu, ale je to realita. Přitom je podle mne verzování zdrojáků, konfigurací a dokumentace úplný základ.

Jak začít?

Máte nějaké materiály, odkazy, tutoriály které by nebyly dlouhé ale spíš "úderné" ... prostě na dvouhodinovou přednášku se všichni vy... .
A nemůžou to být CLI only věci - těch jsem našel spoustu - kolegové jsou Win pozitivní ...

PS: moudra "vyhoďte je" si prosím nechte, děkuji

[Reklama]

[MalyTomi]

git je pre vyvojara zaklad. Nepoznam jedineho skuseneho, ktory by odmietal git. Vela IDE uz ma priamo integrovany git client, napr. visual studio.
co sa tyka CI, tam napr. u nas sme nasadili teamcity. neriesili sme nic, proste sa im oznamilo, ze to budeme pouzivat a vybavene. Jednoznacna vyhoda CI je v tom, ze mame istotu, co je v repe, to je nasadene na servri. ziadne take, ako kedysi, ked nasadene bolo nieco, co niekto len tak upravil a zdrojaky mal lokalne u seba.
Takze jedine riesenie je oznamit im, ze sa zdrojaky budu spravovat cez git a bodka. Nech si hundraju kolko chcu.
ked ich otravuje git, tak neviem co by robili u nas, ked my ako vyvojari musime vsetko riesit cez jiru, a kazdu jednu vec vykazat - na akom projekte, co sme kazdy den robili a kolko.

[Tomáš Procházka]

Jak jsi na tom ty se znalostmi gitu? Videl bych problém pokud se nekomu "pokazi" git, tak aby jsi mu byl schopen pomoci. Jinak se ti na to brzo vyprdnou. Zvlast kdyz ta chut neni.
Ja bych je nevyhazoval, ja bych odesel Vlastne uz jsem to udelal, ve svem prvnim zamestani.

[Filip Jirsák]

Když napíšu, že jsem zatím neuspěl ani s tím, že budou zdrojáky našich aplikací verzovány v GitLabu asi to bude k smíchu, ale je to realita.

Co to znamená? Že zdrojáky nejsou verzovány vůbec? Nebo jsou verzovány jiným VCS než gitem? Nebo jsou v gitu, ale používá se jiný integrační server, než GitLab?

[Petr Klíma]

Takze jedine riesenie je oznamit im, ze sa zdrojaky budu spravovat cez git a bodka. Nech si hundraju kolko chcu.
ked ich otravuje git, tak neviem co by robili u nas, ked my ako vyvojari musime vsetko riesit cez jiru, a kazdu jednu vec vykazat - na akom projekte, co sme kazdy den robili a kolko.

U nás je to zatím anarchie ... nejsme softwarehouse, ale výrobní fabrika a vývoj děláme podle zadání našeho bussinessu ... většinou malé jednorázové aplikace, ale o to je horší údržba ....

[Reklama]

[jehovista2]

Videl bych problém pokud se nekomu "pokazi" git, tak aby jsi mu byl schopen pomoci.

Tutorialu na git je plny internet. A nez se v tom trochu rozkoukaji, vzdycky se da aplikovat nasledujici:

Kód: [Vybrat]

rm -rf project
git clone project


[Petr Klíma]

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čí.

[to_je_jedno]

pokud jde o CI / devops apod tak nejjednodussi jak je donutit je po nich neco periodicky chtit. nejaky reporty, nasazovani novych verzi, cokoliv co je bude vysirat ze musi opakovat manualne porad dokola.

[Filip Jirsák]

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čí.

To mají zdrojáky umístěné na nějakém sdíleném disku, a tam to všichni editují? Nebo to editují přímo na produkčním serveru? O jaký jazyk se vůbec jedná?

Podle mne nám chybí nějaký kontext. Je zbytečné přemýšlet o zavádění CI/CD, když vývojáři nevidí přínos VCS nebo jeho zavedení považují za příliš nákladné. Je potřeba vidět, jaké problémy současné řešení způsobuje vývojářům a jaké dalším lidem okolo. Přičemž je dobré to ještě rozdělit na ty problémy, které si vývojáři uvědomují, a na ty, které nevnímají. A také jaké přínosy v současném řešení vidí.

[Martin Dráb]

Máte nějaké materiály, odkazy, tutoriály které by nebyly dlouhé ale spíš "úderné" ... prostě na dvouhodinovou přednášku se všichni vy... .
A nemůžou to být CLI only věci - těch jsem našel spoustu - kolegové jsou Win pozitivní ...

Jakmile je naučíte verzovat např. v gitu spolu s použitím nějaké chytřejší nadstavby (Azure DevOps, Gitea, Gitlab...), cesta k CI je celkem jednoduchá.  Alespoň v případě, že vám zatím bude stačit invariant "co je v master/develop, to jde zkomilovat".

Jednoduše proto, že CI pak v podstatě nastavíte sám "na pozadí" a např. dáte podmínku, že do maste/develop nepůjde mergovat "bez té zelené fajfky".

Tím chci říci, že nasazení CI pak nevyžaduje moc práce od samotných vývojářů, ale začnou vidět jeho výhody (postupně).

Co se týče automatických testů, to může být problém, pokud ty aplikace jsou speciální a není lehké automatické testy napsat (nebo stejně nedokážou tu aplikaci pořádně otestovat).

-------

Co se týče přemluvení vývojářů k nasazení verzovacího systému, to může být složité. Samozřejmě, může vám drsně pomoci náhoda (zdrojové kódy zmizí a není záloha, je potřeba se rychle vrátit  k nějaké předchozí verzi a upravit ji).

Jinak mě nic moc nenapadá, zřejmě i proto, že můj pohled je zkreslený (verzování považuji za velmi užitečný základ). Ale pokud to nikdy neviděli a nepracují moc týmově (jeden vývojář obvykle spravuje sám určité aplikace), tak se výhody (z jejich pohledu) ztrácejí.

[Petr Klíma]

To mají zdrojáky umístěné na nějakém sdíleném disku, a tam to všichni editují? Nebo to editují přímo na produkčním serveru? O jaký jazyk se vůbec jedná?

Ne, ty zdrojáky jsou v zásadě ve dvou kopiích ... u vývojáře a v běhovém prostředí.
Vesměs se jedná o jednoúčelovky které buď z technologií tahají data, transformují je a ukládají do DB, nebo jen předžvýkají a předhazují jiným např. dodávaným aplikacím a/nebo jen dodatečné report pro obsluhu ...

Z části je to PHP a/nebo JS, něco Java, něco C# ... u těch posledních dvou je kopie možná jen jedna ...

Podle mne nám chybí nějaký kontext. Je zbytečné přemýšlet o zavádění CI/CD, když vývojáři nevidí přínos VCS nebo jeho zavedení považují za příliš nákladné. Je potřeba vidět, jaké problémy současné řešení způsobuje vývojářům a jaké dalším lidem okolo. Přičemž je dobré to ještě rozdělit na ty problémy, které si vývojáři uvědomují, a na ty, které nevnímají. A také jaké přínosy v současném řešení vidí.

Kontext ... spousta cca 35 malých "pomocných" aplikací, které když nepojedou, tak ztratíme část funkcí, něco půjde dělat ručně, něco ne. Zmizí celkem dost reportů ...

Další kontextová část je, že nikdo z nich není vývojář na 100%, část času (30%) věnujou údržbě dodaných aplikací ...

Ohledně CI/CD ... tady beru VCS jako základ od kterého se odpíchnout a ostatní věci nabalovat postupem ...

[Petr Klíma]

Jinak mě nic moc nenapadá, zřejmě i proto, že můj pohled je zkreslený (verzování považuji za velmi užitečný základ). Ale pokud to nikdy neviděli a nepracují moc týmově (jeden vývojář obvykle spravuje sám určité aplikace), tak se výhody (z jejich pohledu) ztrácejí.

No toho jsem se bál ...

Je to pre DevOps klasika ... tady máš program, mě to na PC funguje, je to tvůj problém ...

[MichalKovacic]

Hmmm... Tohle je jednoduché, ale určitě ně snadné.

A/ vnímá management situaci stejně nebo zde nevidí problém?
B/ jsou na změnu prostředky?
C/ existuje někdo s vizí, jak by měla vypadat ideální situace?

Pokud A i B není ANO, máš smůlu. C může velice pomoci, ale není nevyhnutelné. No a pokud je tam ANO, ANO - hmmm... IT manager ve fabrice by měl být schopen odřídit změnu. Pokud ne, externí manager to zvládne bez větších problémů - a je i lepší, jelikož je tam dočasně a nemusí se bát skočit několika "nepostradatelným" na palce.

Jinak bez vnějšího tlaku se vývojáři nezmění - proč by to dělali?

[Filip Jirsák]

Chápu to správně, že pak ty aplikace nasazujete vy, nebo se na tom alespoň podílíte? Pak bych to zkusil vzít od vašeho konce. To, co dostáváte od vývojářů, si dáte do Gitu, a za tím si uděláte pipeline, která to někam nasadí. Když dostanete novou verzi, commitnete ji do toho Gitu a zase se to nasadí. Třeba když vývojáři uvidí že se nemusíte nikam přihlašovat, kopírovat tam soubory atd., budou to chtít taky.

A samozřejmě bych se hodně věnoval té dokumentaci – aby byla dostupná z prohlížeče, prohledávatelná a snadno editovatelná. Pokud teď vývojáři nepoužívají Git, bylo by dobré, aby jí mohli editovat rovnou z prohlížeče (třeba aspoň tak, jak umí GitHub editovat Markdown soubory). Vývojáři píšou dokumentaci neradi, ale když budou vědět, že ji někde najdou napsanou, určitě si radši přečtou dokumentaci, než aby to zkoušeli metodou pokusu a omylu.

[Kit]

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čí.

Zdrojáky verzuji hlavně pro vlastní potřebu, včetně svých vlastních. Totéž s testy - píši si je a když je klient nezaplatí, tak je ani nedostane.

Velkou výhodu vidím v tom, že po dokončení projektu ho jednoduše smažu z lokálního disku a mám od něho klid. Kdykoli si ho mohu znovu naklonovat.

Verzování mě odnaučilo zakomentovávat kód. Prostě ho smažu. Je v historii, ze které si ho mohu snadno vyzobnout, pokud bych ho potřeboval.

Pokud na to dosud nepřišli, je třeba je to naučit. Vím, že když jsme dělali s SVN, tak to byl opruz, ale na Git se dá zvyknout rychle.