[Videó] 10k deploy naponta!

( hup | 2020. 07. 28., k - 14:51 )
HUP
Nézzük meg a continous deployment lehetőségeit és buktatóit - mélyvízben.

"You build it, you run it!". Betekintés egy Continous Deployment pipeline-ba illetve egyéb developer enablement eszközökbe, ahol nem más a cél, mint a napi 10 000 deployment. Kapéter Máté, a Skyscanner szoftvermérnökének 2018-as HWSW mobile! konferencián elhangzott előadásában megnézzük, honnan indultak, milyen buktatókba futottak bele és merre tartanak a cég Developer Enablement csapatai!

Ha érdekel a DevOps, a konténerizáció, a konténer menedzsment, akkor ajánljuk szeptember 15-én induló 24 órás, online Kubernetes alapjai című képzésünket.

( Crayon | 2020. 07. 28., k - 21:13 )

Szerkesztve: 2020. 07. 28., k - 21:14

értem én, hogy kell a clickbait címadás, de még akkor is nehéz elérni a napi  10k-t ha minden fejlesztő minden Ctrl+s -ére lefut az a pipeline...

0 szavazat

azóta már bezárták a budapesti irodát... állítólag nem emiatt. :) el nem tudom képzelni, hogy naponta 50 vagy 100 vagy még több feature kimenjen. ha meg bugfixek mennek ki akkor azt jelenti, hogy folyamatosan alpha verzió fut élesben. Én napi maximum 4 deployt engednék meg, de úgy, hogy ha valamelyik deploy után valami balul sül el, akkor a következőig eltelő 6 óra alatt keletkező anyagi kár megoszlik a teamen. De a napi 4-et is úgy, hogy napi egynél több is már levonással jár, még akkor is ha nincs anyagi kár...

0 szavazat

Biztosan talalnal is olyan teamet, aki nem mondana fel. (Csak beszelgess el par programozoval, miert lepett ki az elozo munkahelyerol.) De a munkaugyi pert talan megusznad, leven Munka Torvenykonyvevel sem igazan osszeegyeztetheto ez a levonas, de olyan gyorsan kezdenek majd az uj helyukon, hogy nem lesz idejuk ezzel foglalkozni.

Egyebkent nekem a rekordom egy nap 11 deploy. Hogyan tortenhetett? Gyorsan dolgoztam, mert nekem hozta a penzt a projekt siker eseten.

Egyebkent komolyan levonnal az alabbiert penzt programozok fizetesebol?

  1. Maintenance site bekapcs
  2. Migracio lefuttat live
  3. Feature kimegy
  4. Maintenance site kikapcs mert mar mennie kell mindennek
  5. Volt egy eliras egy szoban (meg csak nem is bug)

Egy elgepelt szo egy template-en, sima termeszetes nyelvi hiba: ez szerinted bercsokkentest er?

2 szavazat

3 report cronjob ami futtatott orankent/naponta egy query-t postgres-ben es kuldott mailt, egyikbe kellett egy extra field aztan, 4 "blind fix attempt", mert olyan "jo startuposan" ahhoz a reszhez amiben a bugot talaltak nem volt tesztkornyezet es nehez lett volna gyorsan csinalni egyet es annal surgosebb volt a javitas, 1 eliras, egy rossz conflict resolve javitasa es egy edge case bug hotfixe. Nagyobb baj egyikbol se lett, mint ahogy elotte nap allt a rendszer.

0 szavazat

Akkor nem levonás lenne, hanem bónusz csökkentés. A videóban éles deployról volt szó fentebb, tehát ami már átment a teszteken és többen átnézték. A cél az lenne, hogy a fejlesztő vállaljon felelősséget azért amit csinál. Ez nem azt jelenti hogy nem lehet hibázni, mindenki hibázik időnként, ez csak azt jelenti hogy nem küldünk élesbe "hurrá lefordult!" kódot. Persze biztosan elérhető ez a cél más, befogadóbb módon is, nem ástam bele magam a kapcsolódó manager szakirodalomba. :)

Tesztek nélküli vagy nem tesztelhető esetben a tűzoltás az egy másik történet, ott a tűzoltás része amit írtál az dicséretes, de ez szerintem nem ugyanaz mint amiről a videóban szó volt.

0 szavazat

"A cél az lenne, hogy a fejlesztő vállaljon felelősséget azért amit csinál. Ez nem azt jelenti hogy nem lehet hibázni, mindenki hibázik időnként, ez csak azt jelenti hogy nem küldünk élesbe "hurrá lefordult!" kódot. "

Ugy latom nem dolgoztal olyan termeken amit 10 csapat 5 kontinensrol farag, raadasul tobb beszallito is van. Mert ott kivancsi lennek kinek a beret csokkentened, vagy kinek a feleloseget hoznad elo.

Ilyenkor jon elo hogy a FEJETOL BUZLIK A HAL mert koordinaciot, fejlesztesi kontrolt (QA-t), dokumentacio elvarast meg hirbol sem hallott a MENEDZSMENT de persze nem hallgatnak a paraszt fejlesztokre hogy milyen problemak vannak es hogy lehetne megoldani oket.

Hogy tud donteni a menedzsment egy fejlesztest javito (ezaltal a termek minoseget kozvetetten javito) kerdesrol amikor nem ert a fejleszteshez? Ez koltoi kerdes, altalaban ezek a javaslatok kapjak a legalacsonyabb prioritast.

Ha ennyire kritikus a szolgaltatas/termek akkor kokemenyen meg kell fizetni nem csak a fejlesztoket, de az egesz fejlesztesi processzet BIZTOSITANI pl. a tobbkoros tesztet, eles rendszer klonjan vegzett teszteket stb. ezek feladata nem a fejlesztoke hanem a feljebb levo szinteke.

De meg igy is vannak problemak, lasd MS-nel a szolgaltatas kieseseket, ezek eselyet csak minnel tobb penz bealdozasaval lehet csokkenteni. De persze penz az nincs, de a kritikus szolgaltatas menjen :) HAHAHAHA.....

0 szavazat

Senki sem nézte meg a videót és úgy irkál, vagy mi történik itt?:)

~1200-at deployoltak naponta, ezek különböző microservicek, lambdák, infrastruktúrák, vagy frontend részek deployai. Ebben benne vannak a tesztrendszerükbe kikerülő deployok is, ha jól értettem.

A 10k deploy az a szám amit a CTO talált ki, hogy akár annyit is tudjon a rendszer.

Ha gyorsak a deployok és jó a monitoring, akkor jobban megérheti néhány hibát bevállalni, ha azokat ugyanúgy gyorsan észre is tudják venni és ki is tudják javítani.

0 szavazat

Kerdes persze hogy deploy vagy deploy process. Azert egy jo nagy cloud infrastructuraban, ahol az ugyfeleid mikroservice-ket futtatgatnak on-demand lehet ennyi "deploy". Kerdes hogy ezeket nevezhetjuk e deploynak csak azert mert mondjuk ezek k8s "Deployment"-ek es darabonkent felbasznak 20-100 pod-ot. :D

Ha igy veszed, akkor naponta akar ennel sokkal tobb deployment is lehet. Sot a 10K az kislanyoknak valo jatszoter csak.

0 szavazat

( msandor (veterán) | 2020. 07. 29., sze - 11:50 )

Mi úgy másfél éve átálltunk a havi egy patch csütörtökre, kivéve az emergency javítások. És még így is fordulnak elő hibák, mert a tesztelők sokszor felületesek, hanyagok.

0 szavazat

Benne van ez is a pakliban.

Meg az is, hogy a legtöbb teszt/fejlesztői/preprod környezetünk köszönő viszonyban sincs az éles környezettel. Komolyan mondom, ha most lehetne nulláról felépíteni a teljes IT-t, sokkal könnyebb lenne az életünk, persze idővel az is káosszá süllyedne :-)

0 szavazat