Onlangs was ik op het DevOpsForum 2019, georganiseerd door Logrocon. Tijdens deze conferentie probeerden deelnemers oplossingen en nieuwe tools te vinden voor een effectieve samenwerking tussen bedrijven en ontwikkelaars en IT-dienstverleners.
De conferentie was geslaagd: er waren werkelijk veel nuttige presentaties, interessante presentatieformaten en een hoop interactie met de sprekers. En vooral belangrijk, niemand probeerde me iets te verkopen, wat de sprekers op grote conferenties de laatste tijd vaak doen.
Een samenvatting van de presentaties van Raiffeisenbank, Alfastrakhovanie, de ervaring van Mango Telecom bij de implementatie van automatisering en andere details onder de kat.
Ik ben Jana, ik werk als tester, houd me bezig met automatisering, evenals DevOps en ik hou ervan om naar conferenties en meetups te gaan. In de afgelopen twee jaar ben ik naar conferenties van Oleg Bunin gegaan (HighLoad++, TeamLead Conf), naar evenementen van Jug (Heisenbug, JPoint), naar TestCon Moskou, DevOps Pro Moskou, Big Data Moskou.
Als eerste kijk ik naar het programma van de conferentie. In mindere mate kijk ik naar waar de presentatie over zal gaan, en in grotere mate naar de spreker. Zelfs als de presentatie erg technologisch en interessant blijkt te zijn, is het geen feit dat je enkele best practices uit de presentatie in je eigen bedrijf kunt toepassen. Dan heb je een goede spreker nodig.
Licht aan het einde van de pijplijn bij Raiffeisenbank
Gewoonlijk ben ik op jacht naar interessante sprekers in de lobby. Tijdens DevOpsForum 2019 viel een spreker van Raiffeisenbank in mijn interessegebied ā Mikhail Bijan. Tijdens zijn presentatie vertelde hij hoe ze hun teams geleidelijk op DevOps overstappen, waarom ze dit nodig hebben en hoe ze het idee van DevOps-transformatie aan het bedrijf kunnen verkopen. Over het algemeen sprak hij over hoe je het licht aan het einde van de pijplijn kunt zien.
Mikhail Bijan, directeur automatisering bij Raiffeisenbank
Momenteel hebben ze in hun bedrijf geen 'echte DevOps'. Dat wil zeggen, het is echt, maar niet in alle teams. Bij de implementatie van DevOps baseren ze zich op de bereidheid van de teams, zowel qua specifieke ingenieurs als qua de behoefte van het product en de volwassenheid van het platform waarop dit product is gebouwd. Misha legde uit hoe je het bedrijf kunt vertellen waarom DevOps nodig is.
De banksector heeft verschillende groeifactoren: de kosten van diensten en de uitbreiding van de klantenbasis. Een stijging van de kosten van diensten is niet echt een goede groeifactor, maar een groei van de klantenbasis wel. Als concurrenten een objectief goed product lanceren, vertrekken alle klanten daarheen, en na verloop van tijd normaliseert de markt weer. Daarom is het introduceren van nieuwe producten en de snelheid waarmee ze op de markt worden gebracht de belangrijkste focus voor banken. Juist daarvoor is DevOps nodig, en het bedrijfsleven begrijpt dit.
Een volgende belangrijke opmerking: DevOps vermindert niet altijd de time to market. DevOps kan niet alleen functioneren, het is slechts een onderdeel van het proces van productontwikkeling en gezamenlijke winstgevendheid, van ontwikkeling tot productie (van code tot klant). Alles wat voor de code komt, heeft niets met DevOps te maken. Dit betekent dat marketeers jarenlang de markt kunnen bestuderen en hun concurrenten hun hele leven kunnen achterna jagen. Het is noodzakelijk om snel te begrijpen wat de klant nodig heeft en de implementatie van bepaalde functies te plannen ā vaak is dit precies wat ontbreekt voor een effectieve werking van DevOps en voor het bereiken van de doelstellingen van het bedrijf. Daarom zijn ze in Raiffeisenbank in de eerste plaats met het bedrijfsleven overeengekomen dat ze DevOps moesten leren gebruiken. Automatisering alleen omwille van automatisering helpt niet echt in de strijd om nieuwe klanten.
Over het algemeen denkt Misha dat DevOps moet worden geĆÆmplementeerd, maar met wijsheid. Men moet voorbereid zijn op het feit dat de productiviteit van het team in het begin van de transformatie zal dalen, en dat ze minder geld zullen verdienen, maar het zal zich uiteindelijk rechtvaardigen.
Automatisering van testen bij 'Mango Telecom'
Een andere interessante presentatie voor mij als tester werd gegeven door Egor Maslov van 'Mango Telecom'. De presentatie heette 'Automatisering van de volledige testcyclus binnen een SCRUM-team'. Egor is van mening dat DevOps precies voor SCRUM is gemaakt, maar tegelijkertijd is het best problematisch om DevOps in een SCRUM-team te implementeren. Dit komt omdat het SCRUM-team voortdurend aan het rennen is, er is geen tijd om af te leiden naar vernieuwingen en het proces opnieuw te structureren. Het probleem is ook dat SCRUM geen sub-teams binnen het team veronderstelt (zoals een testteam, ontwikkelteam, enzovoort). Bovendien is voor de automatisering van het bestaande proces documentatie nodig, maar in SCRUM ontbreekt documentatie vaak volledig - 'het product is belangrijker dan enige documentatie'.
Na de overgang naar SCRUM begonnen testers met ontwikkelaars te overleggen over hoe ze functies moesten testen. Geleidelijk aan nam de functionaliteit toe, de documentatie ontbrak, en ze ontdekten veel fouten in de functionaliteit waar geen tests voor waren, en het was Ć¼berhaupt niet duidelijk wie en wanneer het had getest. In twee woorden - chaos. Ze besloten over te schakelen op testautomatisering. Maar zelfs toen liep het volledig mis. Ze haalden externe specialisten in voor de automatisering, die schreven in een technologie stack die onbekend was voor de interne testers. Het framework voor geautomatiseerde tests werkte natuurlijk, maar nadat de externen vertrokken waren, hield het slechts twee weken stand. Vervolgens was er een poging om automatisering nummer twee in te voeren. Dit begon met de realisatie dat alles intern in het bedrijf moest worden opgebouwd, met eigen middelen (de juiste richting: bouw expertise intern op), binnen SCRUM, en ondertussen documentatie aan te maken. De stack voor automatisering moest overeenkomen met de stack van het product (hier ben ik het volledig mee eens, test een project niet met iets anders dan JavaScript). Aan het einde van de sprint organiseerden ze een demo van hoe de geautomatiseerde test werkte, met deelname van het hele team (nuttig). Op deze manier werd de betrokkenheid van alle teamleden in het automatiseringsproces vergroot, evenals het vertrouwen in de geautomatiseerde tests en de kans dat deze tests daadwerkelijk gebruikt zouden worden (en niet na een maand worden uitgecommentarieerd vanwege constante mislukkingen).
Overigens was er op DevOpsForum 2019 een open microfoon - een al lang bekend en, naar mijn mening, nuttig formaat voor presentaties. Je loopt rond, luistert naar lezingen, en beslist dan dat er tijdens de conferentie een onderwerp of probleem is dat je wilt bespreken, en waar je relevante ervaringen over het oplossen van een probleem wilt delen.
Ik merkte ook op dat de organisatoren een reeks korte presentaties hebben gemaakt. Elke presentatie duurt niet langer dan 10 minuten, gevolgd door vragen. Op die manier kunnen veel onderwerpen meteen aan bod komen, en kunnen deelnemers vragen stellen aan de sprekers die interessant waren.
Tussen de lezingen door heb ik een rondje gelopen langs de stands van de partners van de conferentie en heb ik veel verschillende snuisterijen verzameld. Oh, ik hou van giveaways!
Ronde tafel en vragen over DevOps met de ontwikkelingsdirecteur van AlfaStrakhovanie.
De kers op de taart van DevOpsForum 2019 voor mij was de uur durende plenaire sessie met DevOps-experts. Vier deelnemers aan de sessie waren uitgenodigd om DevOps vanuit verschillende perspectieven te bekijken: Anton Isanin (AlfaStrakhovanie, ontwikkelingsdirecteur), Nailya Zamashkina (Fintech Lab, operationeel directeur), Oleg Egorkin (Rostelecom, Agile-coach) en Anton Martyanov (onafhankelijke expert, kijkt naar DevOps vanuit zakelijk perspectief).
De experts gingen dichter bij het publiek zitten en het begon: een vol uur stelden deelnemers uit de zaal hun vragen, en de experts moesten zich er doorheen slaan. Soms ontstonden er echte debatten. De vragen waren zeer divers, bijvoorbeeld: zijn DevOps-engineers Ć¼berhaupt nodig, waarom kunnen we ze niet uit systeembeheerders kweken, moet iedereen DevOps aangeboden krijgen, wat is de waarde ervan, enzovoort.
Daarna sprak ik persoonlijk met Anton Isanin. We bespraken de noodzaak om de DevOps-cultuur naar elk huis te brengen en belichtten de donkere kant van de DevOps-transformatie.
Stel je voor dat iedereen zich heeft verzameld en besloten heeft dat DevOps nodig is voor zowel het product als het bedrijf en het team. We zijn begonnen met implementeren. Het is gelukt. We hebben opgelucht ademgehaald. DevOps heeft ons dichter bij de klant gebracht, nu kunnen we al zijn wensen snel vervullen. Uiteindelijk hebben we een grote Ops-afdeling met strikte regels en vereisten, en die blijft voortdurend defecten op het product aanbrengen en een heleboel aanvragen creƫren. Bovendien komen alle defecten met de status 'spoed', zelfs als de klant ineens besloot de knop geel in plaats van groen te verven. Het project groeit, het aantal releases groeit en dus ook het aantal defecten en onduidelijkheden over nieuwe functionaliteiten voor klanten. Ops huurt nog 10 mensen in om defecten te rapporteren, terwijl de ontwikkeling nog eens 15 mensen inhuurt om ze op te lossen. En in plaats van nieuwe functies te implementeren, werkt het team met eindeloze SD's, waarbij ze de functionaliteit aan de gebruiker uitleggen en ook aan de support. Uiteindelijk zijn zowel Ops als ontwikkeling druk, maar de klant en het bedrijf zijn ontevreden: nieuwe functies komen vast te zitten. Het lijkt erop dat er wel DevOps is, maar ook niet.
Wat betreft de noodzaak om DevOps te implementeren, stelde Anton duidelijk dat dit rechtstreeks afhankelijk is van de omvang van het bedrijf. Als de dienstverlening aan Ć©Ć©n klant per jaar het bedrijf een miljard oplevert - is DevOps niet nodig (tenzij je deze klant regelmatig nieuwe wijzigingen hoeft aan te bieden). Alles gaat prima. Maar als het bedrijf groeit en er meer klanten komen, dan moet je wel kunnen voldoen aan die vraag. Gewoonlijk heeft een bedrijf aanvankelijk geen geweldige Ops. Eerst bouwen we het product en daarna realiseren we ons dat, om het product te laten werken, we ook moeten letten op servers, de leveringen. Dan ontstaat Ops. We moeten echter begrijpen dat Ops, als afzonderlijke afdeling, veel barriĆØres voor de ontwikkeling zal opwerpen en alle leveringen daardoor zullen vastlopen. Dus in dit geval is de DevOps-cultuur al relevant, maar we moeten niet de donkere kant ervan vergeten.
Bron: habr.com
