Recentemente ho partecipato a DevOpsForum 2019, organizzato da Logrocon. In questa conferenza, i partecipanti cercavano soluzioni e nuovi strumenti per un'interazione efficace tra il business e gli esperti di sviluppo e gestione IT.
La conferenza è stata un successo: ci sono stati davvero molti interventi utili, formati di presentazione interessanti e tanto scambio con i relatori. E, cosa particolarmente importante, nessuno ha cercato di vendermi nulla, un comportamento diffuso tra i relatori delle grandi conferenze negli ultimi tempi.
Un riassunto degli interventi di Raiffeisen Bank, AlfaStrakhovanie, l'esperienza di Mango Telecom nell'implementazione dell'automazione e altri dettagli sotto il tag.
Mi chiamo Jana, lavoro come tester, mi occupo di automazione e DevOps, e adoro partecipare a conferenze e meetup. Negli ultimi due anni sono stata a conferenze organizzate da Oleg Bunin (HighLoad++, TeamLead Conf), a eventi Jug (Heisenbug, JPoint), a TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Per prima cosa, prestiamo attenzione al programma della conferenza. Faccio meno attenzione all'argomento dell'intervento rispetto al relatore. Anche se l'intervento dovesse risultare molto tecnico e interessante, non è affatto detto che tu possa applicare qualche best practice nella tua azienda. E per questo hai bisogno di un relatore.
La luce alla fine del pipeline in Raiffeisen Bank
Di solito, cerco relatori interessanti nei corridoi. A DevOpsForum 2019, un relatore di mio interesse è stato Mikhail Bijan di Raiffeisen Bank. Durante il suo intervento, ha spiegato come stiano gradualmente introducendo i loro team al DevOps, perché ne hanno bisogno e come convincere il business dell'idea della trasformazione DevOps. Inoltre, ha parlato di come vedere la luce alla fine del pipeline.
Mikhail Bijan, direttore dell'automazione in Raiffeisen Bank
Attualmente nella loro azienda non si può parlare di vero DevOps. Cioè, è vero, ma non in tutti i team. Nella sua implementazione, si basano sulla disponibilità dei team sia in termini di ingegneri specifici, sia in termini di necessità del prodotto e maturità della piattaforma su cui è costruito quel prodotto. Misha ha spiegato come comunicare al business il valore del DevOps.
Nel settore bancario ci sono diversi driver di crescita: il costo dei servizi e l'espansione della clientela. Aumentare il costo dei servizi non è un buon driver, mentre la crescita della clientela lo è. Se i concorrenti lanciano un prodotto oggettivamente valido, tutti i clienti tendono a spostarsi lì, e col tempo il mercato si stabilizza. Pertanto, il lancio di nuovi prodotti e la velocità di lancio sono gli aspetti principali su cui si concentrano le banche. È proprio per questo che serve il DevOps, e il business lo comprende.
Un'altra osservazione importante: il DevOps non sempre riduce il time to market. Il DevOps non può funzionare autonomamente, è solo una parte del processo di creazione e lancio di un prodotto sul mercato, dalla fase di sviluppo fino alla produzione (dal codice al cliente). Tutto ciò che avviene prima del codice non ha nulla a che fare con il DevOps. I marketer possono studiare il mercato per anni e passare la vita a inseguire i concorrenti. È necessario comprendere rapidamente di cosa ha bisogno il cliente e pianificare l'implementazione di una determinata funzionalità: spesso è proprio questo ciò che manca affinché il DevOps funzioni e l'azienda raggiunga i propri obiettivi. Pertanto, innanzitutto, in Raiffeisen Bank hanno concordato con il business che dovevano imparare a utilizzare il DevOps. L'automazione fine a sé stessa non aiuterà molto nella conquista di nuovi clienti.
In generale, Misha ritiene che il DevOps debba essere implementato, ma con saggezza. Bisogna essere pronti al fatto che all'inizio della trasformazione la produttività del team potrebbe calare, guadagneranno meno, ma poi questo sarà giustificato.
Automazione dei test in 'Mango Telecom'
Un ulteriore intervento interessante per me come tester è stato quello di Egor Maslov di 'Mango Telecom'. La presentazione si intitolava 'Automazione del ciclo completo di testing in un team SCRUM'. Egor crede che il DevOps sia stato creato proprio per SCRUM, ma al tempo stesso implementare il DevOps in un team SCRUM è piuttosto problematico. Questo accade perché il team SCRUM è sempre di fretta, non ha il tempo di concentrarsi su novità e ristrutturazioni del processo. C'è anche un problema legato al fatto che lo SCRUM non prevede la creazione di sottogruppi all'interno del team (team di tester, team di sviluppatori, ecc.). Inoltre, per automatizzare un processo esistente è necessaria della documentazione, ma nello SCRUM spesso la documentazione è completamente assente: 'il prodotto è più importante di qualche scrittura'.
Dopo il passaggio a SCRUM, i tester hanno iniziato a consultarsi con gli sviluppatori su come testare le funzionalità. Gradualmente, il volume delle funzionalità è aumentato, la documentazione era assente e hanno cominciato a intercettare molti bug in quelle funzionalità che non erano coperte da test e non era chiaro chi le avesse testate e quando. In poche parole: regnava il caos. Hanno deciso di passare all'automazione dei test. Ma anche in quel caso è stato un completo fallimento. Hanno coinvolto specialisti esterni per l'automazione, che scrivevano in un linguaggio sconosciuto ai tester interni. Il framework per i test automatici funzionava, ma dopo che gli esterni se ne sono andati, è sopravvissuto solo due settimane. Segue un secondo tentativo di introdurre i test automatici. È iniziato con l'idea che tutto dovesse essere costruito internamente all'azienda con le proprie forze (direzione corretta: accrescere l'expertise interna), all'interno di SCRUM, e nel processo creare documentazione. Il stack per l'automazione doveva essere identico a quello del prodotto (qui concordo, non testate un progetto JavaScript con qualcos'altro). Alla fine dello sprint, organizzavano una demo di come funzionava il test automatico, coinvolgendo l'intero team (utile). In questo modo, aumentava il coinvolgimento di tutti i membri del team nel processo di automazione e la fiducia nei test automatici, aumentando le probabilità che il test automatico venisse effettivamente utilizzato (e non fosse commentato dopo un mese a causa di continui fallimenti).
A proposito, al DevOpsForum 2019 c'era un microfono aperto, un formato di intervento ben noto e, a mio avviso, utile. Ti muovi, ascolti le presentazioni e poi decidi che nell'ambito della conferenza vale la pena discutere un certo tema o problema, condividere esperienze rilevanti nella risoluzione di compiti.
Ho notato anche che gli organizzatori hanno creato un flusso di interventi brevi. Ogni presentazione dura al massimo 10 minuti, seguita da domande. In questo modo si possono trattare subito molti temi e fare domande ai relatori che interessano.
Tra le presentazioni, ho fatto un giro tra gli stand dei partner della conferenza e ho portato via/vinto molte piccole cose. Ah, adoro i gadget!
Tavolo rotondo e domande sul DevOps con il direttore dello sviluppo di AlfaStrakhovanie.
La ciliegina sulla torta del DevOpsForum 2019 per me è stata la sessione plenaria di un'ora con esperti di DevOps. Sono stati invitati quattro partecipanti alla sessione, che dovevano analizzare il DevOps da diverse prospettive: Anton Isanin (AlfaStrakhovanie, direttore dello sviluppo), Nailya Zamashkina (Fintech Lab, direttore operativo), Oleg Egorkin (Rostelecom, Agile coach) e Anton Martyanov (esperto indipendente, che guardava al DevOps dal punto di vista del business).
Gli esperti si sono seduti più vicino al pubblico e così è iniziato: per un'ora interi partecipanti dalla sala hanno posto domande, e gli esperti si sono adoperati per rispondere. A volte si sono svolti veri dibattiti. Le domande erano delle più varie, ad esempio: servono davvero gli ingegneri DevOps, perché non è possibile formarli dai sistemisti, tutti dovrebbero considerare il DevOps, qual è il valore di quest'ultimo e così via.
Poi, ho parlato personalmente con Anton Isanin. Abbiamo discusso della necessità di portare la cultura DevOps in ogni casa e abbiamo rivelato il lato oscuro della trasformazione DevOps.
Immaginiamo che tutti si siano riuniti e abbiano deciso che il DevOps è necessario sia per il prodotto, sia per il business e il team. Hanno cominciato a implementarlo. È andato tutto bene. Hanno respirato. Il DevOps ci ha avvicinati al cliente, ora possiamo soddisfare rapidamente tutte le sue richieste. In definitiva, abbiamo un grande dipartimento Ops con rigorosi regolamenti e requisiti, e continua a generare difetti nel prodotto, creando tonnellate di richieste. Inoltre, tutti i difetti hanno lo stato "urgente", anche se il cliente ha improvvisamente deciso di cambiare il colore di un pulsante da verde a giallo. Il progetto cresce, aumentano le versioni e, di conseguenza, il numero di difetti e il disorientamento circa le nuove funzionalità da parte dei clienti. Gli Ops assumono 10 persone in più per poter segnalare i difetti, mentre lo sviluppo ne assume 15 in più per poterli risolvere. E invece di implementare nuove funzionalità, il team lavora con continui SD, spiegando le funzionalità agli utenti e, per di più, al supporto. In definitiva, sia gli Ops che lo sviluppo sono impegnati, ma il cliente e il business sono insoddisfatti: le nuove funzionalità si bloccano. Risulta che il DevOps c'è, ma non c'è.
Anton ha affermato chiaramente che la necessità di implementare DevOps dipende direttamente dalle dimensioni del business. Se gestire un solo cliente all'anno genera un miliardo per l'azienda — DevOps non è necessario (a condizione che non sia necessario fornire regolarmente nuove modifiche a quel cliente). Tutto procede per il meglio. Ma se il business cresce e ci sono più clienti, allora è necessario adeguarsi. Di solito, in un'azienda non c'è un grande Ops all'inizio. Prima sviluppiamo il prodotto, e solo dopo capiamo che per far funzionare il prodotto, bisogna monitorare server, tenere d'occhio le forniture. È allora che nasce Ops. Resta da capire che Ops, come reparto separato, inizierà a mettere in atto molti ostacoli per lo sviluppo, e tutte le forniture inizieranno a trovarsi in difficoltà. In questo caso, la cultura DevOps è già rilevante, ma non bisogna dimenticare il suo lato oscuro.
Fonte: habr.com
