Nedavno sem se udeležila DevOpsForum 2019, ki ga je priredila Logrocon. Na tej konferenci so se udeleženci trudili najti rešitve in nove instrumente za učinkovito sodelovanje med podjetji ter razvijalci in informacijskimi tehnologijami.
Konferenca je bila uspešna: bilo je precej koristnih predstavitev, zanimive oblike nastopov in veliko pogovorov z govorniki. Še posebej pomembno je, da mi nihče nič ni skušal prodati, kar je zadnje čase slaba praksa govorcev na velikih konferencah.
Izvleček iz predstavitev Raiffeisen Banke, Alfastrahovanja, izkušnje Mango Telekoma pri uvajanju avtomatizacije in druge podrobnosti v nadaljevanju.
Moje ime je Jana, delam kot tester, ukvarjam se z avtomatizacijo, prav tako tudi z DevOps in obožujem obiskovanje konferenc in srečanj. V zadnjih dveh letih sem bila na konferencah Olega Bunina (HighLoad++, TeamLead Conf), na dogodkih Jug (Heisenbug, JPoint), na TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Najprej bom pozornost usmerila na program konference. Manj me zanima, o čem bo predstavitev, veliko bolj pa me zanima govornik. Tudi če je predstavitev zelo tehnološka in zanimiva, ni nujno, da boš lahko uporabil katere koli najboljše prakse iz predstave v svojem podjetju. In takrat potrebuješ govornika.
Svetloba na koncu pipeline-a v Raiffeisen Banki
Običajno si v ozadju prirejam lov na zanimive govornike. Na DevOpsForum 2019 je v mojih interesih izstopal govornik iz Raiffeisen Banke - Mihail Bijan. Med predstavitvijo je spregovoril o tem, kako postopoma vključujejo svoje ekipe v DevOps, zakaj je to potrebno in kako podjetju prodati idejo o DevOps transformaciji. Na splošno je govoril o tem, kako videti svetlobo na koncu pipeline-a.
Mihail Bijan, direktor za avtomatizacijo v Raiffeisen Banki
Trenutno v njihovem podjetju ni 'pravega DevOps'. Torej je resničen, vendar ne v vseh ekipah. Pri uvajanju DevOps se zanašajo na pripravljenost ekip tako z vidika konkretnih inženirjev, kot tudi z vidika potrebnosti produkta in zrelosti tiste platforme, na kateri je ta izdelek zasnovan. Miša je razložil, kako razložiti podjetju, zakaj je DevOps potreben.
Banka segmenta ima nekoliko pokretača rasta: cijena usluga i širenje baze klijenata. Povećanje cijene usluga nije baš dobar pokretač, dok je rast baze klijenata upravo suprotno. Ako konkurenti ponude objektivno izvrsan proizvod, svi klijenti će otići tamo, a s vremenom se tržište izjednači. Stoga, uvođenje novih proizvoda na tržište i brzina njihovog uvođenja je osnovna stvar na koju se banke fokusiraju. Upravo zato je DevOps potreban, a poslovanje to razumije.
Sledeća važna napomena: DevOps ne smanjuje uvek vreme do tržišta. DevOps ne može raditi sam, to je samo deo procesa razvoja i uvođenja proizvoda na tržište od razvoja do produkcije (od koda do klijenta). No, sve što je pre koda, nema direktne veze s DevOps-om. To jest, marketinški stručnjaci mogu godinama proučavati tržište i celu večnost juriti konkurenciju. Potrebno je brzo shvatiti šta klijent želi i planirati realizaciju određene funkcionalnosti – često upravo to nedostaje kako bi DevOps funkcionisao i kompanija postigla cilj. Zbog toga je prvo u Raiffeisen banci postignut dogovor s poslovanjem o tome da je potrebno naučiti koristiti DevOps. Automatizacija radi automatizacije neće mnogo pomoći u borbi za nove klijente.
Ukratko, Miša smatra da je potrebno uvesti DevOps, ali promišljeno. Treba biti spreman na to da će tim na početku transformacije imati opadanje produktivnosti, zarađivaće manje novca, ali će se to na kraju isplatiti.
Automatizacija testiranja u "Mango Telekom"
Še en zanimiv prispevek je pripravila Egor Maslov iz 'Mango Telecom'. Predstavitev je nosila naslov 'Avtomatizacija celotnega cikla testiranja v SCRUM timu'. Ekor meni, da je DevOps ustvarjen prav za SCRUM, a hkrati je uvajanje DevOps v SCRUM ekipo precej problematično. Razlog za to je, da SCRUM ekipa nenehno teče, ni časa, da bi se posvetili novostim in preurejali proces. Problem je tudi v tem, da SCRUM ne predvideva ločevanja podskupin v ekipi (ekipa za testiranje, ekipa razvijalcev in tako naprej). In še, za avtomatizacijo obstoječega procesa so potrebne dokumentacije, ki pa v SCRUM-u najpogosteje popolnoma primanjkuje – 'izdelek je pomembnejši od kakršnega koli pisanja.'
Po prehodu na SCRUM so se testeri začeli posvetovati z razvijalci, kako testirati funkcionalnosti. Postopoma se je obseg funkcionalnosti povečeval, dokumentacija pa je manjkala, zato so začeli naleteti na številne napake v tisti funkcionalnosti, ki ni bila pokrita s testi, in sploh ni bilo jasno, kdo in kdaj jo je testiral. Na kratko – zmeda. Odločili so se za avtomatizacijo testiranja. Ampak tudi takrat je prišlo do popolnega neuspeha. Pripravili so zunanje strokovnjake za avtomatizacijo, ki so pisali na neznanem stack-u za redne testerje. Okvir za avtomatske teste je seveda deloval, vendar je po odhodu zunanjih strokovnjakov živel le še dva tedna. Sledila je poskus uvajanja avtomatizacije testiranja številka dve. Začela se je s prepričanjem, da je vse potrebno zgraditi znotraj podjetja, s svojimi močmi (pravi smer: razvijajte strokovnost znotraj), v okviru SCRUM-a in med procesom ustvarjati dokumentacijo. Stack za avtomatizacijo mora biti enak stack-u produkta (tukaj se strinjam, no natančite projekta na JavaScript z nečim drugim). Na koncu sprinta so organizirali demo, kako deluje avtomatski test, s sodelovanjem celotne ekipe (koristno). Tako se je povečala vključenost vseh članov ekipe v proces avtomatizacije, zaupanje v avtomatske teste in možnost, da bo ta avtomatski test res uporabljen (in ne bo zakomentiran čez mesec dni zaradi nenehnih napak).
Nesejans je na DevOpsForum 2019 deloval odprt mikrofon - že dolgo znan in po mojem mnenju koristen format predstavitev. Hodiš, poslušaš predavanja, potem pa se odločiš, da bi v okviru konference razpravljal o določeni temi ali problemu, delil relevantne izkušnje reševanja naloge.
Opazila sem tudi to, da so organizatorji naredili tokom kratkih predavanj. Vsako predavanje traja največ 10 minut, sledi vprašanja. Tako lahko takoj pokrijemo več tem in postavimo vprašanja govornikom, ki so nas zanimali.
Med predavanji sem se sprehodila po stojnicah partnerjev konference in pobrala/zmagala veliko raznih stvari. O, kako imam rada promocijske materiale!
Okrogla miza in vprašanja o DevOps z direktorjem razvoja v Alfastrojenju.
Češnja na torti DevOpsForum 2019 je zame bila enourno splošno zasedanje z DevOps strokovnjaki. Povabljeni so bili štirje člani seje, ki so naj bi devOps pogledali z različnih zornih kotov: Anton Isanin (Alfastrojenje, direktor razvoja), Nailya Zamashkina (Fintech Lab, operativna direktorica), Oleg Egorkin (Rostelecom, Agile trener) in Anton Martjanov (neodvisni strokovnjak, je gledal na DevOps z vidika poslovanja).
Strokovnjaki so sedeli bližje ljudem in tu se je začelo: celih eno uro so udeleženci iz občinstva postavljali vprašanja, strokovnjaki pa so se trudili odgovarjati. Včasih so se pojavile prave razprave. Vprašanja so bila najrazličnejša, na primer: ali DevOps inženirji sploh potrebujemo, zakaj jih ne moremo vzgojiti iz sistemskih administratorjev, ali je treba vsem ponuditi DevOps, kakšna je njegova vrednost in tako naprej.
Nato sem se osebno pogovorila z Antonin Isaninem. Razpravljali smo o potrebi po prenašanju DevOps kulture v vsak dom in razkrili temno plat DevOps transformacije.
Predstavljamo si, da so se vsi zbrali in odločili, da je DevOps potreben tako za izdelek kot tudi za podjetje in ekipo. Začeli smo z uvajanjem. Vse je uspelo. Zadihali smo. DevOps nas je pripeljal bližje strankam, zdaj bomo lahko hitro izpolnili vse njihove želje. Na koncu imamo veliko podpoglavje Ops z strogo urejenimi pravili in zahtevami, ki nenehno ustvarja napake v izdelku in oblikuje kup zahtevkov. Vse napake prihajajo s statusom 'nujno', tudi če je stranka nenadoma želela obarvati gumb v rumeno namesto v zeleno. Projekt raste, število izdaj se povečuje, posledično pa narašča tudi število napak in zmede glede nove funkcionalnosti s strani strank. Ops zaposli še 10 ljudi, da bi uspeli prijaviti napake, razvoj pa zaposli še 15, da bi jih zapirali. Namesto da bi uvajali nove funkcije, ekipa dela z neskončnimi «SD» nalogami, razlagajoč funkcionalnost uporabniku in tudi podpori. Na koncu sta tako Ops kot razvoj zaposlena, a stranka in podjetje nista zadovoljna: nove funkcije zastajajo. Izkazalo se je, da DevOps nekako obstaja, a ga dejansko ni.
Glede nujnosti uvajanja DevOps je Anton nedvomno izjavil, da to neposredno vpliva na obseg poslovanja. Če storitev enega naročnika na leto prinaša podjetju milijardo — DevOps ni potreben (pod pogojem, da ni potrebno redno uvajati novih sprememb za tega naročnika). Vse je že v redu. Ampak, če podjetje raste in se povečuje število strank, je treba že ustrezati. Običajno v podjetju sprva ni izjemnega Ops. Sprva razvijamo izdelek, šele nato razumemo, da je treba strežniki, paziti na dobavo. Takrat se pojavi Ops. Ostaja razumeti, da bo Ops kot ločen oddelek začel postavljati številne ovire za razvoj in vse dobave bodo začele stagnirati. To pomeni, da je v tem primeru kultura DevOps že aktualna, le da ne smemo pozabiti na njeno temno stran.
Izvor: habr.com
