Kohët e fundit mora pjesë në DevOpsForum 2019, të organizuar nga Logrocon. Në këtë konferencë, pjesëmarrësit kërkuan zgjidhje dhe mjete të reja për bashkëpunim efektiv midis bizneseve, profesionistëve të zhvillimit dhe mbështetjes së IT-së.
Konferenca ishte një sukses: pati vërtet shumë prezantime të dobishme, formate interesante prezantimi dhe shumë bashkëveprim me folësit. Dhe më e rëndësishmja, askush nuk u përpoq të më shiste asgjë, gjë që është një dukuri e zakonshme midis folësve në konferenca të mëdha këto kohë.
Më poshtë janë fragmente nga prezantimet e Raiffeisenbank dhe AlfaStrakhovanie, përvoja e Mango Telecom në zbatimin e automatizimit dhe detaje të tjera.
Emri im është Yana, punoj si testuese, e specializuar në automatizim dhe DevOps, dhe më pëlqen të shkoj në konferenca dhe takime. Gjatë dy viteve të fundit, kam marrë pjesë në konferencat e Oleg Bunin (HighLoad++, TeamLead Conf), eventet Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow dhe Big Data Moscow.
Gjëja e parë që shikoj është programi i konferencës. Jam më pak i shqetësuar për vetë prezantimin dhe më shumë për folësin. Edhe nëse prezantimi është shumë teknik dhe interesant, kjo nuk është një garanci se do të jeni në gjendje të zbatoni disa nga praktikat më të mira të tij në kompaninë tuaj. Atëherë keni nevojë për një folës.
Dritë në fund të tubacionit në Raiffeisenbank
Zakonisht kërkoj folës interesantë prapa skenave. Në DevOpsForum 2019, një folës nga Raiffeisenbank, Mikhail Bizhan, më tërhoqi vëmendjen. Gjatë prezantimit të tij, ai diskutoi se si ata i prezantojnë gradualisht ekipet e tyre me DevOps, pse kanë nevojë për të dhe si t'ua shesin idenë e transformimit të DevOps bizneseve. Ai foli gjithashtu se si të shihet drita në fund të procesit.
Mikhail Bizhan, Drejtor i Automatizimit në Raiffeisenbank
Aktualisht, kompania e tyre nuk ka "DevOps të vërtetë". Kjo është e vërtetë, por jo në të gjitha ekipet. Kur zbatojnë DevOps, ata mbështeten në gatishmërinë e ekipeve, si në aspektin e inxhinierëve individualë, nevojave të produktit, ashtu edhe pjekurisë së platformës mbi të cilën është ndërtuar produkti. Misha shpjegoi se si t'u shpjegohet DevOps bizneseve.
Sektori bankar ka disa faktorë që ndikojnë në rritje: kostot e shërbimit dhe zgjerimin e bazës së klientëve. Ndërsa rritja e kostove të shërbimit nuk është një faktor i mirë, rritja e bazës së klientëve është. Nëse konkurrentët publikojnë një produkt vërtet tërheqës, të gjithë klientët e tyre migrojnë dhe me kalimin e kohës, tregu stabilizohet. Prandaj, futja e produkteve të reja në treg dhe përshpejtimi i futjes së tyre është fokusi kryesor për bankat. Pikërisht për këtë shërben DevOps dhe bizneset e kuptojnë këtë.
Një pikë tjetër e rëndësishme: DevOps nuk e shkurton gjithmonë kohën e lançimit në treg. DevOps nuk mund të funksionojë vetëm; është thjesht pjesë e procesit të krijimit dhe sjelljes së një produkti në treg, nga zhvillimi te prodhimi (nga kodi te klienti). Por gjithçka para kodit nuk lidhet drejtpërdrejt me DevOps. Kjo do të thotë që marketerët mund të kalojnë vite duke studiuar tregun dhe të gjithë jetën e tyre duke u përpjekur të arrijnë konkurrentët. Është thelbësore të kuptohet shpejt se çfarë u nevojitet klientëve dhe të planifikohet zbatimi i një veçorie të caktuar - shpesh kjo është pikërisht ajo që mungon që DevOps të funksionojë dhe që një kompani të arrijë qëllimet e saj. Prandaj, përparësia e parë e Raiffeisenbank ishte të binte dakord me bizneset e saj mbi nevojën për të mësuar se si të përdorin DevOps. Automatizimi për hir të automatizimit nuk do të ndihmojë shumë në fitimin e klientëve të rinj.
Në përgjithësi, Misha beson se DevOps duhet të zbatohet, por me mençuri. Dhe duhet të jemi të përgatitur që produktiviteti i ekipit të bjerë dhe fitimet të ulen në fillim të transformimit, por në planin afatgjatë, kjo do të japë frytet e veta.
Automatizimi i testimit në Mango Telecom
Një tjetër prezantim interesant për mua si testues u mbajt nga Egor Maslov nga Mango Telecom. Prezantimi i tij titullohej "Automatizimi i Ciklit të Plotë të Testimit në një Ekip SCRUM". Egor beson se DevOps u krijua posaçërisht për SCRUM, por në të njëjtën kohë, zbatimi i DevOps në një ekip SCRUM është mjaft problematik. Kjo ndodh sepse një ekip SCRUM është vazhdimisht duke vrapuar, pa kohë për t'u përqendruar në inovacione dhe për të ridizajnuar procesin. Një problem tjetër është se SCRUM nuk lejon ndarjen e nëngrupeve brenda një ekipi (ekipi i testimit, ekipi i zhvillimit e kështu me radhë). Për më tepër, automatizimi i një procesi ekzistues kërkon dokumentacion, dhe në SCRUM, dokumentacioni shpesh mungon plotësisht - "produkti është më i rëndësishëm se disa dokumente".
Pasi kaluan në SCRUM, testuesit filluan të konsultoheshin me zhvilluesit se si të testonin veçoritë. Shtrirja e funksionalitetit u rrit gradualisht, mungonte dokumentacioni dhe ata filluan të kapnin gabime të shumta në veçoritë që nuk mbuloheshin nga testet dhe nuk ishte më e qartë se kush i kishte testuar ato ose kur. Shkurt, pati rrëmujë dhe konfuzion. Ata vendosën të kalonin në automatizimin e testimit. Por edhe atëherë, ishte një dështim i plotë. Ata punësuan specialistë automatizimi të jashtëm, të cilët shkruan në një grumbull të panjohur për testuesit e brendshëm. Korniza e testimit të automatizuar sigurisht që funksionoi, por pasi u larguan jashtëkontraktorët, zgjati vetëm dy javë. Pastaj erdhi përpjekja e dytë për testimin e automatizuar. Filloi me idenë se gjithçka duhej të ndërtohej brenda kompanisë, duke përdorur burimet tona (qasja e duhur: ndërtimi i ekspertizës së brendshme), brenda kornizës SCRUM, dhe se dokumentacioni duhej të krijohej gjatë rrugës. Grumbulli i automatizimit duhet të jetë i barabartë me grumbullin e produkteve (Unë jam padyshim dakord këtu; mos testoni një projekt JavaScript me asgjë tjetër). Në fund të sprintit, ata mbajtën një demonstrim të testit të automatizuar me të gjithë ekipin (i dobishëm). Kjo rriti angazhimin e ekipit në procesin e automatizimit, rriti besimin në testet e automatizuara dhe rriti mundësinë që testi i automatizuar të përdoret në të vërtetë (dhe të mos komentohet një muaj më vonë për shkak të dështimeve të përsëritura).
Rastësisht, DevOpsForum 2019 paraqiti një format prezantimi me mikrofon të hapur—një format prezantimi i njohur dhe, sipas mendimit tim, i dobishëm. Ju merrni pjesë, dëgjoni prezantimet dhe më pas vendosni që një temë ose problem i caktuar ia vlen të diskutohet në konferencë, duke ndarë zgjidhje përkatëse.
Gjithashtu vura re se organizatorët kishin organizuar një sërë prezantimesh të shkurtra. Çdo prezantim nuk zgjat më shumë se 10 minuta, i ndjekur nga pyetje. Në këtë mënyrë, mund të trajtoni shumë tema njëkohësisht dhe t'i bezdisni folësit me pyetje që ju interesojnë.
Midis prezantimeve, shëtita nëpër stendat e partnerëve të konferencës dhe rrëmbeva/fitova një mori dhuratash. Oh, sa shumë i dua dhuratat!
Diskutim në tryezë të rrumbullakët dhe pyetje DevOps me Drejtorin e Zhvillimit në AlfaStrakhovanie
Qershia mbi tortë e DevOpsForum 2019 për mua ishte seanca plenare njëorëshe me ekspertë të DevOps. Katër panelistë u ftuan për të eksploruar DevOps nga perspektiva të ndryshme: Anton Isanin (AlfaStrakhovanie, Drejtor i Zhvillimit), Nailya Zamashkina (Fintech Lab, Drejtor i Përgjithshëm i Operacioneve), Oleg Egorkin (Rostelecom, trajner i Agile) dhe Anton Martyanov (një ekspert i pavarur, që e shqyrton DevOps nga një perspektivë biznesi).
Ekspertët u ulën më afër audiencës dhe pastaj filloi gjithçka: për një orë të tërë, audienca bëri pyetje dhe ekspertët u përgjigjën. Ndonjëherë, pasuan debate të vërteta. Pyetjet varionin nga më të ndryshmet, duke përfshirë: a nevojiten fare inxhinierë DevOps? Pse nuk mund t'i zhvillojnë administratorët e sistemit? A duhet t'u ofrohet DevOps të gjithëve? Cila është vlera e tij?
Pastaj, fola personalisht me Anton Isanin. Diskutuam nevojën për ta sjellë kulturën DevOps në çdo shtëpi dhe zbuluam anën e errët të transformimit të DevOps.
Le të imagjinojmë që të gjithë u mblodhën dhe vendosën që DevOps ishte thelbësor për produktin, biznesin dhe ekipin. Ne nxituam ta zbatonim. Gjithçka funksionoi. Morëm një psherëtimë lehtësimi. DevOps na solli më afër klientit; tani mund t'i përmbushim shpejt të gjitha dëshirat e tyre. Rezultati është një departament i madh i Operacioneve me rregullore dhe kërkesa të rrepta, që vazhdimisht i godet defektet produktit, duke krijuar një mori tiketash. Për më tepër, të gjitha defektet shënohen si "urgjente", edhe nëse klienti papritmas dëshiron ta ngjyrosë një buton me të verdhë në vend të gjelbër. Projekti rritet, numri i publikimeve rritet dhe, në përputhje me rrethanat, numri i defekteve dhe keqkuptimeve në lidhje me funksionalitetin e ri midis klientëve rritet. Operacionet punësojnë 10 persona të tjerë për të vazhduar me raportimin e defekteve, dhe zhvillimi punëson 15 të tjerë për t'i ndjekur ato. Dhe në vend që të zbatojë veçori të reja, ekipi punon përmes SDK-ve të pafundme, duke u shpjeguar funksionalitetin përdoruesve dhe madje edhe mbështetjen në të njëjtën kohë. Në fund të fundit, si Operacionet ashtu edhe Zhvillimi janë të zënë, por klienti dhe biznesi janë të pakënaqur: veçoritë e reja kanë ngecur. Rezulton se DevOps në një farë mënyre ekziston, por në një farë mënyre jo.
Lidhur me nevojën për të zbatuar DevOps, Anton deklaroi pa mëdyshje se kjo varet drejtpërdrejt nga shkalla e biznesit. Nëse shërbimi ndaj një klienti në vit i sjell kompanisë një miliard, DevOps nuk është i nevojshëm (duke supozuar se nuk keni nevojë të ofroni ndryshime të reja për atë klient rregullisht). Gjithçka është tashmë në rregull. Por nëse biznesi rritet dhe fiton më shumë klientë, atëherë duhet të vazhdoni. Zakonisht, një kompani nuk ka një ekip të shkëlqyer Operacionesh që nga fillimi. Së pari, ne e përsosim produktin dhe vetëm atëherë e kuptojmë se që produkti të funksionojë, duhet të monitorojmë performancën e tij. serverat, monitorojnë dorëzimet. Këtu hyn në lojë Operacionet. Mbetet të shihet nëse Operacionet, si një departament i veçantë, do të fillojnë të vendosin një mori pengesash në zhvillim dhe të gjitha dorëzimet do të ngecin. Pra, në këtë rast, një kulturë DevOps është tashmë e rëndësishme, por nuk duhet të harrojmë anën e saj të errët.
Burimi: www.habr.com
