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
