Ik haw koartlyn DevOpsForum 2019 bywenne, host troch Logrocon. Op dizze konferinsje besochten dielnimmers oplossingen en nije ark te finen foar effektive ynteraksje tusken saaklike en ûntwikkeling en spesjalisten foar ynformaasjetechnologytsjinsten.
De konferinsje wie in súkses: der wiene echt in soad nuttige rapporten, nijsgjirrige presintaasjeformaten en in soad kommunikaasje mei de sprekkers. En it is foaral wichtich dat nimmen my wat besocht te ferkeapjen, eat dêr't sprekkers op grutte konferinsjes har de lêste tiid oan skuldich makke hawwe.
In úttreksel út 'e taspraken fan Raiffeisenbank, Alfastrakhovanie, Mango Telecom's ûnderfining yn it útfieren fan automatisearring en oare details ûnder de besuniging.
Myn namme is Yana, ik wurkje as tester, ik doch automatisearring, lykas DevOps, en ik gean graach nei konferinsjes en gearkomsten. Yn 'e ôfrûne twa jier haw ik de konferinsjes fan Oleg Bunin west (HighLoad ++, TeamLead Conf), Jug-eveneminten (Heisenbug, JPoint), TestCon Moskou, DevOps Pro Moskou, Big Data Moskou.
Foarearst vestig ik de oandacht op it konferinsjeprogramma. Ik sjoch minder nei wêr't it rapport oer gean sil, en mear nei de sprekker. Sels as it rapport heul technologysk en ynteressant blykt te wêzen, is it gjin feit dat jo guon fan 'e bêste praktiken út it rapport yn jo bedriuw kinne tapasse. En dan hawwe jo in sprekker nedich.
Ljocht oan 'e ein fan' e pipeline by Raiffeisenbank
Meastentiids sykje ik foar sprekkers oan 'e kant dy't my ynteressearje. Op DevOpsForum 2019 fong in sprekker fan Raiffeisenbank, Mikhail Bizhan, myn belangstelling. Tidens syn taspraak spruts hy oer hoe't se har teams stadichoan oan 'e DevOps krije, wêrom't se it nedich binne, en hoe't se it idee fan DevOps-transformaasje kinne ferkeapje oan bedriuw. No, yn 't algemien haw ik it oer hoe't jo it ljocht sjen kinne oan' e ein fan 'e pipeline.
Mikhail Bizhan, direkteur fan automatisearring by Raiffeisenbank
No hawwe se gjin "DevOps" yn har bedriuw. Dat is, hy wurket, mar net yn alle teams. By it ymplementearjen fan DevOps fertrouwe se op 'e reewilligens fan' e teams, sawol yn termen fan spesifike yngenieurs, as yn termen fan it ferlet fan it produkt en de folwoeksenheid fan it platfoarm wêrop dit produkt is boud. Misha fertelde hoe't jo in bedriuw útlizze kinne wêrom DevOps nedich is.
It banksegment hat ferskate groeidriuwers: kosten fan tsjinsten en útwreiding fan 'e klantbasis. It ferheegjen fan de kosten fan tsjinsten is net in heul goede sjauffeur, mar it groeien fan 'e klantbasis is it tsjinoerstelde. As konkurrinten in objektyf cool produkt frijlitte, geane alle klanten derhinne, dan wurdt de merk oer de tiid út. Dêrom is it yntrodusearjen fan nije produkten op 'e merk en de snelheid fan har yntroduksje it wichtichste ding dat banken rjochtsje op. Dit is krekt wêrfoar DevOps is, en bedriuwen begripe dit.
De folgjende wichtige opmerking: DevOps fermindert net altyd de tiid om te merken. DevOps kin net allinich wurkje, it is gewoan diel fan it proses fan it meitsjen en bringen fan in produkt op 'e merk fan ûntwikkeling oant produksje (fan koade oant klant). Mar alles foar de koade is net direkt relatearre oan DevOps. Dat is, marketeers kinne de merk jierrenlang studearje en har heule libben besteegje oan it ynheljen fan konkurrinten. It is needsaaklik om fluch te begripen wat de klant nedich is en de ymplemintaasje fan dizze of dy funksje planje - faaks is dit wat net genôch is foar DevOps om te wurkjen en it bedriuw om har doel te berikken. Dêrom, yn it foarste plak, Raiffeisenbank ôfpraat mei it bedriuwslibben dat it wie nedich om te learen hoe te brûken DevOps. Automatisearring om 'e wille fan automatisearring sil net folle helpe yn' e striid om nije klanten.
Yn 't algemien is Misha fan betinken dat DevOps moat wurde ymplementearre, mar ferstannich. En wy moatte taret wêze op it feit dat oan it begjin fan 'e transformaasje de produktiviteit fan it team sil sakje, it sil minder jild fertsjinje, mar dan sil it rjochtfeardich wêze.
Automatisearring fan testen by Mango Telecom
In oar nijsgjirrich rapport foar my as tester waard jûn troch Egor Maslov fan Mango Telecom. De presintaasje waard neamd "Automatisaasje fan 'e folsleine testsyklus yn in SCRUM-team." Egor is fan betinken dat DevOps spesifyk makke is foar SCRUM, mar tagelyk is it yntrodusearjen fan DevOps yn in SCRUM-team frij problematysk. Dit bart om't it SCRUM-team altyd earne rint, d'r is gjin tiid om ôf te lieden troch ynnovaasjes en it proses opnij op te bouwen. It probleem sit ek yn it feit dat SCRUM net de skieding fan subteams yn it team (testteam, ûntwikkelingsteam, ensfh.) omfettet. No, boppedat, om in besteande proses te automatisearjen, is dokumintaasje nedich, en yn SCRUM is d'r meastentiids gjin dokumintaasje folslein - "it produkt is wichtiger dan wat soarte fan skriuwen."
Nei it wikseljen nei SCRUM, begon testers te rieplachtsjen mei ûntwikkelders oer hoe't jo funksjes kinne testen. Stadichoan naam it folume fan funksjonaliteit ta, d'r wie gjin dokumintaasje, en se begûnen in protte bugs yn 'e funksjonaliteit te fangen dy't net waarden dekt troch tests en yn it algemien wie it net mear dúdlik wa't it testte en wannear. Yn in notedop - betizing en twifel. Wy besletten om oer te skeakeljen nei testautomatisaasje. Mar ek doe wie der in folsleine mislearring. Se hierden útbestege automatisearring spesjalisten dy't skreau op in stapel ûnbekend foar in-house testers. It ramt foar autotests wurke fansels, mar nei't de útbestegers fuortgien wiene, duorre it twa wiken. Folgjende wie in besykjen om autotesting nûmer twa yn te fieren. It begûn mei it feit dat alles boud wurde moat binnen it bedriuw, op jo eigen (de juste vector: opbouwe ekspertize yntern), yn it ramt fan SCRUM, en meitsje dokumintaasje yn it proses. De stapel foar automatisearring moat gelyk wêze oan de stapel fan it produkt (hjir foegje ik it ta, test jo JavaScript-projekt net mei wat oars). Oan 'e ein fan' e sprint diene se in demo fan hoe't de autotest wurket mei it hiele team (nuttich). Sa is de belutsenens fan alle teamleden yn it automatisearringsproses ferhege, lykas it fertrouwen yn autotests en de kâns dat dizze autotest definityf brûkt wurdt (en sil net yn in moanne kommentearre wurde fanwege konstante mislearrings).
Trouwens, by DevOpsForum 2019 wie d'r in iepen mikrofoan - in lang bekend en, nei myn miening, nuttich formaat fan taspraken. Jo rinne sa om, harkje nei rapporten, en beslute dan dat it op 'e konferinsje it wurdich is om in bepaald ûnderwerp of probleem te besprekken, relevante ûnderfining te dielen by it oplossen fan it probleem.
Ik fernaam ek dat de organisatoaren in stream fan koarte reportaazjes makken. Elk rapport duorret net mear as 10 minuten, folge troch fragen. Op dizze manier kinne jo in protte ûnderwerpen tagelyk dekke en fragen stelle oan sprekkers dy't jo ynteressearje.
Tusken de presintaasjes rûn ik om de hokjes fan de konferinsjepartners hinne en stiel/wûn in protte guod. Oh, ik hâld fan 'e handout!
Rûne tafel en DevOps-problemen mei de ûntwikkelingsdirekteur by Alfastrakhovanie
De kers op 'e taart fan DevOpsForum 2019 foar my wie de oerenlange plenêre sesje mei DevOps-eksperts. Fjouwer sesje-dielnimmers waarden útnoege om DevOps út ferskate hoeken te sjen: Anton Isanin (Alfastrakhovanie, ûntwikkelingsdirekteur), Nailya Zamashkina (Fintech Lab, bestjoeringsdirekteur), Oleg Egorkin (Rostelecom, Agile coach) en Anton Martyanov (ûnôfhinklike ekspert, seach nei DevOps út in saaklik eachpunt).
De saakkundigen sieten tichter by de minsken en doe begûnen dingen te barren: in heal oere lang stelden dielnimmers út it publyk harren fragen, en de saakkundigen namen de rap. Soms wiene der echte debatten. De fragen wiene bygelyks hiel oars: binne DevOps-yngenieurs überhaupt nedich, wêrom kinne se net oplaat wurde as systeembehearders, moatte DevOps oan elkenien oanbean wurde, wat is de wearde, ensfh.
Doe spruts ik persoanlik mei Anton Isanin. Wy besprutsen de needsaak om de DevOps-kultuer nei elk hûs te bringen en iepenbiere de tsjustere kant fan DevOps-transformaasje.
Litte wy ús foarstelle dat elkenien byinoar kaam en besletten dat DevOps nedich is sawol troch it produkt as troch it bedriuw en it team. Litte wy it útfiere. Alles slagge. Wy útademen. DevOps hat ús tichter by de klant brocht, no kinne wy al syn winsken fluch ferfolje. As gefolch hawwe wy in grutte Ops ôfdieling mei strange regeljouwing en easken, en it fynt konstant mankeminten yn it produkt en skept in bosk oanfragen. Boppedat wurde alle mankeminten de status "urgent" tawiisd, sels as de kliïnt ûnferwachts de knop giel yn plak fan grien kleurje woe. It projekt groeit, it oantal releases groeit en, dêrtroch, it oantal defekten en misferstannen fan nije funksjonaliteit troch kliïnten. Ops hiert 10 mear minsken yn om by te hâlden mei it rapportearjen fan defekten, en ûntwikkeling hiert 15 mear om by te hâlden mei it sluten fan se. En ynstee fan nije funksjes yn te fieren, wurket it team mei einleaze SD's, ferklearje de funksjonaliteit oan 'e brûker en stipe tagelyk. As gefolch binne sawol Ops as ûntwikkeling yn bedriuw, mar de klant en it bedriuw binne ûngelokkich: nije funksjes sitte fêst. It docht bliken dat DevOps liket te bestean, mar it liket net te bestean.
Oangeande de needsaak om DevOps te ymplementearjen, sei Anton dúdlik dat dit direkt hinget fan 'e skaal fan it bedriuw. As it betsjinjen fan ien klant yn 't jier it bedriuw in miljard bringt, is DevOps net nedich (foarsafier't jo gjin nije wizigingen nei dizze klant moatte regelmjittich útrolje). Alles is bedutsen mei sûkelade. Mar as it bedriuw groeit en mear kliïnten ferskine, dan moatte jo foldwaan. As regel binne d'r yn 't earstoan gjin koele Ops yn it bedriuw. Earst snije wy it produkt, en pas dan begripe wy dat om it produkt te wurkjen, wy moatte de tsjinners yn 'e gaten hâlde en leveringen kontrolearje. Dat is doe't Ops ûntstiet. It bliuwt te begrepen dat Ops, as in aparte divyzje, sil begjinne te setten in boskje barriêres foar ûntwikkeling en alle leveringen sille begjinne te stall. Dat is, yn dit gefal is de DevOps-kultuer al relevant, mar wy moatte har tsjustere kant net ferjitte.
Boarne: www.habr.com