For nylig deltog jeg i DevOpsForum 2019, som blev arrangeret af Logrocon. På denne konference forsøgte deltagerne at finde løsninger og nye værktøjer til effektivt samspil mellem erhvervslivet og specialister inden for udvikling og IT-service.
Konferencen var en succes: der var virkelig mange nyttige indlæg, interessante præsentationsformer og masser af kommunikation med talerne. Og især vigtigt var det, at ingen prøvede at sælge mig noget, som de fleste talere gør på store konferencer for tiden.
Udsnit fra præsentationer fra Raiffeisen Bank, AlfaStrakhovanie, erfaringer fra Mango Telecom ved implementering af automatisering og andre detaljer nedenfor.
Mit navn er Jana, jeg arbejder som tester, beskæftiger mig med automatisering og DevOps, og jeg elsker at deltage i konferencer og meetups. I løbet af de sidste to år har jeg været på konferencer af Oleg Bunin (HighLoad++, TeamLead Conf), hos Jug (Heisenbug, JPoint), på TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Først og fremmest lægger jeg mærke til konferencens program. I mindre grad ser jeg på, hvad præsentationen vil handle om, men i højere grad på taleren. Selv hvis præsentationen viser sig at være meget teknologisk og interessant, er der ikke nogen garanti for, at du kan anvende nogle af best practices fra indlægget i din virksomhed. Og så har du brug for taleren.
Lys i slutningen af pipeline i Raiffeisen Bank
Normalt går jeg på jagt efter interessante talere i krogene. På DevOpsForum 2019 lå en taler fra Raiffeisen Bank, Mikhail Bijan, inden for mit interesseområde. Under sin præsentation forklarede han, hvordan de gradvist introducerer deres teams til DevOps, hvorfor de har brug for det, og hvordan man sælger ideen om DevOps-transformation til virksomheden. Generelt talte han om, hvordan man kan se lyset i slutningen af pipeline.
Mikhail Bijan, direktør for automatisering i Raiffeisen Bank
I øjeblikket har de ikke "ægte DevOps" i deres virksomhed. Altså er det ægte, men ikke i alle teams. Ved implementering af DevOps baserer de sig på teamernes parathed, både med hensyn til konkrete ingeniører og behovet for produktet og modningen af den platform, som produktet er bygget på. Misha forklarede, hvordan man kan overbevise virksomheden om, hvorfor DevOps er nødvendigt.
Banksektoren har flere vækstdrivere: omkostningerne ved tjenester og udvidelse af kundegrundlaget. En stigning i tjenesteomkostningerne er ikke en optimal driver, mens væksten i kundegrundlaget derimod er. Hvis konkurrenter lancerer et objektivt fremragende produkt, vil alle kunder flytte derhen, og over tid vil markedet stabilisere sig. Derfor er introduktionen af nye produkter og hastigheden af denne proces det vigtigste fokus for bankerne. Det er netop derfor, DevOps er nødvendigt, og det forstår virksomheden.
Det næste vigtige punkt: DevOps reducerer ikke altid time to market. DevOps kan ikke fungere alene; det er kun en del af processen med at skabe og bringe et produkt til markedet fra udvikling til produktion (fra kode til kunde). Alt, hvad der ligger før koden, har ikke direkte relation til DevOps. Det vil sige, at marketingfolk kan bruge år på at studere markedet og hele livet indhente konkurrenterne. Det er nødvendigt hurtigt at forstå, hvad kunden har brug for, og planlægge implementeringen af en eller anden funktion — ofte er det lige præcis det, der mangler for at DevOps kan fungere, og virksomheden kan nå sine mål. Derfor er det i første omgang blevet aftalt med forretningen i Raiffeisen Bank, at de skal lære at anvende DevOps. Automatisering for automatiseringens skyld vil næppe hjælpe i kampen om nye kunder.
Generelt mener Misha, at DevOps skal implementeres, men det skal gøres med omtanke. Man skal være forberedt på, at holdets produktivitet vil falde i starten af transformationen, og de vil tjene færre penge, men det vil betale sig på sigt.
Automatisering af test i "Mango Telecom"
En anden interessant præsentation for mig som tester blev lavet af Egor Maslov fra "Mango Telecom". Præsentationen hed "Automatisering af hele testcyklussen i SCRUM-teamet". Egor mener, at DevOps er skabt netop til SCRUM, men samtidig er det ret problematisk at implementere DevOps i et SCRUM-team. Det skyldes, at SCRUM-teamet hele tiden har travlt og ikke har tid til at afbryde for nye initiativer og revidere processerne. Problemet er også, at SCRUM ikke forudsætter, at der dannes sub-teams i gruppen (f.eks. testere, udviklere osv.). Derudover kræver automatiseringen af eksisterende processer dokumentation, og i SCRUM er dokumentationen ofte helt fraværende - "produktet er vigtigere end noget skriftligt".
Efter overgangen til SCRUM begyndte testerne at konsultere udviklerne om, hvordan man tester funktioner. Gradvis blev omfanget af funktionaliteten større, dokumentationen manglede, og de begyndte at opdage mange fejl i funktionaliteten, som ikke havde testdækning, og det var generelt uklart, hvem og hvornår det var blevet testet. Kort sagt - kaos. De besluttede at gå videre med automatiseringen af testerne. Men selv da blev der en total fiasko. De tiltrak eksterne specialister til automatiseringen, som arbejdede med en stack, der var ukendt for de interne testere. Rammeværket til automatiserede tests virkede selvfølgelig, men efter at de eksterne specialister forlod, overlevede det kun i to uger. Derefter var der et forsøg på at implementere automatisering nummer to. Det begyndte med, at alt skulle bygges internt i virksomheden af egne kræfter (den rigtige vej: opbygge ekspertise internt), inden for rammerne af SCRUM, og at der undervejs skulle oprettes dokumentation. Stakken til automatisering skal være den samme som produktets stack (her er jeg helt enig, test ikke et projekt på JavaScript med noget andet). I slutningen af sprinten holdt de en demo af, hvordan den automatiserede test fungerede, med hele teamets deltagelse (nyttigt). På den måde blev alles engagement i automatiseringsprocessen øget, ligesom tilliden til de automatiserede tests og chancen for, at denne test faktisk vil blive brugt (og ikke blive kommenteret ud efter en måned på grund af konstant fiasko).
For øvrigt arbejdede den åbne mikrofon på DevOpsForum 2019 — et velkendt format for præsentationer, som jeg mener er nyttigt. Du går rundt, lytter til oplæg, og beslutter så, at det er værd at diskutere et bestemt emne eller problem, og dele relevant erfaring med at løse opgaven.
Jeg bemærkede også, at arrangørerne indførte en række korte oplæg. Hvert oplæg varer ikke mere end 10 minutter, hvorefter der er spørgsmål. På den måde kan man dække mange emner og stille spørgsmål til de talere, der har interesseret en.
Imellem oplæggene gik jeg rundt ved partnerstandene og fik fat i/vandt mange forskellige ting. Åh, hvor jeg elsker giveaways!
Rundbord og spørgsmål om DevOps med udviklingsdirektøren fra AlfaStrakhovanie
Kirsebærret på toppen af DevOpsForum 2019 for mig var den timelange plenumsession med DevOps-eksperter. Fire deltagere blev inviteret til sessionen, som skulle se på DevOps fra forskellige perspektiver: Anton Isanin (AlfaStrakhovanie, udviklingsdirektør), Nailya Zamashkina (Fintech Lab, driftsdirektør), Oleg Egorkin (Rostelecom, Agile coach) og Anton Martyanov (uafhængig ekspert, der så på DevOps fra et forretningsperspektiv).
Eksperterne satte sig tættere på folk, og så gik det løs: i en hel time stillede deltagerne fra salen deres spørgsmål, mens eksperterne hang på. Nogle gange udviklede det sig til virkelige debatter. Spørgsmålene var meget forskellige, for eksempel: er DevOps-ingeniører overhovedet nødvendige, hvorfor kan man ikke opdrage dem fra systemadministratorer, skal man tilbyde alle DevOps, hvad er dens værdi osv.
Derefter talte jeg personligt med Anton Isanin. Vi diskuterede nødvendigheden af at bringe DevOps-kulturen ind i hvert hus og afdækkede den mørke side af DevOps-transformation.
Lad os forestille os, at alle er samlet og blevet enige om, at DevOps er nødvendigt for både produktet, forretningen og teamet. Implementeringen gik i gang. Det lykkedes. Vi åndede lettet op. DevOps har bragt os nærmere kunden, så vi hurtigere kan opfylde alle deres ønsker. Resultatet er en stor Ops-afdeling med strenge regler og krav, og den producerer konstant defekter til produktet og opretter en masse anmodninger. Alle fejl bliver sendt med status "haster", selvom kunden pludselig ønsker at ændre farven på en knap fra grøn til gul. Når projektet vokser, vokser antallet af udgivelser og dermed antallet af defekter og misforståelser omkring nye funktioner hos kunderne. Ops ansætter yderligere 10 personer for at kunne rapportere defekter, mens udviklingsteamet ansætter yderligere 15 for at kunne lukke dem. Og i stedet for at implementere nye funktioner, bruger teamet tid på endeløse SD'er, hvor de forklarer funktionaliteten til brugerne og til supporten samtidig. Resultatet er, at både Ops og udvikling har travlt, men kunden og forretningen er utilfredse: nye funktioner bliver forsinket. Det ser ud til, at DevOps er til stede, men samtidig ikke.
Angående nødvendigheden af at implementere DevOps, sagde Anton klart, at det afhænger direkte af virksomhedens størrelse. Hvis det at betjene én kunde om året genererer en milliard for virksomheden — så er DevOps ikke nødvendigt (forudsat at man ikke regelmæssigt skal rulle nye ændringer ud til denne kunde). Alt virker, som det skal. Men hvis forretningen vokser, og der kommer flere kunder, så skal man begynde at leve op til det. Som regel er der ikke en stærk Ops-afdeling i virksomheden fra starten. Først udvikler vi produktet, og så indser vi, at for at produktet skal fungere, skal vi også holde øje med servere, følge med leverancerne. Så opstår Ops. Det er vigtigt at forstå, at Ops, som en separat enhed, begynder at stille mange barrierer for udviklingen, og alle leverancer begynder at halte. Så i dette tilfælde er DevOps-kulturen allerede relevant, men man skal huske dens mørke sider.
Kilde: habr.com
