Nedávno jsem se zúčastnila DevOpsForum 2019, kterou pořádal Logrocon. Na této konferenci se účastníci snažili najít řešení a nové nástroje pro efektivní spolupráci mezi podniky a specialisty na vývoj a informační technologie.
Konference byla úspěšná: bylo tam opravdu hodně užitečných prezentací, zajímavé formáty vystoupení a spousta komunikace s přednášejícími. A co je zejména důležité, nikdo se mi nesnažil nic prodat, což je poslední dobou častý jev u přednášejících na velkých konferencích.
Shrnutí z vystoupení Raiffeisen Bank, Alfa Insurance, zkušenosti Mango Telecom při zavádění automatizace a další podrobnosti najdete pod odkazem.
Jmenuji se Jana, pracuji jako tester, zabývám se automatizací a také DevOps a miluji účast na konferencích a meetupech. Za poslední dva roky jsem navštívila konference Olega Bunina (HighLoad++, TeamLead Conf), akce Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Nejdříve se soustředím na program konference. Méně mě zajímá, o čem bude přednáška, více mě zajímá přednášející. I když může být prezentace velmi technologická a zajímavá, není zaručeno, že budete moci aplikovat některé osvědčené postupy z přednášky ve své firmě. A tehdy potřebujete dobrého přednášejícího.
Světlo na konci pipeline v Raiffeisen Bank.
Obvykle pátrám po zajímavých přednášejících v zákulisí. Na DevOpsForum 2019 mě zaujal přednášející z Raiffeisen Bank — Michail Bižan. Během vystoupení hovořil o tom, jak postupně zavádějí svým týmům DevOps, proč je to potřebné a jak prodat myšlenku DevOps transformace byznysu. Taktéž hovořil o tom, jak vidět světlo na konci pipeline.
Michail Bižan, ředitel automatizace v Raiffeisen Bank.
V současné době ve společnosti nemají „skutečný DevOps“. To znamená, že je skutečný, ale ne ve všech týmech. Při zavádění DevOps se opírají o připravenost týmů jak z hlediska konkrétních inženýrů, tak z hlediska potřeb produktu a zralosti platformy, na které je tento produkt postaven. Míša vysvětlil, jak obhájit byznysu, proč je DevOps potřebný.
Bankovní sektor má několik motorů růstu: cena služeb a rozšíření klientské základny. Zvyšování cen služeb není příliš silným faktorem, ale růst klientské základny je naopak pozitivní. Pokud konkurenti uvedou na trh skutečně atraktivní produkt, všichni klienti odejdou tam, a až časem se trh vyrovná. Proto je zavádění nových produktů a rychlost jejich uvedení na trh klíčová záležitost, na kterou se banky zaměřují. Právě pro to je potřebný DevOps, a podniky to chápou.
Další důležitý bod: DevOps ne vždy zkracuje čas na uvedení na trh. DevOps nemůže fungovat sám, je to jen část procesu vývoje a uvádění produktu na trh od vývoje po produkci (od kódu ke klientovi). Všechno, co je před kódem, nemá s DevOps přímou souvislost. To znamená, že marketingoví specialisté mohou roky zkoumat trh a celý život dohánět konkurenty. Je nutné rychle pochopit, co klient potřebuje, a plánovat realizaci určité funkce — často právě to chybí, aby DevOps fungoval a společnost dosáhla cíle. Proto se v Raiffeisenbank nejprve dohodli s podnikem, že se musí naučit využívat DevOps. Automatizace pro automatizaci příliš nepomůže v boji o nové klienty.
Celkově Míša považuje, že DevOps je třeba zavádět, ale s rozmyslem. A je třeba být připraven na to, že na začátku transformace klesne produktivita týmu, budou vydělávat méně peněz, ale nakonec se to vyplatí.
Automatizace testování v „Mango Telecom“
Další zajímavou prezentaci pro mě jako testera přednesl Eгор Маслов z "Mango Telecom". Prezentace se nazývala „Automatizace plného cyklu testování v SCRUM týmu“. Eгор věří, že DevOps je stvořen právě pro SCRUM, ale implementovat DevOps do SCRUM týmu je docela problematické. Důvodem je to, že SCRUM tým neustále někam spěchá, nemá čas se soustředit na novinky a přestavět proces. Dalším problémem je, že SCRUM nepředpokládá rozdělení v týmu na sub-týmy (tým testerů, tým vývojářů atd.). A kromě toho, k automatizaci stávajícího procesu je potřeba dokumentace, ale v SCRUMu většinou dokumentace zcela chybí – "produkt je důležitější než nějaké psaní."
Po přechodu na SCRUM začali testeři radit s vývojáři, jak testovat nové funkce. Postupně se objem funkcionality zvyšoval, dokumentace chyběla a začali nacházet mnoho chyb v funkcionalitě, která neměla pokrytí testy a již nebylo jasné, kdo a kdy ji testoval. Jinými slovy – rozvrat a chaos. Rozhodli se přejít na automatizaci testování. Ale ani poté to skončilo naprostým neúspěchem. Přivedli externí specialisty na automatizaci, kteří psali v pro ně neznámém technologickém stacku. Rámec pro automatizované testy samozřejmě fungoval, ale poté, co externisté odešli, vydržel jen 14 dní. Následovalo další pokus o zavedení automatizovaného testování číslo dvě. Začalo to tím, že všechno musí být vybudováno uvnitř společnosti, vlastními silami (správný směr: zvyšujte odborné znalosti uvnitř), v rámci SCRUMu, a během procesu vytvářet dokumentaci. Stack pro automatizaci by měl odpovídat stacku produktu (zde souhlasím, netestujte projekt na JavaScript něčím jiným). Na konci sprintu pořádali demo toho, jak funguje automatizovaný test, za účasti celého týmu (užitečné). Tímto způsobem se zvyšovala angažovanost všech členů týmu v procesu automatizace, stejně jako důvěra v automatizované testy a šance, že tento automatizovaný test bude skutečně používán (a nebude za měsíc zakomentován z důvodu neustálých neúspěchů).
Na DevOpsForum 2019 byl otevřený mikrofon – dlouho známý a, podle mého názoru, užitečný formát přednášek. Chodíte, posloucháte prezentace a pak se rozhodnete, že na konferenci je potřeba prodiskutovat nějaké téma nebo problém, sdílet relevantní zkušenosti s řešením úkolu.
Také jsem si všimla, že organizátoři vytvořili sekci krátkých prezentací. Každá prezentace trvá maximálně 10 minut, poté následovaly otázky. Takto je možné pokrýt mnoho témat a položit otázky řečníkům, kteří vás zaujali.
Mezi přednáškami jsem se prošla po stáncích partnerů konference a získala mnoho různých věcí. Ach, miluji propagační materiály!
Kulatý stůl a otázky DevOps s ředitelem vývoje v AlfaStrakhovanie.
Třešinkou na dortu DevOpsForum 2019 pro mě byla hodinová plenární sezení s odborníky na DevOps. Byli pozváni čtyři účastníci sezení, kteří měli pohlížet na DevOps z různých úhlů: Anton Isanin (AlfaStrakhovanie, ředitel vývoje), Nailya Zamashkina (Fintech Lab, provozní ředitel), Oleg Egorkin (Rostelecom, Agile kouč) a Anton Martyanov (nezávislý expert, posuzoval DevOps z pohledu podnikání).
Odborníci se usadili blíže k lidem a začalo se: celý hodinový blok účastníci z publika kladli své otázky, a odborníci se snažili odpovídat. Někdy vznikly skutečné debaty. Otázky byly velmi rozmanité, například: jsou DevOps inženýři vůbec potřební, proč je nelze vychovat z administrátorů systémů, měla by se DevOps nabízet všem, jaká je její hodnota a tak dále.
Poté jsem se osobně setkala s Antonem Isaninem. Diskutovali jsme o potřebě šířit kulturu DevOps do každého domu a odhalili temnou stránku transformace DevOps.
Představme si, že se všichni sešli a rozhodli, že DevOps je potřeba jak pro produkt, tak pro byznys a tým. Pustili se do implementace. Vše se podařilo. Vydechli jsme. DevOps nás přiblížil k zákazníkovi, nyní můžeme rychle plnit všechny jeho přání. Nakonec máme velké oddělení Ops se striktními pravidly a požadavky, a neustále hlásí chyby do produktu, vytvářející spoustu žádostí. Přitom všechny chyby mají status „okamžitě“, i když si klient nečekaně přál, aby se tlačítko obarvilo na žlutou místo zelené. Projekt roste, roste počet vydání a tím i počet chyb a nedorozumění s novou funkčností ze strany zákazníků. Ops najímá dalších 10 lidí, aby stíhali hlásit chyby, zatímco vývojáři najímají dalších 15, aby je stihli opravovat. A místo toho, aby implementovali nové funkce, tým pracuje na nekonečných SD a vysvětluje funkčnost uživatelům i podpoře. Nakonec jsou jak Ops, tak vývojáři zaměstnaní, ale zákazník a byznys jsou nespokojeni: nové funkce uvízly. Takže DevOps sice existuje, ale jako by nebyl.
O nutnosti implementace DevOps Anton jednoznačně prohlásil, že to přímo závisí na rozsahu byznysu. Pokud správa jednoho klienta za rok přináší firmě miliardu — DevOps není potřeba (pokud není třeba pravidelně zavádět nové změny pro tohoto klienta). Všechno je v pořádku. Ale pokud byznys roste a počet klientů se zvyšuje, je nutné se tomuto přizpůsobit. Obvykle v firmě ze začátku skvělý Ops není. Nejdříve vyvíjíme produkt a až poté si uvědomíme, že aby produkt fungoval, je třeba sledovat dodávky. servery, sledovat dodávky. Tehdy se také zrodí Ops. Zůstává pochopit, že Ops jako samostatné oddělení začne zavádět spoustu překážek pro vývoj a všechny dodávky začnou váznout. To znamená, že v tomto případě je kultura DevOps již aktuální, jen je třeba nezapomínat na její temnou stránku.
Zdroj: habr.com
