Recent am participat la DevOpsForum 2019, organizat de Logrocon. La această conferință, participanții au încercat să găsească soluții și instrumente noi pentru o interacțiune eficientă între afaceri și specialiști în dezvoltare și servicii IT.
Conferința a fost un succes: au fost prezentări cu adevărat utile, formate interesante de discursuri și o mulțime de oportunități de a interacționa cu speakerii. Și, cel mai important, nimeni nu a încercat să-mi vândă nimic, ceea ce a devenit o practică frecventă la conferințele mari.
Un rezumat al prezentărilor de la Raiffeisen Bank, Alfa Insurance, experiența Mango Telecom în implementarea automatizării și alte detalii în continuare.
Mă numesc Yana, lucrez ca testeri, mă ocup cu automatizarea, precum și cu DevOps și ador să particip la conferințe și meetup-uri. În ultimii doi ani am fost la conferințele lui Oleg Bunin (HighLoad++, TeamLead Conf), la evenimentele Jug (Heisenbug, JPoint), la TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Primul lucru la care mă uit este programul conferinței. Mai puțin mă interesează despre ce va fi prezentarea, dar mai mult mă concentrez pe speaker. Chiar dacă prezentarea se dovedește a fi foarte tehnică și interesantă, nu este întotdeauna garantat că vei putea aplica unele best practices discutate în compania ta. Și atunci ai nevoie de speaker.
Lumina de la capătul pipeline-ului în Raiffeisen Bank
De obicei, îmi organizez o vânătoare de speakeri interesanți în culise. La DevOpsForum 2019, atenția mea a fost atrasă de un prezentator de la Raiffeisen Bank — Mihail Bijan. În timpul prezentării, el a explicat cum își sprijină treptat echipele în adoptarea DevOps, de ce este necesar și cum să vinzi afacerii ideea transformării DevOps. Și în general, a vorbit despre cum să vezi lumina de la capătul pipeline-ului.
Mihail Bijan, director de automatizare la Raiffeisen Bank
Acum, în compania lor nu există un „adevărat DevOps”. Adică este real, dar nu în toate echipele. În procesul de implementare a DevOps, ei se bazează pe pregătirea echipelor atât din perspectiva inginerilor specifici, cât și din perspectiva nevoilor produsului și maturității platformei pe care este construit acest produs. Misha a explicat cum să explice afacerii de ce este necesar DevOps.
Sectorul bancar are mai mulți factori de creștere: costul serviciilor și extinderea bazei de clienți. Creșterea costului serviciilor nu este un factor prea bun, în timp ce creșterea bazei de clienți, dimpotrivă, este foarte importantă. Dacă competitorii lansează un produs cu adevărat atractiv, toți clienții se vor orienta către acel produs, dar, în timp, piața se va stabiliza. Prin urmare, lansarea de noi produse pe piață și viteza de livrare a acestora sunt principalele priorități pentru bănci. De aceea, DevOps este esențial, iar afacerea înțelege acest lucru.
O altă observație importantă: DevOps nu reduce întotdeauna timpul de lansare pe piață. DevOps nu poate funcționa singur, este doar o parte a procesului de dezvoltare și lansare a produsului pe piață, de la dezvoltare până la producție (de la cod la client). Însă toate aspectele care preced codul nu au legătură directă cu DevOps. Cu alte cuvinte, marketerii pot studia piața ani de zile și totuși pot rămâne în urma competitorilor. Este esențial să înțelegem rapid ce își dorește clientul și să planificăm implementarea diferitelor funcționalități — de multe ori tocmai acest aspect lipsește pentru ca DevOps să funcționeze și compania să atingă obiectivele. Prin urmare, în primul rând, la Raiffeisen Bank s-a convenit cu afacerea că trebuie să învețe să utilizeze DevOps. Automatizarea doar de dragul automatizării nu va ajuta prea mult în atragerea de noi clienți.
În general, Misha consideră că DevOps trebuie implementat, dar cu discernământ. Trebuie să fim pregătiți pentru faptul că, la începutul transformării, echipa va avea o scădere a productivității, va câștiga mai puțini bani, dar ulterior această abordare își va dovedi valoarea.
Automatizarea testării la 'Mango Telecom'
O altă prezentare interesantă pentru mine ca tester a fost susținută de Egor Maslov de la „Mango Telecom”. Prezentarea s-a intitulat „Automatizarea ciclului complet de testare în echipa SCRUM”. Egor consideră că DevOps a fost creat special pentru SCRUM, dar totodată implementarea DevOps în echipa SCRUM este destul de problematice. Acest lucru se întâmplă deoarece echipa SCRUM este mereu în mișcare, neavând timp să se preocupe de inovații și să își reproiecteze procesul. Problema constă, de asemenea, în faptul că SCRUM nu preconizează formarea de sub-echipe (echipa testerilor, echipa dezvoltatorilor etc.). Și, pe deasupra, pentru automatizarea procesului existent este necesară documentația, iar în SCRUM de multe ori documentația este complet absentă — „produsul este mai important decât orice documentație”.
După trecerea la SCRUM, testerii au început să se consulte cu dezvoltatorii despre cum să testeze funcționalitățile. În timp, volumul funcționalităților a crescut, documentația era inexistentă și au început să detecteze multe bug-uri în acea funcționalitate care nu avea acoperire de teste și nu era clar cine și când a testat-o. Pe scurt — haos. S-au decis să treacă la automatizarea testării. Dar chiar și atunci a avut loc un eșec total. Au angajat specialiști outsource pentru automatizare, care foloseau un stack necunoscut testerilor permanenți. Framework-ul pentru teste automate funcționa, dar după plecarea outsourcing-ului, a rezistat doar două săptămâni. A urmat o încercare de a introduce a doua rundă de testare automată. Aceasta a început prin stabilirea că totul trebuie să fie construit în interiorul companiei, cu forțe proprii (direcția corectă: să dezvolți expertiza intern), în cadrul SCRUM, și pe parcurs să se creeze documentația. Stack-ul pentru automatizare trebuie să fie același cu cel al produsului (aici cu adevărat sunt de acord, nu testați un proiect pe JavaScript cu altceva). La sfârșitul sprintului, organizau o demonstrație a modului în care funcționează testele automate, cu participarea întregii echipe (util). Astfel, se creștea implicarea în procesul de automatizare a tuturor membrilor echipei, precum și încrederea în testele automate și șansa ca acest test automat să fie folosit (și nu comentat după o lună din cauza eșecurilor constante).
De fapt, la DevOpsForum 2019 a existat un microfon deschis - un format cunoscut de mult timp și, din punctul meu de vedere, util pentru prezentări. Te plimbi, asculți prezentările, iar apoi decizi că în cadrul conferinței merită să discuți o anumită temă sau problemă, să împărtășești experiența relevantă de soluționare a unei sarcini.
De asemenea, am observat că organizatorii au creat un flux de prezentări scurte. Fiecare prezentare durează maximum 10 minute, apoi urmează întrebările. Astfel, se pot aborda multe subiecte și se pot pune întrebări vorbitorilor care te-au interesat.
Între prezentări, m-am plimbat printre standurile partenerilor conferinței și am câștigat/enat multe lucruri interesante. Oh, îmi plac materialele promoționale!
Masă rotundă și întrebări DevOps cu directorul de dezvoltare la Alfastrahovanie.
Cireașa de pe tortul DevOpsForum 2019 pentru mine a fost sesiunea plenară de o oră cu experți DevOps. Au fost invitați patru participanți la sesiune, care trebuiau să privească DevOps din perspective diferite: Anton Isanin (Alfastrahovanie, director de dezvoltare), Nailya Zamashkina (Fintech Lab, director operațional), Oleg Egorkin (Rostelecom, Agile coach) și Anton Martyanov (expert independent, care a privit DevOps din perspectiva afacerii).
Experții s-au așezat mai aproape de public și a început, un întreg ceas de întrebări din sală, iar experții au făcut față provocărilor. Uneori au avut loc adevărate dezbateri. Întrebările au fost dintre cele mai diverse, de exemplu: sunt necesari inginerii DevOps, de ce nu-i putem crește din administratori de sistem, trebuie să oferim DevOps tuturor, care este valoarea sa și așa mai departe.
Apoi, am discutat personal cu Anton Isanin. Am discutat despre necesitatea de a aduce cultura DevOps în fiecare casă și am dezvăluit latura întunecată a transformării DevOps.
Să ne imaginăm că toată lumea s-a adunat și a decis că DevOps este necesar atât pentru produs, cât și pentru afacere și echipă. S-a dat start implementării. Totul a mers bine. Am respirat ușurați. DevOps ne-a adus mai aproape de client, acum putem îndeplini rapid toate cerințele sale. În final, avem o mare divizie Ops cu reglementări și cerințe stricte, care continuă să introducă defecte în produs, generând o mulțime de cereri. Și toate defectele sunt marcate ca „urgente”, chiar dacă clientului i-a venit brusc ideea să schimbe culoarea butonului din verde în galben. Proiectul crește, crește numărul de lansări și, în consecință, și numărul de defecte și neînțelegeri legate de noua funcționalitate a clienților. Ops angajează încă 10 oameni pentru a putea raporta defectele, iar dezvoltarea angajează încă 15 pentru a le putea închide. Și în loc să implementeze noi funcții, echipa lucrează cu SD-uri infinite, explicând funcționalitatea utilizatorului și, de asemenea, suportului. În final, atât Ops, cât și dezvoltarea sunt ocupate, dar clientul și afacerea sunt nemulțumiți: noile funcții rămân blocate. Așadar, DevOps pare că există, dar, în același timp, nu există.
Privind necesitatea implementării DevOps, Anton a afirmat clar că aceasta depinde direct de dimensiunea afacerii. Dacă serviciul unui singur client pe an aduce companiei un miliard — DevOps nu este necesar (cu condiția să nu fie necesară livrarea de noi modificări acestui client în mod regulat). Totul este în regulă. Dar dacă afacerea crește și apar mai mulți clienți, atunci trebuie să ne conformăm. De obicei, nu există un Ops puternic în companie la început. Inițial, lucrăm la produs, iar abia apoi înțelegem că, pentru ca produsul să funcționeze, trebuie să ne uităm la livrări. Aici apare Ops. servers, trebuie să ne ocupăm de livrări. Atunci apare Ops. Rămâne de înțeles că Ops, ca divizie separată, va începe să impună o mulțime de bariere pentru dezvoltare și toate livrările vor începe să încetinească. Adică, în acest caz, cultura DevOps este deja relevantă, dar trebuie să nu uităm de partea sa întunecată.
Sursa: habr.com
