Së fundi kam marrë pjesë në DevOpsForum 2019, të organizuar nga Logrocon. Në këtë konferencë, pjesëmarrësit përpiqeshin të gjenin zgjidhje dhe mjete të reja për një bashkëpunim efektiv midis biznesit dhe specialistëve të zhvillimit dhe shërbimeve teknologjike informative.
Konferenca ishte e suksesshme: kishte shumë prezantime të dobishme, formate interesante të fjalimeve dhe shumë mundësi për të komunikuar me folësit. Dhe është veçanërisht e rëndësishme që askush nuk përpiqej të më shiste diçka, siç ndodh shpesh me folësit në konferencat e mëdha në kohët e fundit.
Përmbledhja e prezantimeve nga Raiffeisen Bank, Alfa Strahovanje, përvoja e Mango Telekom mbi implementimin e automatizimit dhe detaje të tjera më poshtë.
Më quajnë Jana, punoj si testuese, angazhohem me automatizimin, si dhe me DevOps dhe e adhuroj të shkoj në konferenca dhe takime. Në dy vitet e fundit kam qenë në konferencat e Oleg Bunin (HighLoad++, TeamLead Conf), në ngjarjet Jug (Heisenbug, JPoint), në TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
E para që vërej është programi i konferencës. Në një masë më të vogël shoh se për çfarë do jetë prezantimi, më shumë fokusohem te folësi. Edhe nëse prezantimi del të jetë shumë teknologjik dhe interesant, nuk është e sigurt që do të jesh në gjendje të aplikosh ndonjë praktikë të mirë nga prezantimi në kompaninë tënde. Prandaj, të duhen folës të mirë.
Drita në fund të pipeline-it në Raiffeisen Bank
Zakonisht, unĂ« organizoj njĂ« gjueti pĂ«r folĂ«s tĂ« interesantĂ« nĂ« kulisat. NĂ« DevOpsForum 2019, folĂ«si qĂ« mĂ« interesoi ishte nga Raiffeisen Bank â Mikhail Bizhan. GjatĂ« prezantimit, ai tregoi se si janĂ« duke integruar gradualisht ekipet e tyre nĂ« DevOps, pse u nevojitet kjo dhe si t'ia shesin idenĂ« e transformimit DevOps biznesit. Ai gjithashtu foli pĂ«r mĂ«nyrĂ«n se si tĂ« shohĂ«sh dritĂ«n nĂ« fund tĂ« pipeline-it.
Mikhail Bizhan, drejtor i automatizimit në Raiffeisen Bank
Aktualisht, nĂ« kompaninĂ« e tyre nuk ka "tĂ« vĂ«rtetĂ« DevOps". Do tĂ« thotĂ«, Ă«shtĂ« i vĂ«rtetĂ«, por jo nĂ« tĂ« gjitha ekipet. GjatĂ« implementimit tĂ« DevOps, ata mbĂ«shteten nĂ« gatishmĂ«rinĂ« e ekipeve nga kĂ«ndvĂ«shtrimi i inxhinierĂ«ve konkretĂ«, si dhe nga nevoja e produktit dhe pjekuria e platformĂ«s mbi tĂ« cilĂ«n Ă«shtĂ« ndĂ«rtuar ky produkt. Misha shpjegoi se si tâi sqarosh biznesit pse Ă«shtĂ« e nevojshme DevOps.
Sektori bankar ka disa motorë rritjeje: kostoja e shërbimeve dhe zgjerimi i bazës së klientëve. Rritja e kostos së shërbimeve nuk është një motor shumë i mirë, ndërsa rritja e bazës së klientëve është përkundrazi. Nëse konkurruesit nxjerrin një produkt objektivisht të shkëlqyer, të gjithë klientët do të shkojnë aty dhe me kalimin e kohës tregu do të rregullohet. Prandaj, nxjerrja e produkteve të reja në treg dhe shpejtësia e nxjerrjes së tyre është gjëja kryesore në të cilën bankat përqendrohen. Pikërisht për këtë është e nevojshme DevOps, dhe biznesi e kupton këtë.
NjĂ« vĂ«rejtje tjetĂ«r e rĂ«ndĂ«sishme: DevOps nuk e zvogĂ«lon gjithmonĂ« koha deri nĂ« treg. DevOps nuk mund tĂ« funksionojĂ« njĂ«soj, Ă«shtĂ« vetĂ«m njĂ« pjesĂ« e procesit tĂ« krijimit dhe nxjerrjes sĂ« produktit nĂ« treg nga zhvillimi deri nĂ« prodhim (nga kodi deri te klienti). Por gjithçka qĂ« ndodh para kodit, nuk ka lidhje tĂ« drejtpĂ«rdrejtĂ« me DevOps. Do tĂ« thotĂ«, tregtarĂ«t mund tĂ« studiojnĂ« tregun pĂ«r vite me radhĂ« dhe tĂ« ndjekin konkurrencĂ«n gjatĂ« gjithĂ« jetĂ«s sĂ« tyre. ĂshtĂ« e nevojshme tĂ« kuptohet shpejt se çfarĂ« i nevojitet klientit dhe tĂ« planifikohet realizimi i ndonjĂ« funksionaliteti â shpesh kjo Ă«shtĂ« ajo qĂ« i mungon pĂ«r tĂ« funksionuar DevOps dhe pĂ«r tĂ« arritur qĂ«llimin e kompanisĂ«. Prandaj, sĂ« pari nĂ« Raiffeisen Bank u dakorduan me biznesin qĂ« duhet tĂ« mĂ«sojnĂ« si tĂ« pĂ«rdorin DevOps. Automatizimi pĂ«r shkak tĂ« automatizimit nuk do t'i ndihmojĂ« shumĂ« nĂ« luftĂ«n pĂ«r klientĂ« tĂ« rinj.
Në përgjithësi, Misha mendon se DevOps duhet të implementohet, por me mençuri. Dhe duhet të jesh i gatshëm për faktin se në fillim të transformimit, performanca e ekipit do të bie, do të fitojnë më pak para, por pastaj kjo do të justifikojë veten.
Automatizimi i testimit në "Mango Telekom"
NjĂ« tjetĂ«r prezantim interesant pĂ«r mua si testuese u bĂ« nga Yegor Maslov nga "Mango Telekom". Prezantimi ishte titulluar "Automatizimi i ciklit tĂ« plotĂ« tĂ« testimit nĂ« ekipin SCRUM". Yegor beson se DevOps Ă«shtĂ« krijuar pikĂ«risht pĂ«r SCRUM, por njĂ«kohĂ«sisht, implementimi i DevOps nĂ« njĂ« ekip SCRUM Ă«shtĂ« mjaft problematik. Kjo ndodh sepse ekipi SCRUM gjithmonĂ« Ă«shtĂ« duke vrapuar, nuk ka kohĂ« pĂ«r t'u shpĂ«rndarĂ« pĂ«r risitĂ« dhe pĂ«r tĂ« riparĂ« procesin. Problemi Ă«shtĂ« gjithashtu se SCRUM nuk parashikon ndarjen e nĂ«n-equipave nĂ« ekip (ekipi i testuesve, ekipi i zhvilluesve, etj.). Dhe pĂ«r mĂ« tepĂ«r, pĂ«r automatizimin e procesit ekzistues nevojitet dokumentacion, ndĂ«rsa nĂ« SCRUM zakonisht dokumentacioni Ă«shtĂ« krejtĂ«sisht i munguar â "produkti Ă«shtĂ« mĂ« i rĂ«ndĂ«sishĂ«m se ndonjĂ« shkrim".
Pas kalimi nĂ« SCRUM, testuesit filluan tĂ« konsultohen me zhvilluesit se si tĂ« testojnĂ« tiparet. NgadalĂ«, sasia e funksionalitetit u rrit, dokumentacioni mungonte, dhe ata filluan tĂ« zbulonin shumĂ« gabime nĂ« funksionalitetin ku nuk kishte mbulim testimi dhe nuk ishte e qartĂ« kush dhe kur e kishte testuar. NĂ« dy fjalĂ« â kaos. VendosĂ«m tĂ« kalojmĂ« nĂ« automatizimin e testimit. Por edhe atĂ«herĂ« ndodhi njĂ« dĂ«shtim total. Ata sollĂ«n specialistĂ« tĂ« jashtĂ«m pĂ«r automatizimin, tĂ« cilĂ«t shkruanin nĂ« njĂ« teknologji tĂ« panjohur pĂ«r testuesit e brendshĂ«m. Ăadra pĂ«r testet automatike sigurisht qĂ« punonte, por pasi qĂ« specialistĂ«t e jashtĂ«m u larguan, ajo jetoi vetĂ«m dy javĂ«. MĂ« pas kishte njĂ« pĂ«rpjekje tĂ« dytĂ« pĂ«r tĂ« futur testimin automatizues. Kjo filloi me idenĂ« se gjithçka duhej ndĂ«rtuar brenda kompanisĂ«, me forcat tona (nĂ« drejtimin e duhur: rritni ekspertizĂ«n brenda), brenda kornizĂ«s SCRUM, dhe nĂ« proces tĂ« krijojmĂ« dokumentacion. Stack pĂ«r automatizimin duhet tĂ« jetĂ« i njĂ«jtĂ« me stack-un e produktit (kĂ«tu e shoh si njĂ« pĂ«rfitim, nĂ«se nuk testoni njĂ« projekt nĂ« JavaScript me diçka tjetĂ«r). NĂ« fund tĂ« sprint-it ata organizonin njĂ« demo pĂ«r tĂ« treguar si punonte testimi automatizues, me pjesĂ«marrjen e gjithĂ« ekipit (e dobishme). NĂ« kĂ«tĂ« mĂ«nyrĂ«, pĂ«rfshirja e tĂ« gjithĂ« anĂ«tarĂ«ve tĂ« ekipit nĂ« procesin e automatizimit u rrit, si dhe besimi nĂ« testet automatizues dhe shanset qĂ« kjo testim automatizues tĂ« pĂ«rdoret (dhe jo tĂ« komentohet pas njĂ« muaji pĂ«r shkak tĂ« dĂ«shtimeve tĂ« vazhdueshme).
NdĂ«rkohĂ«, nĂ« DevOpsForum 2019 kishte njĂ« mikrofon tĂ« hapur â njĂ« format i njohur dhe, sipas mendimit tim, i dobishĂ«m pĂ«r ligjĂ«rata. Ecni, dĂ«gjoni prezantimet dhe pastaj vendosni qĂ« gjatĂ« konferencĂ«s tĂ« diskutoni rreth njĂ« teme ose problemi, tĂ« ndani pĂ«rvojĂ«n pĂ«rkatĂ«se nĂ« zgjidhjen e njĂ« tasku.
Vezhgjova gjithashtu se organizatorĂ«t krijuan njĂ« rrjedhĂ« tĂ« prezantimeve tĂ« shkurtra. Ădo prezantim zgjat jo mĂ« shumĂ« se 10 minuta, pastaj vijnĂ« pyetjet. NĂ« kĂ«tĂ« mĂ«nyrĂ« mund tĂ« mbuloni shumĂ« tema menjĂ«herĂ« dhe tĂ« ngriheni me pyetje pĂ«r folĂ«sit qĂ« ju interesojnĂ«.
Midis prezantimeve, dola për të vizituar stendat e partnerëve të konferencës dhe fitova shumë gjëra interesante. Ah, sa e dua shpërndarjen!
Tryeza e rrumbullakët dhe pyetje të DevOps me drejtorin e zhvillimit në Alfastrahovany
Një nga momentet më të rëndësishme të DevOpsForum 2019 për mua ishte një sesion plenarnë njëorësh me ekspertë të DevOps. U ftuan katër pjesëmarrës në sesion, të cilët duhet të shikonin DevOps nga kënde të ndryshme: Anton Isanin (Alfastrahovany, drejtor i zhvillimit), Nailya Zamashkina (Fintech Lab, drejtoreshë operative), Oleg Egorkin (Rostelecom, Koha Agile) dhe Anton Martyanov (ekspert i pavarur, që shqyrtonte DevOps nga këndvështrimi i biznesit).
Ekspertët u ulën më afër publikut dhe filloi diskutimi: për një orë të tërë, pjesëmarrësit në sallë bënin pyetje, dhe ekspertët përpiqeshin të përgjigjeshin. Nganjëherë ndodhnin debatet e vërteta. Pyetjet ishin të larmishme, p.sh.: a nevojiten të vërtetë inxhinierë DevOps, pse s'mund t'i rrisim ata nga administratorët e sistemit, a duhet të ofrojmë DevOps për të gjithë, cila është vlera e tij dhe kështu me radhë.
Më pas, bisedova personalisht me Anton Isanin. Diskutuam për nevojën për të sjellë kulturën DevOps në çdo shtëpi dhe zbuluam anën e errët të transformimit DevOps.
Imagjinoni se të gjithë u mblodhën dhe vendosën se DevOps ishte i nevojshëm si për produktin, ashtu edhe për biznesin dhe ekipin. Filluan implementimin. Të gjitha shkuan mirë. Dola një frymëzim. DevOps na afroi me klientin, tani mund ta përmbushim shpejt të gjitha dëshirat e tij. Në përfundim, kemi një njësi të madhe Ops me rregulla dhe kërkesa të rrepta, dhe ajo vazhdon të gjenerojë defekte në produkt, të krijojë shumë kërkesa. Ndërkohë, të gjitha defektet kanë statusin "urgjente", edhe nëse klienti papritur vendosi të ngjyrosë butonin në ngjyrë të verdhë në vend të gjelbër. Projekti rritet, rritet numri i lëshimeve dhe për pasojë numri i defekteve dhe keqkuptimeve të funksionaliteteve të reja nga klientët. Ops punëson edhe 10 njerëz, për të pasur kohë për të raportuar defektet, ndërsa zhvillimi punëson edhe 15, për të pasur kohë për t'i mbyllur ato. Dhe në vend që të implementojnë tipare të reja, ekipi punon me SD pa fund, duke shpjeguar funksionalitetin për përdoruesin dhe gjithashtu për mbështetje. Në përfundim, dhe Ops, dhe zhvillimi janë të angazhuar, por klienti dhe biznesi janë të pakënaqur: tiparet e reja ngecin. Kështu, DevOps duket se është aty, por në të njëjtën kohë sikur nuk është.
Rreth nevojĂ«s pĂ«r tĂ« implementuar DevOps, Anton theksoi se kjo varet drejtpĂ«rdrejt nga pĂ«rmasat e biznesit. NĂ«se shĂ«rbimi pĂ«r njĂ« klient nĂ« vit sjell njĂ« miliard pĂ«r kompaninĂ« â DevOps nuk Ă«shtĂ« i nevojshĂ«m (pĂ«r sa kohĂ« qĂ« nuk ke nevojĂ« t'i ofrosh kĂ«tij klienti ndryshime tĂ« reja rregullisht). TĂ« gjithĂ« janĂ« mirĂ«. Por nĂ«se biznesi rritet dhe ka mĂ« shumĂ« klientĂ«, atĂ«herĂ« duhet tĂ« pĂ«rshtatemi. Rregullisht, njĂ« Ops i shkĂ«lqyer nuk ekziston nĂ« kompanitĂ« fillimisht. Fillimisht zhvillojmĂ« produktin dhe vetĂ«m mĂ« vonĂ« kuptojmĂ« se pĂ«r tĂ« funksionuar, duhet tĂ« kemi kujdes pĂ«r serverĂ«ve, tĂ« ndjekim dĂ«rgesat. AtĂ«herĂ« lind Ops. Duhet tĂ« kuptojmĂ« se Ops, si njĂ« departament i veçantĂ«, do tĂ« fillojĂ« tĂ« vendosĂ« shumĂ« pengesa pĂ«r zhvillimin dhe tĂ« gjitha dĂ«rgesat do tĂ« fillojnĂ« tĂ« ngadalĂ«sohen. Pra, nĂ« kĂ«tĂ« rast, kultura DevOps tashmĂ« Ă«shtĂ« relevante, vetĂ«m se nuk duhet tĂ« harrojmĂ« anĂ«n e saj negative.
Burimi: habr.com
