Ik was onlangs aanwezig bij DevOpsForum 2019, gehost door Logrocon. Op deze conferentie probeerden de deelnemers oplossingen en nieuwe hulpmiddelen te vinden voor effectieve interactie tussen het bedrijfsleven en specialisten op het gebied van ontwikkeling en informatietechnologiediensten.
De conferentie was een succes: er waren echt veel nuttige rapporten, interessante presentatieformats en veel communicatie met de sprekers. En het is vooral belangrijk dat niemand mij iets probeerde te verkopen, iets waar sprekers op grote conferenties zich de laatste tijd schuldig aan hebben gemaakt.
Een fragment uit de toespraken van Raiffeisenbank, Alfastrakhovanie, Mango Telecom’s ervaring met het implementeren van automatisering en andere details onder de aandacht.
Mijn naam is Yana, ik werk als tester, ik doe automatisering, maar ook DevOps en ik ga graag naar conferenties en meetups. De afgelopen twee jaar ben ik naar de conferenties van Oleg Bunin geweest (HighLoad++, TeamLead Conf), Jug-evenementen (Heisenbug, JPoint), TestCon Moskou, DevOps Pro Moskou, Big Data Moskou.
Allereerst vestig ik de aandacht op het conferentieprogramma. Ik kijk minder naar waar het rapport over gaat, en meer naar de spreker. Zelfs als het rapport zeer technologisch en interessant blijkt te zijn, is het geen feit dat u enkele van de best practices uit het rapport in uw bedrijf zult kunnen toepassen. En dan heb je een luidspreker nodig.
Licht aan het einde van de pijpleiding bij Raiffeisenbank
Normaal gesproken zoek ik langs de zijlijn naar sprekers die mij interesseren. Op DevOpsForum 2019 trok een spreker van Raiffeisenbank, Mikhail Bizhan, mijn interesse. Tijdens zijn toespraak vertelde hij hoe ze hun teams geleidelijk verslaafd maken aan DevOps, waarom ze het nodig hebben en hoe ze het idee van DevOps-transformatie aan het bedrijfsleven kunnen verkopen. Over het algemeen sprak ik over hoe je het licht aan het einde van de pijplijn kunt zien.
Mikhail Bizhan, directeur automatisering bij Raiffeisenbank
Nu hebben ze geen “DevOps” in hun bedrijf. Dat wil zeggen, hij werkt, maar niet in alle teams. Bij de implementatie van DevOps vertrouwen ze op de bereidheid van de teams, zowel wat betreft specifieke engineers, als wat betreft de behoefte aan het product en de volwassenheid van het platform waarop dit product is gebouwd. Misha vertelde hoe je aan een bedrijf kunt uitleggen waarom DevOps nodig is.
Het banksegment heeft verschillende groeimotoren: de kosten van diensten en de uitbreiding van het klantenbestand. Het verhogen van de kosten van diensten is geen goede drijfveer, maar het vergroten van het klantenbestand is het tegenovergestelde. Als concurrenten een objectief cool product uitbrengen, gaan alle klanten daarheen, en na verloop van tijd zal de markt zich stabiliseren. Daarom is het introduceren van nieuwe producten op de markt en de snelheid waarmee ze worden geïntroduceerd het belangrijkste waar banken zich op concentreren. Dit is precies waar DevOps voor is, en bedrijven begrijpen dit.
De volgende belangrijke opmerking: DevOps verkort niet altijd de time-to-market. DevOps kan niet alleen werken, het is slechts een onderdeel van het proces van het creëren en op de markt brengen van een product, van ontwikkeling tot productie (van code tot klant). Maar alles vóór de code heeft niet direct verband met DevOps. Dat wil zeggen dat marketeers de markt jarenlang kunnen bestuderen en hun hele leven bezig zijn met het inhalen van concurrenten. Het is noodzakelijk om snel te begrijpen wat de klant nodig heeft en de implementatie van een of andere functie te plannen - vaak is dit niet genoeg om DevOps te laten werken en het bedrijf zijn doel te laten bereiken. Daarom was Raiffeisenbank het in de eerste plaats met het bedrijfsleven eens dat het nodig was om DevOps te leren gebruiken. Automatisering omwille van de automatisering zal niet veel helpen in de strijd om nieuwe klanten.
Over het algemeen is Misha van mening dat DevOps geïmplementeerd moet worden, maar wel verstandig. En we moeten erop voorbereid zijn dat aan het begin van de transformatie de productiviteit van het team zal dalen, het minder geld zal verdienen, maar dan zal het gerechtvaardigd zijn.
Automatisering van testen bij Mango Telecom
Een ander interessant rapport voor mij als tester werd gegeven door Egor Maslov van Mango Telecom. De presentatie heette ‘Automatisering van de volledige testcyclus in een SCRUM-team’. Egor is van mening dat DevOps specifiek voor SCRUM is gemaakt, maar tegelijkertijd is het introduceren van DevOps in een SCRUM-team behoorlijk problematisch. Dit gebeurt omdat het SCRUM-team altijd ergens aan het rennen is, er geen tijd is om afgeleid te worden door innovaties en het proces opnieuw op te bouwen. Het probleem ligt ook in het feit dat SCRUM geen scheiding van subteams in het team met zich meebrengt (testteam, ontwikkelingsteam, enzovoort). Trouwens, om een bestaand proces te automatiseren is documentatie nodig, en in SCRUM is er meestal geen volledige documentatie - "het product is belangrijker dan een of andere vorm van schrijven."
Nadat ze waren overgestapt op SCRUM, begonnen testers met ontwikkelaars te overleggen over het testen van functies. Geleidelijk nam het volume van de functionaliteit toe, er was geen documentatie en ze begonnen veel bugs in de functionaliteit op te vangen die niet door tests werden gedekt, en in het algemeen was het niet langer duidelijk wie het testte en wanneer. Kortom: verwarring en aarzeling. We besloten over te stappen op testautomatisering. Maar zelfs toen was er sprake van een complete mislukking. Ze huurden externe automatiseringsspecialisten in die op een stapel schreven die onbekend was bij interne testers. Het raamwerk voor autotests werkte uiteraard, maar nadat de uitbesteders waren vertrokken, bleef het twee weken bestaan. Vervolgens werd een poging ondernomen om autotesting nummer twee te introduceren. Het begon met het feit dat alles binnen het bedrijf zelf gebouwd moet worden (de juiste vector: intern expertise opbouwen), binnen het raamwerk van SCRUM, en daarbij documentatie creëren. De stapel voor automatisering moet gelijk zijn aan de stapel van het product (hier voeg ik deze toe, test uw JavaScript-project niet met iets anders). Aan het einde van de sprint deden ze met het hele team een demo van hoe de autotest werkt (handig). Zo nam de betrokkenheid van alle teamleden bij het automatiseringsproces toe, evenals het vertrouwen in autotests en de kans dat deze autotest zeker gebruikt zal worden (en niet binnen een maand zal worden becommentarieerd vanwege voortdurende storingen).
Trouwens, op DevOpsForum 2019 was er een open microfoon - een al lang bekend en, naar mijn mening, nuttig formaat van toespraken. Je loopt zo rond, luistert naar rapporten en besluit dan dat het op de conferentie de moeite waard is om een bepaald onderwerp of probleem te bespreken en relevante ervaringen te delen bij het oplossen van het probleem.
Het viel mij ook op dat de organisatoren een stroom korte reportages maakten. Elk rapport duurt maximaal 10 minuten, gevolgd door vragen. Zo kun je veel onderwerpen tegelijk behandelen en vragen stellen aan sprekers die je interesseren.
Tussen de presentaties door liep ik langs de stands van de conferentiepartners en stal/won ik veel spullen. Oh, ik vind de hand-out zo leuk!
Rondetafelgesprek en DevOps-problemen met de ontwikkelingsdirecteur bij Alfastrakhovanie
De kers op de DevOpsForum 2019-taart was voor mij de urenlange plenaire sessie met DevOps-experts. Vier sessiedeelnemers werden uitgenodigd om DevOps vanuit verschillende invalshoeken te bekijken: Anton Isanin (Alfastrakhovanie, ontwikkelingsdirecteur), Nailya Zamashkina (Fintech Lab, operationeel directeur), Oleg Egorkin (Rostelecom, Agile coach) en Anton Martyanov (onafhankelijk expert, gekeken naar DevOps vanuit zakelijk oogpunt).
De experts gingen dichter bij de mensen zitten en toen begon het te gebeuren: een uur lang stelden deelnemers uit het publiek hun vragen, en de experts namen de rap op. Soms waren er echte debatten. De vragen waren bijvoorbeeld heel verschillend: zijn DevOps-engineers überhaupt nodig, waarom kunnen ze niet worden opgeleid tot systeembeheerders, moet DevOps aan iedereen worden aangeboden, wat is de waarde ervan, enzovoort.
Vervolgens heb ik persoonlijk met Anton Isanin gesproken. We bespraken de noodzaak om de DevOps-cultuur naar ieder huis te brengen en onthulden de donkere kant van de DevOps-transformatie.
Laten we ons voorstellen dat iedereen bij elkaar kwam en besloot dat DevOps nodig is, zowel voor het product als voor het bedrijf en het team. Laten we het gaan implementeren. Alles is gelukt. Wij ademden uit. DevOps heeft ons dichter bij de klant gebracht, nu kunnen we snel al zijn wensen vervullen. Als gevolg hiervan hebben we een grote Ops-afdeling met strikte regels en eisen, die voortdurend defecten in het product ontdekt en een heleboel verzoeken genereert. Bovendien krijgen alle gebreken de status ‘urgent’, ook als de opdrachtgever onverhoopt de knop geel wilde kleuren in plaats van groen. Het project groeit, het aantal releases groeit en daarmee ook het aantal defecten en misverstanden over nieuwe functionaliteit bij klanten. Ops neemt nog eens tien mensen in dienst om de rapportage van defecten bij te houden, en Development neemt nog eens vijftien mensen in dienst om de problemen op te lossen. En in plaats van nieuwe features te introduceren, werkt het team met eindeloze SD's, waarbij de functionaliteit aan de gebruiker wordt uitgelegd en tegelijkertijd ondersteuning wordt geboden. Als gevolg hiervan zijn zowel Ops als Development in bedrijf, maar zijn de klant en het bedrijf ontevreden: nieuwe functies blijven hangen. Het blijkt dat DevOps lijkt te bestaan, maar het lijkt niet te bestaan.
Met betrekking tot de noodzaak om DevOps te implementeren, heeft Anton duidelijk aangegeven dat dit rechtstreeks afhangt van de schaal van het bedrijf. Als het bedienen van één klant per jaar het bedrijf een miljard oplevert, is DevOps niet nodig (mits je niet regelmatig nieuwe wijzigingen bij deze klant hoeft uit te rollen). Alles is bedekt met chocolade. Maar als het bedrijf groeit en er meer klanten verschijnen, moet u hieraan voldoen. In de regel zijn er aanvankelijk geen coole Ops in het bedrijf. Eerst snijden we het product, en pas dan begrijpen we dat we, om het product te laten werken, de servers in de gaten moeten houden en de voorraden moeten controleren. Dat is het moment waarop Ops ontstaat. Het valt nog te begrijpen dat Ops, als afzonderlijke divisie, een aantal barrières voor de ontwikkeling zal opwerpen en dat alle leveringen zullen stagneren. Dat wil zeggen dat in dit geval de DevOps-cultuur al relevant is, maar we mogen de donkere kant ervan niet vergeten.
Bron: www.habr.com