Nylig var jeg pÄ DevOpsForum 2019 arrangert av Logrocon. PÄ denne konferansen forsÞkte deltakerne Ä finne lÞsninger og nye verktÞy for effektivt samarbeid mellom virksomheten og utviklere samt IT-tjenesteleverandÞrer.
Konferansen var vellykket: det var mange nyttige presentasjoner, interessante foredragsformater og masse kommunikasjon med foredragsholderne. Det var ogsÄ spesielt viktig at ingen prÞvde Ä selge meg noe, noe som ofte skjer pÄ store konferanser.
Sammendrag fra foredragene fra Raiffeisen Bank, AlfaStrakhovanie, erfaringer fra Mango Telecom ved implementering av automatisering og andre detaljer under fanen.
Jeg heter Yana, jeg jobber som tester, driver med automatisering, samt DevOps, og jeg elsker Ä delta pÄ konferanser og meetups. I lÞpet av de siste to Ärene har jeg vÊrt pÄ konferansene til Oleg Bunin (HighLoad++, TeamLead Conf), pÄ arrangementene til Jug (Heisenbug, JPoint), pÄ TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
FÞrst og fremst ser jeg pÄ programmet for konferansen. I mindre grad vurderer jeg hva foredraget handler om, i stÞrre grad - pÄ foredragsholderen. Selv om foredraget viser seg Ä vÊre svÊrt teknologisk og interessant, er det ikke sikkert at du kan anvende noen av de beste praksisene i foredraget i ditt selskap. Og da trenger du en god foredragsholder.
Lysende perspektiv i Raiffeisen Bank
Vanligvis gÄr jeg pÄ jakt etter interessante foredragsholdere i pausene. PÄ DevOpsForum 2019 fanget en foredragsholder fra Raiffeisen Bank - Mikhail Bijan - min interesse. Under sitt foredrag fortalte han hvordan de gradvis introduserer DevOps til sine team, hvorfor de trenger det, og hvordan man kan selge ideen om DevOps-transformasjon til virksomheten. Han snakket ogsÄ om hvordan man kan se lyset i enden av pipelinen.
Mikhail Bijan, direktĂžr for automatisering i Raiffeisen Bank
Akkurat nÄ har de ikke "ekte DevOps" i selskapet. Det vil si at det er ekte, men ikke i alle teamene. Ved implementering av DevOps baserer de seg pÄ beredskapen til teamene bÄde nÄr det gjelder spesifikke ingeniÞrer og nÄr det gjelder produktbehovet og modenheten til plattformen produktet er bygget pÄ. Misha forklarte hvordan man kan forklare forretningsverdenen hvorfor DevOps er nÞdvendig.
Banksektoren har flere vÊkstdrivere: omkostninger ved tjenester og udvidelse af kundebasen. Stigning i omkostningerne ved tjenester er ikke en sÊrlig god driver, mens vÊksten i kundebasen derimod er det. Hvis konkurrenterne lancerer et objektivt innovativt produkt, vil alle kunder flygte dertil, og senere vil markedet stabilisere sig. Derfor er det at lancere nye produkter og hastigheden af lanceringsprocessen den vÊsentligste ting, som bankerne fokuserer pÄ. Netop derfor er DevOps nÞdvendigt, og erhvervslivet forstÄr det.
NĂŠste vigtige bemĂŠrkning: DevOps reducerer ikke altid time to market. DevOps kan ikke arbejde alene; det er kun en del af processen med at skabe og lancere et produkt fra udvikling til produktion (fra kode til kunde). Alt, hvad der foregĂ„r 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 de forskellige funktioner â ofte netop det er mangelfuldt for, at DevOps kan fungere, og virksomheden kan nĂ„ sine mĂ„l. Derfor blev det fĂžrst og fremmest i Raiffeisenbank aftalt med erhvervslivet, at det er nĂždvendigt at lĂŠre at bruge DevOps. Automatisering for automatiseringens skyld hjĂŠlper ikke meget i kampen om nye kunder.
Alt i alt mener Misha, at DevOps skal implementeres, men med omtanke. Man skal vÊre forberedt pÄ, at holdets produktivitet vil falde i starten af transformationen, de vil tjene fÊrre penge, men senere vil det betale sig.
Automatisering af testning i "Mango Telekom"
En interessant presentasjon ble gjort av EĐłĐŸŃ ĐĐ°ŃĐ»ĐŸĐČ fra «ĐĐ°ĐœĐłĐŸ йДлДĐșĐŸĐŒÂ». Presentasjonen het «Automatisering av hele testsyklusen i SCRUM-teamet». EĐłĐŸŃ mener at DevOps er skapt spesielt for SCRUM, men samtidig er det ganske vanskelig Ă„ implementere DevOps i et SCRUM-team. Dette skyldes at SCRUM-teamet hele tiden er under press og ikke har tid til Ă„ avbryte for innovasjoner og omstrukturering av prosessen. Problemet ligger ogsĂ„ i at SCRUM ikke forutsetter opprettelse av sub-team i laget (testteam, utviklerteam osv.). I tillegg, for Ă„ automatisere en eksisterende prosess, er dokumentasjon nĂždvendig, men i SCRUM er det ofte helt fravĂŠrende â «produktet er viktigere enn noe skriving».
Etter overgangen til SCRUM begynte testere Ă„ rĂ„dfĂžre seg med utviklerne om hvordan de skulle teste funksjoner. Gradvis Ăžkte funksjonaliteten, dokumentasjonen manglet, og de begynte Ă„ oppdage mange feil i funksjonaliteten som ikke var dekket av tester, og det var generelt uklart hvem som hadde testet det og nĂ„r. I korte trekk â kaos. De bestemte seg for Ă„ gĂ„ over til automatisering av testing. Men selv da skjedde det et totalfiasko. De tilkalte eksterne spesialister for automatisering, som brukte en teknologi som var ukjent for de interne testerne. Rammeverket for automatiserte tester fungerte selvfĂžlgelig, men etter at de eksterne forlot, overlevde det i to uker. Det kom deretter et forsĂžk pĂ„ en ny runde med innfĂžring av automatiserte tester. Den startet med at alt mĂ„tte bygges internt i selskapet, med egne ressurser (riktig retning: bygg kompetanse internt), innenfor SCRUM, og i lĂžpet av prosessen skape dokumentasjon. Teknologistacken for automatisering mĂ„tte vĂŠre lik produktets tech-stack (her er jeg helt enig, vĂŠr sĂ„ snill, ikke test prosjektet pĂ„ JavaScript med noe annet). PĂ„ slutten av sprinten holdt de en demo av hvordan den automatiserte testen fungerte, med hele laget til stede (nyttig). PĂ„ denne mĂ„ten Ăžkte involveringen av alle teammedlemmer i prosessen med automatisering, samt tilliten til de automatiserte testene, noe som Ăžkte sjansen for at den automatiserte testen faktisk ville bli brukt (og ikke kommentert ut etter en mĂ„ned pĂ„ grunn av konstante feil).
PĂ„ DevOpsForum 2019 var det en Ă„pen mikrofon â en langvarig og, etter min mening, nyttig form for presentasjoner. Du gĂ„r rundt, hĂžrer pĂ„ innlegg, og sĂ„ bestemmer du deg for at det innen konferansen er verdt Ă„ diskutere et bestemt tema eller problem, og dele relevant erfaring med Ă„ lĂžse oppgaven.
Jeg la ogsÄ merke til at arrangÞrene hadde laget en strÞmm av korte innlegg. Hver innlegg varer ikke lenger enn 10 minutter, etterfulgt av spÞrsmÄl. PÄ denne mÄten kan man dekke mange temaer samtidig og stille spÞrsmÄl til talerne som vekker interesse.
Mellom innleggene ruslet jeg rundt pĂ„ partnerstandene og fikk tak i mange forskjellige smĂ„ting. Ă
h, jeg elsker gratisutdeling!
Rundebord og DevOps spÞrsmÄl med utviklingsdirektÞren i AlfaStrakhovanie
Den store hÞydepunktet for meg pÄ DevOpsForum 2019 var den timelange plenumssesjonen med DevOps-eksperter. Fire deltakere ble invitert til Ä se pÄ DevOps fra forskjellige perspektiver: Anton Isanin (AlfaStrakhovanie, utviklingsdirektÞr), Nailya Zamashkina (Fintech Lab, driftsdirektÞr), Oleg Egorkin (Rostelekom, Agile-coach) og Anton Martyanov (uavhengig ekspert, sÄ pÄ DevOps fra forretningsperspektiv).
Ekspertene satte seg nÊrmere publikum, og sÄ fikk vi se hvordan det gikk: i en hel time stilte deltakere fra salen spÞrsmÄl, og ekspertene svarte. Noen ganger fÞrte det til ekte debatter. SpÞrsmÄlene var varierte, for eksempel: trengs det i det hele tatt DevOps-ingeniÞrer, hvorfor kan de ikke vokse ut av systemadministratorer, bÞr alle tilbys DevOps, hva er verdien av det, og sÄ videre.
Deretter snakket jeg personlig med Anton Isanin. Vi diskuterte nĂždvendigheten av Ă„ fremme DevOps-kultur i hvert hjem og avdekket den mĂžrke siden av DevOps-transformasjonen.
La oss si at alle samles og bestemmer at DevOps er nÞdvendig bÄde for produktet, for virksomheten og for teamet. De begynner implementeringen. Alt fungerer. De puster ut. DevOps har gjort oss nÊrmere kunden, nÄ kan vi raskt oppfylle alle deres Þnsker. Til slutt har vi en stor Ops-avdeling med strenge regler og krav, og de leverer hele tiden feil til produktet, og oppretter en mengde henvendelser. Og alle feil har «haster»-status, selv om kunden plutselig Þnsker Ä male en knapp gul i stedet for grÞnn. Prosjektet vokser, antallet utgivelser Þker, og dermed Þker ogsÄ antallet feil og kunders forvirring om den nye funksjonaliteten. Ops ansetter 10 personer til for Ä rapportere feil, mens utviklingen ansetter 15 for Ä lukke dem. Og i stedet for Ä implementere nye funksjoner, jobber teamet med endelÞse SD-er, og forklarer funksjonaliteten til brukeren og supporten samtidig. Til slutt er bÄde Ops og utvikling opptatt, men kunden og virksomheten er misfornÞyde: nye funksjoner sitter fast. SÄ, DevOps ser ut til Ä vÊre der, men er det egentlig ikke.
NĂ„r det gjelder nĂždvendigheten av Ă„ implementere DevOps, uttalte Anton klart at dette avhenger direkte av omfanget av virksomheten. Hvis kundeservicen for Ă©n kunde per Ă„r gir selskapet milliarder â trenger de ikke DevOps (forutsatt at det ikke er nĂždvendig Ă„ rulle ut nye endringer til denne kunden regelmessig). Alt gĂ„r greit. Men hvis virksomheten vokser og det kommer flere kunder, mĂ„ man tilpasse seg. Vanligvis finnes det ikke en skikkelig Ops i selskapet fra starten av. FĂžrst utvikler vi produktet, og sĂ„ forstĂ„r vi at for at produktet skal fungere, mĂ„ vi holde Ăžye med servere, fĂžlge med pĂ„ leveranser. Da oppstĂ„r Ops. Det gjenstĂ„r Ă„ forstĂ„ at Ops, som en egen avdeling, vil begynne Ă„ sette opp en rekke barrierer for utviklingen, og alle leveranser vil begynne Ă„ skli. I dette tilfellet er DevOps-kulturen allerede relevant, men man mĂ„ ikke glemme dens mĂžrke side.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish