Aghju assistitu recentemente à DevOpsForum 2019, ospitatu da Logrocon. In questa cunferenza, i participanti anu pruvatu à truvà suluzioni è novi arnesi per l'interazzione efficace trà l'affari è u sviluppu è i specialisti di u serviziu di l'informatica.
A cunferenza hè stata un successu: ci era veramente assai rapporti utili, formati di presentazione interessanti è assai cumunicazioni cù i parlanti. È hè soprattuttu impurtante chì nimu hà pruvatu à vende qualcosa, qualcosa chì i parlanti in grandi cunferenze sò stati culpèvuli ultimamente.
Un extracte di i discorsi di Raiffeisenbank, Alfastrakhovanie, l'esperienza di Mango Telecom in implementà l'automatizazione è altri dettagli sottu u cut.
Mi chjamu Yana, travagliu cum'è tester, facciu l'automatizazione, è ancu DevOps, è mi piace à andà à cunferenze è riunioni. In l'ultimi dui anni, aghju statu à e cunferenze di Oleg Bunin (HighLoad++, TeamLead Conf), Jug events (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Prima di tuttu, attira l'attenzione à u prugramma di a cunferenza. Fighjulu menu à ciò chì u rapportu serà circa, è più à u parlante. Ancu s'è u rapportu hè assai tecnulugicu è interessante, ùn hè micca un fattu chì puderete applicà alcune di e migliori pratiche da u rapportu in a vostra cumpagnia. È dopu avete bisognu di un parlante.
Luce à a fine di u pipeline à Raiffeisenbank
Di solitu, caccia per i parlanti à u latu chì m'interessa. À DevOpsForum 2019, un parlante di Raiffeisenbank, Mikhail Bizhan, hà attiratu u mo interessu. Duranti u so discorsu, hà parlatu di cumu si avvicinanu gradualmente i so squadre à DevOps, perchè ne anu bisognu, è cumu vende l'idea di trasfurmazioni DevOps à l'affari. Eppo, in generale, aghju parlatu di cumu vede a luce à a fine di u pipeline.
Mikhail Bizhan, direttore di l'automatizazione in Raiffeisenbank
Avà ùn anu micca "DevOps" in a so cumpagnia. Questu hè, travaglia, ma micca in tutti i squadre. Quandu implementanu DevOps, si basanu nantu à a prontezza di e squadre, sia in termini di ingegneri specifichi, sia in quantu à a necessità di u pruduttu è a maturità di a piattaforma nantu à quale hè custruitu stu pruduttu. Misha hà dettu cumu spiegà à una impresa perchè DevOps hè necessariu.
U segmentu bancariu hà parechji mutori di crescita: u costu di servizii è espansione di a basa di clienti. Aumentà u costu di i servizii ùn hè micca un mutore assai bonu, ma cresce a basa di clientella hè u cuntrariu. Se i cuncurrenti liberanu un pruduttu obiettivamente cool, tutti i clienti vanu quì, allora cù u tempu u mercatu si stende. Per quessa, l'introduzione di novi prudutti à u mercatu è a rapidità di a so introduzione hè u principale chì i banche fucalizza. Questu hè esattamente ciò chì DevOps hè per, è l'imprese capiscenu questu.
A prossima nota impurtante: DevOps ùn riduce micca sempre u tempu di mercatu. DevOps ùn pò micca travaglià solu, hè solu una parte di u prucessu di creazione è di purtà un pruduttu à u mercatu da u sviluppu à a produzzione (da u codice à u cliente). Ma tuttu prima di u codice ùn hè micca direttamente ligatu à DevOps. Vale à dì, i cummercializatori ponu studià u mercatu per anni è passanu a so vita sana à chjappà cù i cuncurrenti. Hè necessariu di capisce rapidamente ciò chì u cliente hà bisognu è pianificà l'implementazione di questa o quella funzione - spessu questu hè ciò chì ùn hè micca abbastanza per DevOps per travaglià è a cumpagnia per ottene u so scopu. Dunque, prima di tuttu, Raiffeisenbank accunsenu cù l'affari chì era necessariu d'amparà cumu utilizà DevOps. L'automatizazione per l'automatizazione ùn aiuterà micca assai in a lotta per i novi clienti.
In generale, Misha crede chì DevOps deve esse implementatu, ma cun prudenza. È avemu da esse preparatu per u fattu chì à l'iniziu di a trasfurmazioni a produtividade di a squadra scenderà, guadagnà menu soldi, ma allora serà ghjustificatu.
Automatizazione di teste in Mango Telecom
Un altru rapportu interessante per mè cum'è tester hè statu datu da Egor Maslov da Mango Telecom. A presentazione hè stata chjamata "Automatizazione di u ciclu di teste cumpletu in una squadra SCRUM". Egor crede chì DevOps hè statu creatu apposta per SCRUM, ma à u stessu tempu, l'introduzione di DevOps in una squadra SCRUM hè abbastanza problematica. Questu succede perchè a squadra SCRUM hè sempre in esecuzione in un locu, ùn ci hè micca tempu per esse distrattu da l'innuvazioni è ricustruisce u prucessu. U prublema hè ancu in u fattu chì SCRUM ùn implica micca a siparazione di sub-squadre in a squadra (squadra di teste, squadra di sviluppu, etc.). Eppo, in più, per automatizà un prucessu esistenti, a documentazione hè necessaria, è in SCRUM, a maiò spessu, ùn ci hè micca una documentazione cumpletamente - "u pruduttu hè più impurtante chè qualchì tipu di scrittura".
Dopu avè cambiatu à SCRUM, i testatori cuminciaru à cunsultà cù i sviluppatori nantu à cumu pruvà e funzioni. A pocu à pocu, u voluminu di funziunalità cresce, ùn ci era micca ducumentazione, è cuminciaru à catturà assai bug in a funziunalità chì ùn era micca cupartu da e teste è in generale ùn era più chjaru quale hà pruvatu è quandu. In poche parole - cunfusione è vacillazione. Avemu decisu di passà à l'automatizazione di teste. Ma ancu allora ci hè statu un fallimentu cumpletu. Hanu assuciatu specialisti in automatizazione esternalizzati chì anu scrittu annantu à una pila scunnisciuta da i testatori interni. U quadru per l'autotests hà travagliatu, sicuru, ma dopu chì l'outsourcers partianu, durò duie simane. In seguitu hè statu un tentativu di presentà l'autotesting numeru dui. Accuminciau cù u fattu chì tuttu deve esse custruitu in l'impresa, nantu à u vostru propiu (u vettore ghjustu: custruisce un sapè fà internamente), in u quadru di SCRUM, è creà documentazioni in u prucessu. A pila per l'automatizazione deve esse uguale à a pila di u pruduttu (quì aghju aghjustatu, ùn pruvate micca u vostru prughjettu JavaScript cù qualcosa altru). À a fine di u sprint, anu fattu una demo di cumu funziona l'autotest cù tutta a squadra (utile). Cusì, l'implicazione di tutti i membri di l'equipa in u prucessu d'automatizazione hà aumentatu, è dinò a fiducia in l'autotest è a chance chì questu autotest serà definitamente utilizatu (è ùn serà micca cummentatu in un mesi per via di fallimenti custanti).
Per via, à DevOpsForum 2019 ci era un micru apertu - un formatu di discorsi longu cunnisciutu è, in u mo parè, utile. Camminate cusì, ascolta i rapporti, è poi decide chì à a cunferenza vale a pena discutiri un certu tema o prublema, sparte una sperienza pertinente per risolve u prublema.
Aghju nutatu ancu chì l'urganizatori anu fattu un flussu di brevi rapporti. Ogni rapportu ùn dura micca più di 10 minuti, seguitu da dumande. Questu modu pudete copre parechji temi à una volta è dumandà dumande à i parlanti chì vi interessanu.
Trà presentazioni, aghju andatu intornu à e cabine di i partenarii di cunferenza è arrubati / vintu assai cose. Eh, mi piace a manu !
Tavola rotonda è prublemi DevOps cù u direttore di sviluppu in Alfastrakhovanie
A ciliegina nantu à a torta DevOpsForum 2019 per mè hè stata a sessione plenaria di un'ora cù esperti di DevOps. Quattru participanti di sessione sò stati invitati à vede DevOps da diverse anguli: Anton Isanin (Alfastrakhovanie, direttore di sviluppu), Nailya Zamashkina (Fintech Lab, direttore operatore), Oleg Egorkin (Rostelecom, coach Agile) è Anton Martyanov (espertu indipendente, hà guardatu DevOps). da un puntu di vista cummerciale).
L'esperti si pusonu più vicinu à a ghjente è dopu e cose cuminciaru à succede: per una ora sana, i participanti di l'audienza anu dumandatu e so dumande, è l'esperti anu pigliatu u rap. Calchì volta ci sò stati veri dibattiti. E dumande eranu assai diverse, per esempiu: sò l'ingegneri DevOps necessarii à tutti, perchè ùn ponu micca esse furmati cum'è amministratori di sistema, DevOps deve esse offertu à tutti, quale hè u so valore, etc.
Dopu, aghju parlatu cù Anton Isanin personalmente. Avemu discututu a necessità di portà a cultura DevOps in ogni casa è hà revelatu u latu scuru di a trasformazione DevOps.
Imaginemu chì tutti si sò riuniti è decisu chì DevOps hè necessariu sia da u pruduttu sia da l'affari è a squadra. Andemu à implementà. Tuttu hà travagliatu. Avemu expiratu. DevOps ci hà avvicinatu à u cliente, avà pudemu cumpiendu rapidamente tutti i so desideri. In u risultatu, avemu un grande dipartimentu Ops cù rigulamenti stretti è esigenze, è constantemente trova difetti in u pruduttu è crea una mansa di richieste. Inoltre, tutti i difetti sò attribuiti u statutu "urgente", ancu s'ellu u cliente hà vulsutu inaspettatamente colore u buttone giallu invece di verde. U prugettu hè in crescita, u numeru di versioni hè crescente è, per quessa, u numeru di difetti è malintesi di novi funziunalità da i clienti. Ops assume 10 persone in più per seguità cù i difetti di rapportu, è u sviluppu assume 15 più per mantene a chjusa. È invece d'intruduce e funzioni novi, a squadra travaglia cù SD infiniti, spieghendu a funziunalità à l'utilizatori è supportu à u stessu tempu. In u risultatu, sia Ops è sviluppu sò in l'affari, ma u cliente è l'affari sò infelici: e funzioni novi si bloccanu. Ci hè chì DevOps pare esse esiste, ma ùn pare micca esse.
In quantu à a necessità di implementà DevOps, Anton hà dichjaratu chjaramente chì questu dipende direttamente da a scala di l'affari. Se u serviziu di un cliente à l'annu porta à a cumpagnia un miliardo, DevOps ùn hè micca necessariu (sempre chì ùn avete micca bisognu di lancià novi cambiamenti à stu cliente regularmente). Tuttu hè cupartu di cioccolatu. Ma se l'affari cresce è più clienti appariscenu, allora avete bisognu di cunfurmà. In regula, ùn ci hè micca Ops cool in a cumpagnia inizialmente. Prima avemu tagliatu u pruduttu, è solu dopu avemu capitu chì, per u produttu per travaglià, avemu bisognu di guardà un ochju nantu à i servitori è monitorà i pruvisti. Hè quandu Ops nasce. Resta da esse capitu chì Ops, cum'è una divisione separata, cumincià à mette una mansa di barriere à u sviluppu è tutte e spedizioni cumincianu à stallà. Hè, in questu casu, a cultura DevOps hè digià pertinente, ma ùn deve micca scurdatu di u so latu scuru.
Source: www.habr.com