Kohët e fundit kam marrë pjesë në DevOpsForum 2019, të organizuar nga Logrocon. Në këtë konferencë, pjesëmarrësit u përpoqën të gjenin zgjidhje dhe mjete të reja për ndërveprim efektiv midis biznesit dhe specialistëve të shërbimeve të zhvillimit dhe teknologjisë së informacionit.
Konferenca ishte një sukses: pati vërtet shumë raporte të dobishme, formate interesante të prezantimit dhe shumë komunikim me folësit. Dhe është veçanërisht e rëndësishme që askush nuk u përpoq të më shiste asgjë, diçka për të cilën folësit në konferenca të mëdha kanë qenë fajtorë kohët e fundit.
Një fragment nga fjalimet e Raiffeisenbank, Alfastrakhovanie, përvoja e Mango Telecom në zbatimin e automatizimit dhe detaje të tjera nën prerje.
Emri im është Yana, punoj si testues, bëj automatizim, si dhe DevOps, dhe më pëlqen të shkoj në konferenca dhe takime. Gjatë dy viteve të fundit, kam qenë në konferencat e Oleg Bunin (HighLoad++, TeamLead Conf), ngjarjet Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Para së gjithash, tërheq vëmendjen te programi i konferencës. Unë shikoj më pak se çfarë do të jetë raporti, dhe më shumë tek folësi. Edhe nëse raporti rezulton të jetë shumë teknologjik dhe interesant, nuk është fakt që ju do të mund të aplikoni disa nga praktikat më të mira nga raporti në kompaninë tuaj. Dhe pastaj ju duhet një altoparlant.
Drita në fund të gazsjellësit në Raiffeisenbank
Zakonisht, kërkoj folës anash që më interesojnë. Në DevOpsForum 2019, një folës nga Raiffeisenbank, Mikhail Bizhan, tërhoqi interesin tim. Gjatë fjalimit të tij, ai foli se si ata gradualisht po i lidhin ekipet e tyre në DevOps, pse u duhen dhe si t'ia shesin idenë e transformimit të DevOps në biznes. Epo, në përgjithësi, fola se si ta shoh dritën në fund të tubacionit.
Mikhail Bizhan, drejtor i automatizimit në Raiffeisenbank
Tani ata nuk kanë "DevOps" në kompaninë e tyre. Domethënë punon, por jo në të gjitha ekipet. Gjatë zbatimit të DevOps, ata mbështeten në gatishmërinë e ekipeve, si për sa i përket inxhinierëve specifikë, ashtu edhe për sa i përket nevojës së produktit dhe pjekurisë së platformës mbi të cilën është ndërtuar ky produkt. Misha tha se si t'i shpjegojë një biznesi pse nevojitet DevOps.
Segmenti bankar ka disa nxitës rritjeje: kostoja e shërbimeve dhe zgjerimi i bazës së klientëve. Rritja e kostos së shërbimeve nuk është një shtysë shumë e mirë, por rritja e bazës së klientëve është e kundërta. Nëse konkurrentët lëshojnë një produkt objektivisht të lezetshëm, të gjithë klientët shkojnë atje, atëherë me kalimin e kohës tregu nivelohet. Prandaj, futja e produkteve të reja në treg dhe shpejtësia e prezantimit të tyre është gjëja kryesore në të cilën fokusohen bankat. Kjo është pikërisht ajo për të cilën është DevOps dhe bizneset e kuptojnë këtë.
Shënimi tjetër i rëndësishëm: DevOps jo gjithmonë zvogëlon kohën në treg. DevOps nuk mund të funksionojë vetëm, është vetëm pjesë e procesit të krijimit dhe sjelljes së një produkti në treg nga zhvillimi në prodhim (nga kodi te klienti). Por gjithçka përpara kodit nuk lidhet drejtpërdrejt me DevOps. Kjo do të thotë, tregtarët mund të studiojnë tregun për vite dhe të kalojnë gjithë jetën e tyre duke kapur konkurrencën. Shtë e nevojshme të kuptoni shpejt se çfarë i nevojitet klientit dhe të planifikoni zbatimin e kësaj ose asaj veçorie - shpesh kjo është ajo që nuk mjafton që DevOps të funksionojë dhe kompania të arrijë qëllimin e saj. Prandaj, para së gjithash, Raiffeisenbank ra dakord me biznesin se ishte e nevojshme të mësohej se si të përdorni DevOps. Automatizimi për hir të automatizimit nuk do të ndihmojë shumë në luftën për klientët e rinj.
Në përgjithësi, Misha beson se DevOps duhet të zbatohet, por me mençuri. Dhe ne duhet të jemi të përgatitur për faktin se në fillim të transformimit produktiviteti i ekipit do të bjerë, do të fitojë më pak para, por më pas do të justifikohet.
Automatizimi i testimit në Mango Telecom
Një raport tjetër interesant për mua si testues është dhënë nga Egor Maslov nga Mango Telecom. Prezantimi u quajt "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ë, futja e DevOps në një ekip SCRUM është mjaft problematike. Kjo ndodh sepse ekipi i SCRUM është gjithmonë duke vrapuar diku, nuk ka kohë për t'u shpërqendruar nga risitë dhe për të rindërtuar procesin. Problemi qëndron gjithashtu në faktin se SCRUM nuk përfshin ndarjen e nën-skuadrave në ekip (ekipin e testimit, ekipin e zhvillimit, etj.). Epo, përveç kësaj, për të automatizuar një proces ekzistues, nevojitet dokumentacion, dhe në SCRUM, më shpesh nuk ka dokumentacion plotësisht - "produkti është më i rëndësishëm se një lloj shkrimi".
Pas kalimit në SCRUM, testuesit filluan të konsultohen me zhvilluesit se si të testonin veçoritë. Gradualisht, vëllimi i funksionalitetit u rrit, nuk kishte dokumentacion dhe filluan të kapnin shumë gabime në funksionalitetin që nuk mbulohej nga testet dhe në përgjithësi nuk ishte më e qartë se kush dhe kur e testoi. Me pak fjalë - konfuzion dhe lëkundje. Ne vendosëm të kalonim në automatizimin e testimit. Por edhe atëherë pati një dështim të plotë. Ata punësuan specialistë të automatizimit të jashtëm, të cilët shkruanin në një pirg të panjohur për testuesit e brendshëm. Kuadri për autotestet funksionoi, sigurisht, por pasi u larguan të huajt, zgjati dy javë. Tjetra ishte një përpjekje për të prezantuar autotestimin numër dy. Filloi me faktin se gjithçka duhet të ndërtohet brenda kompanisë, vetë (vektori i duhur: ndërtoni ekspertizë brenda), brenda kornizës së SCRUM, dhe të krijoni dokumentacion në proces. Rafti për automatizimin duhet të jetë i barabartë me grumbullin e produktit (këtu po e shtoj, mos e testoni projektin tuaj JavaScript me asgjë tjetër). Në fund të sprintit, ata bënë një demonstrim se si funksionon autotesti me të gjithë ekipin (e dobishme). Kështu, u rrit përfshirja e të gjithë anëtarëve të ekipit në procesin e automatizimit, si dhe besimi në autotestet dhe mundësia që ky autotest të përdoret patjetër (dhe nuk do të komentohet brenda një muaji për shkak të dështimeve të vazhdueshme).
Nga rruga, në DevOpsForum 2019 kishte një mikrofon të hapur - një format i njohur prej kohësh dhe, për mendimin tim, i dobishëm fjalimesh. Ju ecni kështu, dëgjoni raporte dhe më pas vendosni që në konferencë ia vlen të diskutoni një temë ose problem të caktuar, të ndani përvojën përkatëse në zgjidhjen e problemit.
Vura re gjithashtu se organizatorët bënë një rrjedhë raportesh të shkurtra. Çdo raport zgjat jo më shumë se 10 minuta, i ndjekur nga pyetje. Në këtë mënyrë ju mund të mbuloni shumë tema në të njëjtën kohë dhe t'u bëni pyetje folësve që ju interesojnë.
Ndërmjet prezantimeve, unë shëtisja nëpër kabinat e partnerëve të konferencës dhe vodha/fitova shumë gjëra. Oh, më pëlqen fletushka!
Tryeza e rrumbullakët dhe çështjet e DevOps me drejtorin e zhvillimit në Alfastrakhovanie
Qershia mbi tortën e DevOpsForum 2019 për mua ishte seanca plenare një orëshe me ekspertët e DevOps. Katër pjesëmarrës të sesionit u ftuan të shikonin DevOps nga këndvështrime të ndryshme: Anton Isanin (Alfastrakhovanie, drejtore e zhvillimit), Nailya Zamashkina (Fintech Lab, drejtoreshë operative), Oleg Egorkin (Rostelecom, trajner Agile) dhe Anton Martyanov (ekspert i pavarur, shikoi DevOps nga pikëpamja e biznesit).
Ekspertët u ulën më afër njerëzve dhe më pas gjërat filluan të ndodhin: për një orë të tërë, pjesëmarrësit nga audienca bënin pyetjet e tyre dhe ekspertët morën repin. Ndonjëherë ka pasur debate të vërteta. Pyetjet ishin shumë të ndryshme, për shembull: a duhen fare inxhinierë DevOps, pse nuk mund të trajnohen si administratorë të sistemit, a duhet t'u ofrohet DevOps të gjithëve, cila është vlera e tij etj.
Më pas kam biseduar personalisht me Anton Isanin. Ne diskutuam nevojën për të 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 është i nevojshëm si nga produkti, ashtu edhe nga biznesi dhe ekipi. Le të shkojmë ta zbatojmë atë. Gjithçka funksionoi. Ne shfrymë. DevOps na ka afruar me klientin, tani ne mund t'i plotësojmë shpejt të gjitha dëshirat e tij. Si rezultat, ne kemi një departament të madh Ops me rregulla dhe kërkesa strikte, dhe ai vazhdimisht gjen defekte në produkt dhe krijon një mori kërkesash. Për më tepër, të gjitha defekteve u caktohet statusi "urgjent", edhe nëse klienti donte papritur ta ngjyroste butonin me ngjyrë të verdhë në vend të gjelbër. Projekti po rritet, numri i lëshimeve po rritet dhe, në përputhje me rrethanat, numri i defekteve dhe keqkuptimeve të funksionalitetit të ri nga klientët. Ops punëson 10 njerëz të tjerë për të vazhduar me raportimin e defekteve dhe zhvillimi punëson 15 të tjerë për të vazhduar me mbylljen e tyre. Dhe në vend që të prezantojë veçori të reja, ekipi punon me SD të pafundme, duke i shpjeguar përdoruesit funksionalitetin dhe mbështetjen në të njëjtën kohë. Si rezultat, si Opsionet ashtu edhe zhvillimi po funksionojnë, por klienti dhe biznesi janë të pakënaqur: veçoritë e reja ngecin. Rezulton se DevOps duket se ekziston, por nuk duket se ekziston.
Lidhur me nevojën për të zbatuar DevOps, Anton deklaroi qartë se kjo varet drejtpërdrejt nga shkalla e biznesit. Nëse shërbimi i një klienti në vit i sjell kompanisë një miliard, DevOps nuk është i nevojshëm (me kusht që të mos keni nevojë të bëni rregullisht ndryshime të reja për këtë klient). Gjithçka është e mbuluar me çokollatë. Por nëse biznesi rritet dhe shfaqen më shumë klientë, atëherë duhet të pajtoheni. Si rregull, fillimisht nuk ka Opsione të lezetshme në kompani. Fillimisht ne e presim produktin dhe vetëm atëherë kuptojmë se në mënyrë që produkti të funksionojë, duhet të mbajmë një sy te serverët dhe të monitorojmë furnizimet. Kjo është kur Ops vjen në ekzistencë. Mbetet të kuptohet se Ops, si një ndarje e veçantë, do të fillojë të vendosë një mori pengesash për zhvillimin dhe të gjitha dërgesat do të fillojnë të ngecin. Kjo do të thotë, në këtë rast, kultura DevOps është tashmë e rëndësishme, por nuk duhet të harrojmë anën e saj të errët.
Burimi: www.habr.com