Alapkövetelmény lett a DevOps ismerete a fejlesztők számára?

 ( hup | 2019. április 13., szombat - 18:50 )

A DevOps alapjaiban változtatja meg a fejlesztői kultúrát.

A DevOps lényege nem a használt eszközökben, hanem a fejlesztői kultúrában gyökerezik. Egyetlen kódbázis sem különíthető el élesen a pipeline-tól, ami telepíti a teszt, majd az éles környezetbe, éppen ezért a fejlesztőknek és az üzemeltetőknek folyamatos, aktív és hatékony kommunikációt kell fenntartaniuk egymás között, és betekintést kell nyerniük egymás munkájába.

Az üzemeltetők és a fejlesztők közötti együttműködés eleinte sok nehézséget jelentett és nagyban megnehezítette a munkát a két terület közötti közös nyelv és kultúra hiánya. A probléma megoldásaként jött létre a DevOps módszertan, amely a szervezetet, a folyamatot és a technológiát hangolja össze. A végeredmény gyorsabb és egyszerűbb deployment ciklusokat eredményez.

Az április 24-én induló, 11 alkalmas DevOps képzésünk pontosan ezen technikák és technológiák alapjaiba nyújt betekintést, hiszen egy modern fejlesztőtől a felhős környezet, a Docker vagy akár a Terraform ismerete már alapelvárás.

Ki ne hallotta volna már ezerszer, hogy a Google, Facebook, Uber, Netflix és hasonló cégek napi több százezer vagy akar millió release-zel dolgoznak? Ezek a nagy számok nem csupán jól hangzanak. A gyors release-ek gyors visszajelzésekkel szolgálnak, így az éles rendszer hibái gyorsan felfedezhetők és javíthatók, illetve a felhasználók visszajelzéseire is gyorsabban tudunk reagálni. Ehhez képest még napjainkban is gyakoriak a havi vagy akár fél éves, éves deployment ciklusok, amelyek nagy mértékű technical debt-hez és folyamatosan növekvő backloghoz vezetnek. Noha úgy hangozhat, hogy ez a hihetetlen sebesség csupán a Szilícium-völgyben lakozó óriások privilégiuma, azonban a mai felhős technológiák és DevOps best-practice-ek alkalmazásával bárki számára elérhető, legyen az egy pár fős fejlesztő csapat, vagy akár egy több ezer fős mamut vállalat.

Hódi Tamás és Iváncza Kristóf, a képzés oktatóinak egy DevOps "war" sztorit elregélő előadása a HWSW április 2-i DevOps meetupján

A 33 órás tanfolyamon gyakorlatorientáltan vesszük végig a 3 legnagyobb felhőszolgáltató által nyújtott szolgáltatásokat és beállítási lehetőségeket, illetve felkészítünk egy példa alkalmazást a felhőben való üzemelésre. A képzés oktatópartnere a RisingStack, akik JavaScript (Node.js, React, Angular) fejlesztésre és oktatásra, illetve microservice rendszerek tervezésére és DevOps tanácsadásra specializálódtak. A csapat az egyik legnagyobb eléréssel rendelkező angol nyelvű szakmai blog szerzője (JavaScript, DevOps), havi 150 ezer olvasójuknak köszönhetően pedig a nemzetközi mezőnyben is húzónévnek számítanak.

A kurzus online követhető, de néhány tantermi hely is rendelkezésre áll. Minden óráról felvétel készül, melyet a résztvevők tetszőlegesen visszanézhetnek. A részletes tematika a képzés oldalán érhető el, ahol jelentkezni is lehet.

Április 16-án 10 alkalmas, 30 órás front-end fejlesztői képzést is indítunk Angular alapokon, amellyel a résztvevők önállóan is képesek lesznek modern frontend alkalmazásokat készíteni.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Tudnek meselni az eziranyu kepessegekrol: pl. az elegge rombolo jellegu, amikor a devopszendzsiner MacAddress nevu mezobe tarolja az ipv6 cimet.

+1 :)
____________________
echo crash > /dev/kmem

> Alapkövetelmény lett a DevOps ismerete a fejlesztők számára?

Nem. Ártani persze nem árt, ha valaki a szűk szakterületén kívül is hall dolgokról.

Amúgy a millió release per nap - kiszámolta már valaki, hogy az mennyi? A fent említett Google-nek van kb 90.000 full time alkalmazottja, ha a vezérigazgatótól a sales-eseken át a jogászokig mindenki szoftvert fejleszt, akkor is fejenként napi 11+ release kellene, hogy meglegyen az egy millió.

I'm not buying it.

Másodpercenként 11 release.

Ezt ugy hijjak, hogy tervezes nelkuli fejetlen kapkodas, majd a normalis teszteles nelkul kitolt sz..k instant toldozgatasa.
Fejlesztoi/PM oldalrol meg szkrum, meg agilis (valojaban arrogans) szirszar, meg sorolhatnam.

Szerintem az agilis önmagában nem hülyeség, ha mellette érvényesül a JPÉ, és nem ezüst golyóként akarják használni, hogy mindent (is) azzal oldanak meg. Illetve segít, ha nem akarják betű szerint implementálni mindenhol, gondolkodás nélkül.

Attól függ hogy mit fejlesztesz. Ha az üzlet is folyamatosan változik, akkor b.szhatod a vízesésedet.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/motog4_athene

Amit en latok, az az, hogy a dev kornyezetben nem letesztelt dolgok miatt sz..nak a fejlesztok, ha ugyanis kiment az uj riliz, ami bár dev környezetben jó volt, élesen már másként működik, akkor elvárja a megrendelő -jogosan- hogy kikerüljön a termék, úgy, ahogy azt dev környezetben látta.
A napi 10-20 uj riliz pedig felveti az egész brigád teljes alkalmatlanságát, kezdve a PM -el, aki nem tudja átadni, mit is akar a megrendelő látni....

Nem lehet, hogy amúgy egyáltalán nem érted a CI/CD környezetek működését és az agilis fejlesztés alapjait?

Pont két hete beszéltem egy PM-el, hogy mennyire jellemző az agilis arrafelé, aztán mondta, hogy próbálták, de azt látta, hogy a scrum master és a product owner a PM, a daily standup a napi report és a sprint egy fejlesztési egység, a product demo meg a retrospektív pedig faszság, szóval ugyanazt csinálták agilis módszertanban, mint előtte, csak másképp hívták a dolgokat, szóval faszság. Te is valahogy így gondolod, nem?

--
https://iotguru.live

Valojaban tenyleg nem ertem. En a masik oldalon vagyok, en vagyok az, akitol elvarjak, hogy olyan kornyezetben mukodjon valami, amit napi 4-5 alkalommal kepesek felulbiralni, mert a lokalis fejlesztokornyezetben neki mar maskent ment/maskent volt jo.
Az a gondolatmenet, amire jelenleg sokan rej..lnak epp a kiforratlan kodok production kornyezetbe integralasat erolteti. A unit tesztek soha nem fognak valos helyzeteket szimulalni. Nem lepodnek meg, ha kiderul, ebben a metodologiaban keszult a 737MAX -ok vezerlese is.
Hasonlo, de kevesebb tettel rendelkezo dolgokrol is beszelhetunk, pl. az ISO 27001 tanusitott rendszerekrol, stb.; ott sem szerencses a napi 100+ "namajdmostjolesz" nekifutas, a sor a vegtelensegig folytathato.

"En a masik oldalon vagyok, en vagyok az, akitol elvarjak, hogy olyan kornyezetben mukodjon valami, amit napi 4-5 alkalommal kepesek felulbiralni, mert a lokalis fejlesztokornyezetben neki mar maskent ment/maskent volt jo."

Tényleg nem dolgoztál még CI/CD környezetben, mert ez nem az.

"Az a gondolatmenet, amire jelenleg sokan rej..lnak epp a kiforratlan kodok production kornyezetbe integralasat erolteti."

Nem, ez nem az.

"Nem lepodnek meg, ha kiderul, ebben a metodologiaban keszult a 737MAX -ok vezerlese is."

Nem, az nem így készült. :D

"ott sem szerencses a napi 100+ "namajdmostjolesz" nekifutas, a sor a vegtelensegig folytathato."

A CI/CD nem a majd-most-jó-lesz nekifutásról szól, te tényleg nem érted és nem is jártál még a közelében sem.

--
https://iotguru.live

Valoban nem ertem es nem is okoz gondot, hogy ezt beismerjem.
Abban a formaban, ahogyan hasznaljak azokon a helyeken, amikkel kapcsolatom van, annak semmi koze nincs a Fowler altal lefektetett alapokhoz/koncepciohoz, de(!) annak nevezik. Sajnos ugyanezekrol a tapasztalatokrol kapok visszajelzest mashonnet is.

Ó, én nagyon sok helyen láttam olyat, hogy állítólag agilis, aztán meg leírtam, hogy a gyakorlatban hogyan megy... persze, sok helyen vannak balfaszok, akik ezt rosszul művelik. De attól, hogy sok a balfasz, attól még ez a dolog működik ott, ahol értelmesen művelik. És akkor nem azért van naponta 50 release, mert most-már-jó-lesz, hanem azért, mert naponta 50 - sokszor egymástól független - issue megoldódik, letesztelődik és kimegy élesbe, nem várnak össze havonta 1000 issue-t.

--
https://iotguru.live

Havi 1000 issue azert... na :)
____________________
echo crash > /dev/kmem

Sok vagy kevés? :)

--
https://iotguru.live

Ott a pont :) Szerintem sok. De nyilvan nem ismerem a kornyezetet, csak ugy altalaban veve ertem.
____________________
echo crash > /dev/kmem

Napi négy issue és 10 fős csapat már havi 800 issue.

--
https://iotguru.live

Napi 4 issue/fo eseten - ami ugye donto reszben bugokra reflektal - elgondolkoznek az erintett human eroforras -de kulonosen a felelos vezetok- athelyezesen a munkaugyi kozpontba, illetve beprotezsalnam a konkurenciahoz :)

Lehet, hogy nálad sokkal-de-sokkal jobban fel tudják bontani az igényeket jól megfogható és átlátható részekre. Ha egy feladat több időt igényel, mint két óra, akkor rosszul van előkészítve. Ha egy feladatot nem lehet több kisebb részletben élesbe állítani, akkor rosszul van felépítve az architektúra.

Nálad mennyi idő egy-egy feature issue fejlesztési ideje? És nagyjából mit foglal magában?

--
https://iotguru.live

Nem az volt a kerdes, nalam mi mennyi ido, uzemeltetesben dolgozok, engem a monitorozo rendszer lat el feladatokkal.
Egy production allapotu projektnel szerintem napi 4 issue * 10 fo (napi 40, ahogy szamoltad) azt jelenti, hogy vagy:

-Rossz az implementacio/megvalositas
-Rosszul/nem lettek felmerve a megrendelo igenyei (az altalad emlitett feature requestek is lehetnek ilyen okokra visszavezethetoek)
-A csapat egy -barmekkora es barmely- resze nem alkalmas a munkavegzesre az adott projektben

Termeszetesen ezek barmely variacioja elofordulhat. Ez egyebkent tapasztalat is.

Update: Olyan projektek, amelyek a celcsoport feature requestjeit ilyen szinten lekovetik, eleg ritkak mifelenk.

"Termeszetesen ezek barmely variacioja elofordulhat. Ez egyebkent tapasztalat is."

Vagy egyik sem, mert pont jól lettek felbontva a feladatok. Szerintem egyszerűen az a bajod, hogy rossz helyen dolgozol és nem láttál még jól működő szoftverfejlesztést... :)

A CI/CD alapelve az, hogy amikor sikerült meghatározni egy feladatot, amit mindenki ért és ugyanazt érti alatta, akkor fel kell tenni a következő kérdést: "Is there any possible way to do anything less, and still deliver value?"

Amíg a válasz az, hogy igen, addig bontani kell a feladatot kisebb részekre, azokra ismét feltenni ezt a kérdést és végül bizony eljutsz oda, hogy egy-egy fejlesztő, egy-egy héten 15-20 issue-t (task-ot, story-t, ahogy nevezed) tud release-be küldeni. Ez egyébként tapasztalat is.

--
https://iotguru.live

Szerinted elkepzelhetetlen az a felallas, amit irtam? Ismerem a munkahelyem korlatait, mar ki is veseztuk, de ha csak azt nezem, hogy az utobbi idoben pl. a Facebook eseteben mennyi kritikus bug keletkezett, akkor az is lathato, hogy bizony ez a fajta menetrend sem biztosítja a minosegi munkavegzest, csakugy, mint a vegeredmenyt. Ha valahol, akkor a hasonlo projekteknel pedig mindent elkovetnek, hogy ilyen hibak ne fordulhassanak elo.

Az idealizalt vilagban, amit feltarsz, az latszik, hogy tokeletes tervezest kovetoen meg tokeletesebb reszfeladat-definicio, majd fejlesztes, vagonszamra tesztelesi mechanizmusok es az ezekbol adodo visszacsatolasokat koveto hibajavitasok, amelyeknek a metodusa ugyszint az ebben a bekezdesben leirtak szerinti.
Csak ez sajnos nem mukodik, szamtalan adatvedelmi incidens es rendszerhiba bizonyitja. Az uzemeltetesi terulet tipikusan az, ahol ezek a hibak kiutkoznek; pont ezert nem is ertelmezheto a hurra-optimizmus azok eseteben, akik a generalt foshalmazzal dolgozni kenytelenek. A problemak megoldasat, athidalasat ugyanis instantban mindig az uzemeltetes vegzi, oket pedig a random buzzwordok sajnos nem nyugtatjak meg egyik oldalrol.

Egy ismeros cegnel tortent meg az, hogy a projekt kiadasat kovetoen a vezeto fejlesztonek, illetve a helyettesenek kellett resztvennie az ugyeletekben es keszenletekben, s azonnal beavatkoznia.
Na, ezt kovetoen valtozott meg a kod minosege a kesobbi projektekben is.

"az utobbi idoben pl. a Facebook eseteben mennyi kritikus bug keletkezett"

Kevés olyan kritikus bug-ot látok a Facebook esetén, amit ne látnék mondjuk egy homlokegyenest más fejlesztési módszertant használó bank esetén. Kivéve azt, hogy a bankok képesek hónapokon át reszelni azt, ami egyébként egy kétnapos munka. És amikor kimegy élesbe egy-két hónappal később, akkor is fos marad a következő release időpontig, dacára annak, hogy fél órás munka lenne kijavítani pár low hanging fruit hibát.

"Ha valahol, akkor a hasonlo projekteknel pedig mindent elkovetnek, hogy ilyen hibak ne fordulhassanak elo."

Elkövetnek, ja. Ez látszik is a Facebook és a Google szolgáltatásainak a stabilitásán. Kérlek mutass más módszertan szerint fejlesztett és üzemeltetett rendszert, amelyek akár csak az ezred terhelést kapják, mint amit a Facebook vagy a Google.

"Csak ez sajnos nem mukodik, szamtalan adatvedelmi incidens es rendszerhiba bizonyitja."

Miből gondolod, hogy más módszertannal eljutottak volna egyáltalán a közelébe annak a színvonalnak és feature halmaznak, ahol most vannak?

"Egy ismeros cegnel tortent meg az, hogy a projekt kiadasat kovetoen a vezeto fejlesztonek, illetve a helyettesenek kellett resztvennie az ugyeletekben es keszenletekben, s azonnal beavatkoznia."

Csókolom, ezt hívják úgy mások már közel egy évtizede, hogy DevOps szemlélet. Te eddig kövek alatt éltél?

--
https://iotguru.live

Szerintem mi nem fogunk egyeterteni.

Biztosan van jo pelda is ra, de tobbsegeben en is ezt latom. Ha csorog a telefon, kb. 20-bol 1-2 alkalom ami nem deployment okozta gond.
____________________
echo crash > /dev/kmem

Kérdés, hogy mit jelent a release... mert ha inkább a deploy felé hajlik, amit a forgalom alatt érteni kell, akkor ha elosztod néhány tízezer géppel, már nem is olyan sok, akár reális is lehet. :)

--
https://iotguru.live

Bullshit Bingo