Am participat recent la DevOpsForum 2019, găzduit de Logrocon. La această conferință, participanții au încercat să găsească soluții și noi instrumente pentru interacțiunea eficientă între business și specialiști în domeniul dezvoltării și serviciilor tehnologia informației.
Conferința a fost un succes: au fost într-adevăr o mulțime de rapoarte utile, formate de prezentare interesante și multă comunicare cu vorbitorii. Și este deosebit de important că nimeni nu a încercat să-mi vândă nimic, lucru de care s-au făcut vinovați în ultima vreme vorbitorii de la conferințe mari.
Un extras din discursurile Raiffeisenbank, Alfastrakhovanie, experiența Mango Telecom în implementarea automatizării și alte detalii sub tăietură.
Numele meu este Yana, lucrez ca tester, fac automatizare, precum și DevOps și îmi place să merg la conferințe și întâlniri. În ultimii doi ani, am fost la conferințele lui Oleg Bunin (HighLoad++, TeamLead Conf), evenimente Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
În primul rând, atrag atenția asupra programului conferinței. Mă uit mai puțin la despre ce va fi raportul și mai mult la vorbitor. Chiar dacă raportul se dovedește a fi foarte tehnologic și interesant, nu este un fapt că vei putea aplica unele dintre cele mai bune practici din raport în compania ta. Și atunci ai nevoie de un difuzor.
Lumină la capătul conductei la Raiffeisenbank
De obicei, vânez difuzoare pe margine care mă interesează. La DevOpsForum 2019, un vorbitor de la Raiffeisenbank, Mikhail Bizhan, mi-a atras interesul. În timpul discursului său, el a vorbit despre cum își atrag treptat echipele de DevOps, de ce au nevoie de el și despre cum să vândă ideea transformării DevOps către afaceri. Ei bine, în general, am vorbit despre cum să vezi lumina la capătul conductei.
Mikhail Bizhan, director de automatizare la Raiffeisenbank
Acum nu au „DevOps” în compania lor. Adică lucrează, dar nu la toate echipele. Atunci când implementează DevOps, aceștia se bazează pe pregătirea echipelor, atât în ceea ce privește inginerii specifici, cât și în ceea ce privește nevoia produsului și maturitatea platformei pe care este construit acest produs. Misha a spus cum să explice unei companii de ce este nevoie de DevOps.
Segmentul 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 foarte bun, dar creșterea bazei de clienți este opusul. Dacă concurenții lansează un produs obiectiv, toți clienții merg acolo, apoi, în timp, piața se nivelează. Prin urmare, introducerea de noi produse pe piață și viteza de introducere a acestora este principalul lucru pe care se concentrează băncile. Exact pentru asta este DevOps, iar companiile înțeleg acest lucru.
Următoarea notă importantă: DevOps nu reduce întotdeauna timpul de lansare pe piață. DevOps nu poate funcționa singur, este doar o parte a procesului de creare și aducere pe piață a unui produs, de la dezvoltare la producție (de la cod la client). Dar totul înainte de cod nu este direct legat de DevOps. Adică, agenții de marketing pot studia piața ani de zile și își pot petrece întreaga viață ajungând din urmă cu concurenții. Este necesar să înțelegeți rapid de ce are nevoie clientul și să planificați implementarea acestei sau acelei caracteristici - de multe ori acest lucru nu este suficient pentru ca DevOps să funcționeze și pentru ca compania să își atingă obiectivul. Prin urmare, în primul rând, Raiffeisenbank a fost de acord cu afacerile că este necesar să înveți cum să folosești DevOps. Automatizarea de dragul automatizării nu va ajuta prea mult în lupta pentru noi clienți.
În general, Misha consideră că DevOps trebuie implementat, dar cu înțelepciune. Și trebuie să fim pregătiți pentru faptul că la începutul transformării productivitatea echipei va scădea, va câștiga mai puțini bani, dar apoi va fi justificat.
Automatizarea testării la Mango Telecom
Un alt raport interesant pentru mine ca tester a fost dat de Egor Maslov de la Mango Telecom. Prezentarea s-a numit „Automatizarea întregului ciclu de testare într-o echipă SCRUM”. Egor consideră că DevOps a fost creat special pentru SCRUM, dar, în același timp, introducerea DevOps într-o echipă SCRUM este destul de problematică. Acest lucru se întâmplă pentru că echipa SCRUM rulează mereu undeva, nu există timp să fii distras de inovații și să reconstruiești procesul. Problema constă și în faptul că SCRUM nu presupune separarea sub-echipelor din echipă (echipă de testare, echipă de dezvoltare etc.). Ei bine, în plus, pentru a automatiza un proces existent aveți nevoie de documentație, iar în SCRUM de cele mai multe ori nu există documentație completă - „produsul este mai important decât un fel de scriere”.
După trecerea la SCRUM, testerii au început să se consulte cu dezvoltatorii cu privire la modul de testare a funcțiilor. Treptat, volumul de funcționalități a crescut, nu a existat nicio documentare și au început să prindă o mulțime de bug-uri în funcționalitate care nu erau acoperite de teste și în general nu mai era clar cine a testat-o și când. Pe scurt - confuzie și vacillare. Am decis să trecem la automatizarea testării. Dar chiar și atunci a fost un eșec total. Au angajat specialiști externalizați în automatizare care au scris pe o stivă necunoscută de testerii interni. Cadrul pentru autotestări a funcționat, desigur, dar după ce externalizatorii au plecat, a durat două săptămâni. Următoarea a fost o încercare de a introduce autotestarea numărul doi. A început cu faptul că totul trebuie construit în cadrul companiei, pe cont propriu (vectorul potrivit: construiți expertiză intern), în cadrul SCRUM și creați documentație în acest proces. Stiva de automatizare ar trebui să fie egală cu stiva de produs (aici o adaug, nu testați proiectul JavaScript cu nimic altceva). La sfârșitul sprintului, au făcut o demonstrație a modului în care funcționează autotestul cu întreaga echipă (utilă). Astfel, a crescut implicarea tuturor membrilor echipei în procesul de automatizare, precum și încrederea în autotestări și șansa ca acest autotest să fie cu siguranță folosit (și să nu fie comentat într-o lună din cauza eșecurilor constante).
Apropo, la DevOpsForum 2019 a existat un microfon deschis - un format de discursuri cunoscut și, după părerea mea, util. Te plimbi așa, asculți rapoarte și apoi decideți că la conferință merită să discutați un anumit subiect sau problemă, împărtășind experiența relevantă în rezolvarea problemei.
De asemenea, am observat că organizatorii au făcut un flux de scurte reportaje. Fiecare raport nu durează mai mult de 10 minute, urmat de întrebări. Astfel, puteți acoperi multe subiecte simultan și puteți pune întrebări vorbitorilor care vă interesează.
Între prezentări, m-am plimbat prin cabinele partenerilor de conferință și am furat/câștigat o mulțime de lucruri. Oh, îmi place fișa!
Masa rotundă și probleme DevOps cu directorul de dezvoltare de la Alfastrakhovanie
Cireasa de pe tortul DevOpsForum 2019 pentru mine a fost sesiunea plenară de o oră cu experții DevOps. Patru participanți la sesiune au fost invitați să privească DevOps din unghiuri diferite: Anton Isanin (Alfastrakhovanie, director de dezvoltare), Nailya Zamashkina (Fintech Lab, director operațional), Oleg Egorkin (Rostelecom, antrenor Agile) și Anton Martyanov (expert independent, a analizat DevOps). din punct de vedere al afacerilor).
Experții s-au așezat mai aproape de oameni și atunci lucrurile au început să se întâmple: timp de o oră întreagă, participanții din public și-au pus întrebările, iar experții au luat rap. Uneori au fost adevărate dezbateri. Întrebările au fost foarte diferite, de exemplu: sunt necesari inginerii DevOps, de ce nu pot fi instruiți ca administratori de sistem, ar trebui să fie oferit DevOps tuturor, care este valoarea lui și așa mai departe.
Apoi, am vorbit personal cu Anton Isanin. Am discutat despre necesitatea de a aduce cultura DevOps în fiecare casă și am dezvăluit partea întunecată a transformării DevOps.
Să ne imaginăm că toată lumea s-a reunit și a decis că DevOps este nevoie atât de produs, cât și de companie și echipă. Hai să-l punem în aplicare. Totul a mers. Am expirat. DevOps ne-a apropiat de client, acum îi putem îndeplini rapid toate dorințele. Ca urmare, avem un departament de operațiuni mare, cu reglementări și cerințe stricte, care găsește constant defecte în produs și creează o grămadă de solicitări. Mai mult, tuturor defectelor li se atribuie statutul „urgent”, chiar dacă clientul a dorit în mod neașteptat să coloreze butonul în galben în loc de verde. Proiectul este în creștere, numărul de lansări este în creștere și, în consecință, numărul de defecte și neînțelegeri ale noii funcționalități de către clienți. Ops angajează încă 10 persoane pentru a ține pasul cu raportarea defectelor, iar Development angajează încă 15 pentru a ține pasul cu închiderea acestora. Și în loc să introducă funcții noi, echipa lucrează cu SD-uri nesfârșite, explicând funcționalitatea și suportul în același timp. Drept urmare, atât operațiunile, cât și dezvoltarea funcționează, dar clientul și afacerea sunt nemulțumiți: funcțiile noi se blochează. Se pare că DevOps pare să existe, dar nu pare să existe.
În ceea ce privește necesitatea implementării DevOps, Anton a declarat clar că acest lucru depinde direct de amploarea afacerii. Dacă deservirea unui client pe an aduce companiei un miliard, DevOps nu este necesar (cu condiția să nu fie nevoie să implementați noi modificări la acest client în mod regulat). Totul este acoperit cu ciocolată. Dar dacă afacerea crește și apar mai mulți clienți, atunci trebuie să te conformezi. De regulă, inițial nu există operațiuni grozave în companie. Mai întâi tăiem produsul și abia apoi înțelegem că, pentru ca produsul să funcționeze, trebuie să fim cu ochii pe servere și să monitorizăm consumabilele. Atunci ia naștere Ops. Rămâne de înțeles că Ops, ca divizie separată, va începe să ridice o grămadă de bariere în calea dezvoltării și toate livrările vor începe să se blocheze. Adică, în acest caz, cultura DevOps este deja relevantă, dar nu trebuie să uităm de latura ei întunecată.
Sursa: www.habr.com