Së fundmi, 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 mes bizneseve dhe specialistëve të zhvillimit dhe shërbimeve teknologjike.
Konferenca ishte e suksesshme: kishte vërtet shumë prezantime të dobishme, formate interesante të fjalimeve dhe shumë biseda me folësit. Dhe veçanërisht e rëndësishme ishte se askush nuk përpiqej të më shiste ndonjë gjë, gjë që është bërë e zakonshme në konferencat e mëdha kohëve të fundit.
Përmbledhje nga prezantimet e Raiffeisen Bank, Alpha Insurance, përvoja e Mango Telecom në zbatimin e automatizimit dhe detaje të tjera më poshtë.
Më quajnë Yana, punoj si testuese, merrem me automatizim, si dhe DevOps dhe e adhuroj të shkoj në konferenca dhe meetupa. Gjatë dy viteve të 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.
Gjëja e parë që e vë re është programu i konferencës. Në një farë mase, shoh se për çfarë do të flitet, por në masë më të madhe, shoh folësin. Edhe nëse prezantimi del të jetë shumë teknologjik dhe interesant, nuk ka garanci që do të mund të aplikosh ndonjë praktikë të mirë nga ai prezantim në kompaninë tënde. Dhe atëherë, të nevojitet një folës.
Drita në fund të pipeline në Raiffeisen Bank
Zakonisht, organizoj një përndjekje për folësit interesante për mua në kuluarë. Në DevOpsForum 2019, në qendrën e interesit tim ra një folës nga Raiffeisen Bank - Mikhail Bijan. Gjatë prezantimit, ai tregoi se si ata gradualisht po e kalojnë ekipet e tyre në DevOps, përse u nevojitet kjo dhe se si të shesin idenë e transformimit DevOps në biznes. Po ashtu, ai foli për se si të shohim dritën në fund të pipeline-it.
Mikhail Bijan, drejtor i automatizimit në Raiffeisen Bank
Tani në kompaninë e tyre nuk ka "trush DevOps". Pra, është real, por jo në të gjitha ekipet. Gjatë zbatimit të DevOps, ata mbështeten në gatishmërinë e ekipeve si nga pikëpamja e inxhinierëve konkretë ashtu edhe nga pikëpamja e nevojave të produktit dhe pjekurisë së platformës mbi të cilën është ndërtuar ky produkt. Misha tregoi se si t'u shpjegosh biznesit pse u nevojitet DevOps.
Sektori bankar ka disa motorë rritjeje: kostot e shërbimeve dhe zgjerimi i bazës së klientëve. Rritja e kostove të shërbimeve nuk është një motor shumë i mirë, ndërsa rritja e bazës së klientëve është e kundërta. Nëse konkurentët nxjerrin një produkt objektivisht të shkëlqyer, të gjithë klientët shkojnë atje, pastaj me kalimin e kohës tregu stabilizohet. Prandaj, lançimi i produkteve të reja dhe shpejtësia e lançimit të tyre është gjëja kryesore ndaj së cilës bankat orientohen. Pikërisht për këtë qëllim është e nevojshme DevOps, dhe biznesi e kupton këtë.
NjĂ« vĂ«rejtje tjetĂ«r e rĂ«ndĂ«sishme: DevOps nuk i redukton gjithmonĂ« kohĂ«t pĂ«r tregun. DevOps nuk mund tĂ« punojĂ« vetĂ«m, ai Ă«shtĂ« thjesht njĂ« pjesĂ« e procesit tĂ« krijimit dhe lançimit tĂ« produktit nĂ« treg nga zhvillimi deri te prodhimi (nga kodi te klienti). Por gjithçka para kodit, nuk ka tĂ« bĂ«jĂ« drejtpĂ«rdrejt me DevOps. Kjo do tĂ« thotĂ« se marketerĂ«t mund tĂ« studiojnĂ« tregun pĂ«r vite me radhĂ« dhe tĂ« mbajnĂ« hapin me konkurentĂ«t gjithĂ« jetĂ«n. ĂshtĂ« e nevojshme tĂ« kuptojmĂ« shpejt se çfarĂ« dĂ«shiron klienti dhe tĂ« planifikojmĂ« realizimin e ndonjĂ« veçorie - shpesh pikĂ«risht kjo u mungon qĂ« DevOps tĂ« funksionojĂ« dhe kompania tĂ« arrijĂ« qĂ«llimin. Prandaj, fillimisht nĂ« Raiffeisen Bank u dakordua me biznesin qĂ« duhet tĂ« mĂ«sojnĂ« tĂ« pĂ«rdorin DevOps. Automatizimi pĂ«r hir tĂ« automatizimit nuk do tĂ« ndihmojĂ« shumĂ« nĂ« luftĂ«n pĂ«r klientĂ« tĂ« rinj.
Në përgjithësi, Misha mendon se DevOps duhet të implementohet, por me arsyetim. Dhe duhet të jesh i gatshëm që në fillim të transformimit, ekipi do të ketë rënie të produktivitetit, do të fitojë më pak para, por më pas kjo do të justifikohet.
Automatizimi i testimit në 'Mango Telecom'
NjĂ« tjetĂ«r paraqitje interesant pĂ«r mua si testues ishte bĂ«rĂ« nga Egor Maslov nga «Mango Telecom». Prezentimi titullohej «Automatizimi i ciklit tĂ« plotĂ« tĂ« testimit nĂ« ekipin SCRUM». Egor beson se DevOps Ă«shtĂ« krijuar pikĂ«risht pĂ«r SCRUM, por gjithashtu Ă«shtĂ« mjaft problematike tĂ« implementosh DevOps nĂ« njĂ« ekip SCRUM. Kjo ndodh sepse ekipi SCRUM gjithmonĂ« Ă«shtĂ« nĂ« njĂ« garĂ«, nuk ka kohĂ« pĂ«r tĂ« theksuar risitĂ« dhe pĂ«r tĂ« ristrukturuar procesin. Problemi Ă«shtĂ« gjithashtu se SCRUM nuk parashikon ndarjen e sub-ekipave nĂ« ekip (ekipi i testuesve, ekipi i zhvilluesve dhe kĂ«shtu me radhĂ«). PĂ«r mĂ« tepĂ«r, pĂ«r tĂ« automatizuar procesin ekzistues nevojitet dokumentacion, dhe nĂ« SCRUM zakonisht dokumentacioni Ă«shtĂ« krejtĂ«sisht i munguar â «produkti Ă«shtĂ« mĂ« i rĂ«ndĂ«sishĂ«m se ndonjĂ« shkrim».
Pas kalimit nĂ« SCRUM, testuesit filluan tĂ« konsultoheshin me zhvilluesit se si tĂ« testonin karakteristikat. Gradualisht, volumi i funksionaliteteve u rrit, dokumentacioni mungonte, dhe ata filluan tĂ« zbulojnĂ« shumĂ« gabime nĂ« funksionalitetet qĂ« nuk kishin mbulim me teste dhe pĂ«r mĂ« tepĂ«r nuk ishte e qartĂ« kush dhe kur e kishte testuar atĂ«. NĂ« dy fjalĂ« â kaos dhe shpĂ«rndarje. Ata vendosĂ«n tĂ« kalonin nĂ« automatizimin e testimit. Por edhe atĂ«herĂ« ndodhi njĂ« dĂ«shtim total. Ata angazhuan specialistĂ« tĂ« jashtĂ«m pĂ«r automatizimin, tĂ« cilĂ«t shkruanin nĂ« njĂ« stack tĂ« panjohur pĂ«r testuesit e brendshĂ«m. Framworku pĂ«r testet automatike sigurisht funksionoi, por pasi qĂ« specialistĂ«t e jashtĂ«m u larguan, ai jetoi vetĂ«m dy javĂ«. Pastaj ishte pĂ«rpjekja e dytĂ« pĂ«r tĂ« futur testimin automatizues. Ajo filloi me idenĂ« se gjithçka duhet tĂ« ndĂ«rtohet brenda kompanisĂ«, me forcat e veta (direksioni i duhur: rritni ekspertizĂ«n brenda), nĂ« kuadĂ«r tĂ« SCRUM, dhe gjatĂ« procesit tĂ« krijoni dokumentacion. Stack pĂ«r automatizim duhet tĂ« jetĂ« i barabartĂ« me stack-un e produktit (kĂ«tĂ« e mbĂ«shtes fort, mos e testoni projektin nĂ« JavaScript me diçka tjetĂ«r). NĂ« fund tĂ« sprintit, ata organizonin njĂ« demo se si funksiononte testi 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 automatizuese dhe mundĂ«sia qĂ« ky test automatizues do tĂ« pĂ«rdorej me siguri (nuk do tĂ« ishte shenjĂ«zuar pas njĂ« muaji pĂ«r shkak tĂ« dĂ«shtimeve tĂ« vazhdueshme).
NĂ« DevOpsForum 2019 kishte njĂ« mikrofon tĂ« hapur â njĂ« format i njohur prej kohĂ«sh dhe, sipas mendimit tim, shumĂ« i dobishĂ«m pĂ«r lĂ«shimin e fjalimeve. Ti shkon, dĂ«gjon prezantimet dhe pastaj vendos se Ă«shtĂ« e nevojshme tĂ« diskutosh njĂ« temĂ« ose problem brenda konferencĂ«s, duke ndarĂ« pĂ«rvojĂ«n relevante tĂ« zgjidhjes sĂ« detyrave.
Gjithashtu, vura re se organizatorĂ«t kishin krijuar njĂ« rrjedhĂ« prezantimesh tĂ« shkurtra. Ădo prezantim zgjat jo mĂ« shumĂ« se 10 minuta, pastaj ndodhin pyetje. NĂ« kĂ«tĂ« mĂ«nyrĂ«, mund tĂ« kapesh me shumĂ« tema dhe t'u drejtohesh pyetjeve folĂ«sve qĂ« tĂ« kanĂ« interesuar.
Mes prezantimeve, bëra një shëtitje mes standeve të partnerëve të konferencës dhe fitova shumë gjëra të ndryshme. Ah, sa e dua ndarjen e materialeve!
Tavolina e rrumbullakët dhe pyetje DevOps me drejtorin për zhvillim në Alfastosurance
Kirshta mbi tortën DevOpsForum 2019 për mua ishte një sesion plen i një ore me ekspertët e DevOps. U ftuan katër pjesëmarrës në sesion, të cilët duhej të shihnin DevOps nga këndvështrime të ndryshme: Anton Isanin (Alfastosurance, drejtor i zhvillimit), Nailya Zamashkina (Fintech Lab, drejtoreshë operative), Oleg Yegorkin (Rostelecom, trajner Agile) dhe Anton Martyjanov (ekspert i pavarur, që e shikonte DevOps nga këndvështrimi i biznesit).
Ekspertët u ulën pranë publikut dhe këtu filloi: për një orë të tërë pjesëmarrësit nga salla i drejtonin pyetjet e tyre, ndërsa ekspertët u përballën me to. Ndonjëherë, ndodhnin debate të vërteta. Pyetjet ishin nga më të ndryshmet, për shembull: a janë të nevojshëm inxhinierët DevOps, pse nuk mund t'i rrisim ata nga administratoret e sistemeve, duhet t'u ofrohet të gjithëve DevOps, cilësia e tij dhe kështu me radhë.
Më pas, pata një bisedë personale me Anton Isaninin. 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.
Supozoni qĂ« tĂ« gjithĂ« u mblodhĂ«n dhe vendosĂ«n se DevOps Ă«shtĂ« i nevojshĂ«m si pĂ«r produktin ashtu edhe pĂ«r biznesin dhe ekipin. Filluam ta implementojmĂ«. Gjithçka shkoi mirĂ«. U qetĂ«suam. DevOps na afroi me klientin, tani mund tĂ« pĂ«rmbushim shpejt tĂ« gjitha kĂ«rkesat e tij. NĂ« fund tĂ« fundit, kemi njĂ« departament tĂ« madh Ops me rregulla tĂ« rrepta dhe kĂ«rkesa, dhe ai vazhdon tĂ« dĂ«rgojĂ« defekte nĂ« produkt, duke krijuar shumĂ« kĂ«rkesa. Dhe tĂ« gjitha defektet vijnĂ« me statusin " urgjent ", edhe nĂ«se klienti papritmas dĂ«shiron tĂ« ngjyrosĂ« butonin nĂ« tĂ« verdhĂ« nĂ« vend tĂ« gjelbĂ«rt. Projekti rritet, numri i publikimeve rritet dhe pĂ«r rrjedhojĂ«, rritet edhe numri i defekteve dhe moskuptimeve rreth funksionaliteteve tĂ« reja nga klientĂ«t. Ops angazhon edhe 10 njerĂ«z pĂ«r tĂ« arritur tĂ« raportojnĂ« defektet, ndĂ«rsa zhvillimi angazhon edhe 15, pĂ«r tâi mbyllur ato. Dhe nĂ« vend qĂ« tĂ« implementojnĂ« funksionalitete tĂ« reja, ekipi punon me SD tĂ« pafundme, duke shpjeguar funksionalitetet pĂ«rdoruesit dhe gjithashtu mbĂ«shtetjes. NĂ« fund tĂ« fundit, tĂ« dy Ops dhe zhvillimi janĂ« tĂ« angazhuar, por klienti dhe biznesi janĂ« tĂ« pakĂ«naqur: funksionalitetet e reja ngecin. KĂ«shtu qĂ«, duket se ka DevOps, por gjithashtu nuk duket tĂ« ketĂ«.
PĂ«r domosdoshmĂ«rinĂ« e implementimit tĂ« DevOps, Anton e deklaroi gjithashtu se kjo varet drejtpĂ«rdrejt nga shkalla e biznesit. NĂ«se shĂ«rbimi pĂ«r njĂ« klient nĂ« vit sjell njĂ« miliard pĂ«r kompaninĂ« â DevOps nuk Ă«shtĂ« i nevojshĂ«m (nĂ«n kushtin se nuk ke nevojĂ« tĂ« publikosh ndryshime tĂ« reja pĂ«r atĂ« klient rregullisht). Gjithçka Ă«shtĂ« nĂ« rregull. Por nĂ«se biznesi rritet, shfaqen mĂ« shumĂ« klientĂ«, atĂ«herĂ« duhet tĂ« pĂ«rputhemi. Si rregull, njĂ« Ops i shkĂ«lqyer nuk ekziston fillimisht nĂ« kompaninĂ«. Fillimisht ne zhvillojmĂ« produktin dhe mĂ« pas kuptojmĂ« se pĂ«r tĂ« funksionuar produkti, duhet tĂ« mbajmĂ« nĂ«n mbikĂ«qyrje, serverĂ«, tĂ« mbajmĂ« nĂ«n mbikĂ«qyrje furnizimet. AtĂ«herĂ« shfaqet Ops. Duhet tĂ« kuptojmĂ« se Ops, si njĂ« njĂ«si e veçantĂ« do tĂ« fillojĂ« tĂ« vendosĂ« shumĂ« barriera pĂ«r zhvillimin dhe tĂ« gjitha furnizimet do tĂ« fillojnĂ« tĂ« pengohen. Pra, nĂ« kĂ«tĂ« rast kultura DevOps Ă«shtĂ« aktuale, vetĂ«m duhet tĂ« mos harrojmĂ« anĂ«n e saj tĂ« errĂ«t.
Burimi: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish