Di recente ho partecipato al DevOpsForum 2019, ospitato da Logrocon. In questa conferenza, i partecipanti hanno cercato di trovare soluzioni e nuovi strumenti per un'interazione efficace tra business e specialisti dei servizi di sviluppo e tecnologia dell'informazione.
La conferenza è stata un successo: ci sono state davvero molte relazioni utili, formati di presentazione interessanti e molta comunicazione con i relatori. Ed è particolarmente importante che nessuno abbia cercato di vendermi qualcosa, cosa di cui ultimamente si sono resi colpevoli i relatori delle grandi conferenze.
Un estratto dai discorsi di Raiffeisenbank, Alfastrakhovanie, l'esperienza di Mango Telecom nell'implementazione dell'automazione e altri dettagli sotto taglio.
Mi chiamo Yana, lavoro come tester, mi occupo di automazione e DevOps e adoro andare a conferenze e incontri. Negli ultimi due anni ho partecipato alle conferenze di Oleg Bunin (HighLoad++, TeamLead Conf), agli eventi Jug (Heisenbug, JPoint), TestCon Mosca, DevOps Pro Mosca, Big Data Mosca.
Innanzitutto attiro l'attenzione sul programma della conferenza. Guardo meno l'argomento della relazione e più l'oratore. Anche se il report risulta essere molto tecnologico e interessante, non è un dato di fatto che sarai in grado di applicare alcune delle migliori pratiche del report nella tua azienda. E poi hai bisogno di un oratore.
Luce alla fine del gasdotto presso la Raiffeisenbank
Di solito cerco relatori in disparte che mi interessano. Al DevOpsForum 2019, un relatore della Raiffeisenbank, Mikhail Bizhan, ha catturato il mio interesse. Durante il suo intervento, ha parlato di come i loro team stanno gradualmente appassionandosi a DevOps, del motivo per cui ne hanno bisogno e di come vendere l'idea della trasformazione DevOps al business. Bene, in generale, ho parlato di come vedere la luce alla fine del gasdotto.
Mikhail Bizhan, direttore dell'automazione della Raiffeisenbank
Ora non hanno “DevOps” nella loro azienda. Cioè, lavora, ma non in tutte le squadre. Quando implementano DevOps, fanno affidamento sulla disponibilità dei team, sia in termini di ingegneri specifici, sia in termini di necessità del prodotto e maturità della piattaforma su cui è costruito questo prodotto. Misha ha spiegato come spiegare a un'azienda perché è necessario DevOps.
Il segmento bancario presenta diversi driver di crescita: costo dei servizi e ampliamento della base clienti. L’aumento del costo dei servizi non è un buon driver, ma l’aumento della base di clienti è l’opposto. Se i concorrenti rilasciano un prodotto oggettivamente interessante, tutti i clienti vanno lì, poi col tempo il mercato si livella. Pertanto, l'introduzione di nuovi prodotti sul mercato e la velocità della loro introduzione sono l'aspetto principale su cui si concentrano le banche. Questo è esattamente lo scopo di DevOps e le aziende lo capiscono.
La prossima nota importante: DevOps non sempre riduce il time to market. DevOps non può funzionare da solo, è solo una parte del processo di creazione e immissione di un prodotto sul mercato, dallo sviluppo alla produzione (dal codice al cliente). Ma tutto ciò che precede il codice non è direttamente correlato a DevOps. Cioè, gli esperti di marketing possono studiare il mercato per anni e trascorrere l’intera vita a mettersi al passo con i concorrenti. È necessario comprendere rapidamente di cosa ha bisogno il cliente e pianificare l'implementazione di questa o quella funzionalità: spesso questo è ciò che non è sufficiente affinché DevOps funzioni e l'azienda raggiunga il suo obiettivo. Pertanto la Raiffeisenbank ha concordato innanzitutto con le aziende che fosse necessario imparare a utilizzare DevOps. L'automazione fine a se stessa non aiuterà molto nella lotta per nuovi clienti.
In generale, Misha ritiene che DevOps debba essere implementato, ma con saggezza. E dobbiamo essere preparati al fatto che all'inizio della trasformazione la produttività della squadra diminuirà, guadagnerà meno soldi, ma poi sarà giustificato.
Automazione dei test presso Mango Telecom
Un altro rapporto interessante per me come tester è stato fornito da Egor Maslov di Mango Telecom. La presentazione si chiamava "Automazione dell'intero ciclo di test in un team SCRUM". Egor ritiene che DevOps sia stato creato appositamente per SCRUM, ma allo stesso tempo introdurre DevOps in un team SCRUM è piuttosto problematico. Ciò accade perché il team SCRUM corre sempre da qualche parte, non c'è tempo per farsi distrarre dalle innovazioni e ricostruire il processo. Il problema sta anche nel fatto che SCRUM non prevede la separazione dei sottoteam all'interno del team (team di test, team di sviluppo e così via). Ebbene, inoltre, per automatizzare il processo esistente, è necessaria la documentazione e in SCRUM molto spesso non esiste completamente documentazione: "il prodotto è più importante di qualche tipo di scrittura".
Dopo essere passati a SCRUM, i tester hanno iniziato a consultarsi con gli sviluppatori su come testare le funzionalità. A poco a poco, il volume delle funzionalità è aumentato, non c'era documentazione e hanno iniziato a rilevare molti bug nella funzionalità che non erano coperti dai test e in generale non era più chiaro chi l'ha testata e quando. In poche parole: confusione e indecisione. Abbiamo deciso di passare all'automazione dei test. Ma anche allora si verificò un completo fallimento. Hanno assunto specialisti di automazione in outsourcing che hanno scritto su uno stack sconosciuto ai tester interni. Il quadro per gli autotest ha funzionato, ovviamente, ma dopo che gli outsourcer se ne sono andati, è durato due settimane. Successivamente c'è stato un tentativo di introdurre l'autotest numero due. Tutto è iniziato con il fatto che tutto deve essere costruito all'interno dell'azienda, da soli (il vettore giusto: sviluppare competenze internamente), nell'ambito di SCRUM, e creare documentazione nel processo. Lo stack per l'automazione dovrebbe essere uguale allo stack del prodotto (qui lo aggiungo, non testare il tuo progetto JavaScript con nient'altro). Alla fine dello sprint hanno fatto una dimostrazione di come funziona l'autotest con l'intero team (utile). Pertanto, è aumentato il coinvolgimento di tutti i membri del team nel processo di automazione, così come la fiducia negli autotest e la possibilità che questo autotest venga sicuramente utilizzato (e non venga commentato tra un mese a causa dei continui fallimenti).
A proposito, al DevOpsForum 2019 c'era un microfono aperto, un formato di discorsi noto da tempo e, a mio avviso, utile. Vai in giro in questo modo, ascolti i resoconti e poi decidi che alla conferenza vale la pena discutere un determinato argomento o problema, condividendo esperienze rilevanti nella risoluzione del problema.
Ho anche notato che gli organizzatori hanno redatto un flusso di brevi resoconti. Ogni relazione dura non più di 10 minuti, seguita da domande. In questo modo puoi trattare molti argomenti contemporaneamente e porre domande ai relatori che ti interessano.
Tra una presentazione e l'altra ho camminato tra gli stand dei partner della conferenza e ho rubato/vinto un sacco di cose. Oh, adoro il volantino!
Tavola rotonda e questioni 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 gli esperti DevOps. Quattro partecipanti alla sessione sono stati invitati a esaminare DevOps da diverse angolazioni: Anton Isanin (Alfastrakhovanie, direttore dello sviluppo), Nailya Zamashkina (Fintech Lab, direttore operativo), Oleg Egorkin (Rostelecom, Agile coach) e Anton Martyanov (esperto indipendente, ha esaminato DevOps dal punto di vista commerciale).
Gli esperti si sono seduti più vicino alla gente e poi le cose hanno cominciato a succedere: per un'ora intera i partecipanti del pubblico hanno posto le loro domande e gli esperti si sono presi la colpa. A volte c'erano veri e propri dibattiti. Le domande erano molto diverse, ad esempio: sono davvero necessari gli ingegneri DevOps, perché non possono essere formati come amministratori di sistema, DevOps dovrebbe essere offerto a tutti, qual è il suo valore e così via.
Poi ho parlato personalmente con Anton Isanin. Abbiamo discusso della necessità di portare la cultura DevOps in ogni casa e rivelato il lato oscuro della trasformazione DevOps.
Immaginiamo che tutti si riuniscano e decidano che DevOps è necessario sia per il prodotto che per l'azienda e il team. Andiamo a implementarlo. Tutto ha funzionato. Abbiamo espirato. DevOps ci ha avvicinato al cliente, ora possiamo esaudire rapidamente tutti i suoi desideri. Di conseguenza, disponiamo di un ampio reparto operativo con normative e requisiti rigorosi, che rileva costantemente difetti nel prodotto e crea una serie di richieste. Inoltre, a tutti i difetti viene assegnato lo stato “urgente”, anche se il cliente inaspettatamente ha voluto colorare il pulsante giallo invece che verde. Il progetto cresce, cresce il numero di versioni e, di conseguenza, il numero di difetti e incomprensioni delle nuove funzionalità da parte dei clienti. Ops assume altre 10 persone per tenere il passo con la segnalazione dei difetti e lo sviluppo ne assume altre 15 per tenere il passo con la loro chiusura. E invece di introdurre nuove funzionalità, il team lavora con infiniti SD, spiegando all'utente la funzionalità e il supporto allo stesso tempo. Di conseguenza, sia le operazioni che lo sviluppo funzionano, ma il cliente e l'azienda non sono soddisfatti: le nuove funzionalità si bloccano. Si scopre che DevOps sembra esistere, ma non sembra esistere.
Per quanto riguarda la necessità di implementare DevOps, Anton ha affermato chiaramente che ciò dipende direttamente dalle dimensioni dell'azienda. Se servire un cliente all'anno porta all'azienda un miliardo, DevOps non è necessario (a condizione che non sia necessario implementare regolarmente nuove modifiche a questo cliente). Tutto è ricoperto di cioccolato. Ma se l’attività cresce e compaiono più clienti, allora è necessario conformarsi. Di norma, inizialmente non ci sono operazioni interessanti in azienda. Per prima cosa tagliamo il prodotto e solo allora capiamo che affinché il prodotto funzioni è necessario tenere d'occhio i server e monitorare le forniture. È allora che nasce Ops. Resta da capire che Ops, come divisione separata, inizierà a erigere una serie di barriere allo sviluppo e tutte le consegne inizieranno a bloccarsi. Cioè, in questo caso, la cultura DevOps è già rilevante, ma non dobbiamo dimenticare il suo lato oscuro.
Fonte: habr.com