Kamakailan ay dumalo ako sa DevOpsForum 2019, na hino-host ni Logrocon. Sa kumperensyang ito, sinubukan ng mga kalahok na humanap ng mga solusyon at bagong tool para sa epektibong pakikipag-ugnayan sa pagitan ng negosyo at pag-unlad at mga espesyalista sa serbisyo ng teknolohiya ng impormasyon.
Naging matagumpay ang kumperensya: talagang maraming kapaki-pakinabang na ulat, kawili-wiling mga format ng pagtatanghal at maraming komunikasyon sa mga tagapagsalita. At lalong mahalaga na walang sinuman ang nagtangkang magbenta sa akin ng anuman, isang bagay na ang mga nagsasalita sa malalaking kumperensya ay nagkasala kamakailan.
Isang sipi mula sa mga talumpati ng Raiffeisenbank, Alfastrakhovanie, karanasan ng Mango Telecom sa pagpapatupad ng automation at iba pang mga detalye sa ilalim ng cut.
My name is Yana, I work as a tester, I do automation, as well as DevOps, and I love going to conference and meetups. Sa nakalipas na dalawang taon, nakapunta ako sa mga kumperensya ni Oleg Bunin (HighLoad++, TeamLead Conf), Jug event (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Una sa lahat, binibigyang pansin ko ang programa ng kumperensya. Hindi ko masyadong tinitingnan kung tungkol saan ang ulat, at higit pa sa tagapagsalita. Kahit na ang ulat ay naging napaka-teknolohiya at kawili-wili, hindi isang katotohanan na magagawa mong ilapat ang ilan sa mga pinakamahusay na kagawian mula sa ulat sa iyong kumpanya. At pagkatapos ay kailangan mo ng isang speaker.
Banayad sa dulo ng pipeline sa Raiffeisenbank
Kadalasan, naghahanap ako ng mga nagsasalita sa gilid na interesado ako. Sa DevOpsForum 2019, isang tagapagsalita mula sa Raiffeisenbank, si Mikhail Bizhan, ang nakakuha ng aking interes. Sa kanyang talumpati, pinag-usapan niya kung paano nila unti-unting nahuhuli ang kanilang mga koponan sa DevOps, kung bakit nila ito kailangan, at kung paano ibenta ang ideya ng pagbabagong DevOps sa negosyo. Well, sa pangkalahatan, napag-usapan ko kung paano makita ang liwanag sa dulo ng pipeline.
Mikhail Bizhan, direktor ng automation sa Raiffeisenbank
Ngayon ay wala silang "DevOps" sa kanilang kumpanya. Ibig sabihin, nagtatrabaho siya, ngunit hindi sa lahat ng mga koponan. Kapag nagpapatupad ng DevOps, umaasa sila sa kahandaan ng mga koponan, kapwa sa mga tuntunin ng mga partikular na inhinyero, at sa mga tuntunin ng pangangailangan ng produkto at ang kapanahunan ng platform kung saan binuo ang produktong ito. Sinabi ni Misha kung paano ipaliwanag sa isang negosyo kung bakit kailangan ang DevOps.
Ang segment ng pagbabangko ay may ilang mga driver ng paglago: gastos ng mga serbisyo at pagpapalawak ng base ng kliyente. Ang pagtaas ng halaga ng mga serbisyo ay hindi isang napakahusay na driver, ngunit ang pagpapalaki ng base ng kliyente ay ang kabaligtaran. Kung ang mga kakumpitensya ay naglalabas ng isang talagang cool na produkto, ang lahat ng mga customer ay pupunta doon, pagkatapos ay sa paglipas ng panahon ang mga antas ng merkado. Samakatuwid, ang pagpapakilala ng mga bagong produkto sa merkado at ang bilis ng kanilang pagpapakilala ay ang pangunahing bagay na pinagtutuunan ng pansin ng mga bangko. Para sa mismong ito ang DevOps, at naiintindihan ito ng mga negosyo.
Ang susunod na mahalagang tala: Hindi palaging binabawasan ng DevOps ang oras sa market. Ang DevOps ay hindi maaaring gumana nang mag-isa, ito ay bahagi lamang ng proseso ng paglikha at pagdadala ng isang produkto sa merkado mula sa pag-unlad hanggang sa produksyon (mula sa code hanggang sa customer). Ngunit ang lahat bago ang code ay hindi direktang nauugnay sa DevOps. Iyon ay, maaaring pag-aralan ng mga marketer ang merkado sa loob ng maraming taon at gugulin ang kanilang buong buhay na nakakakuha ng mga kakumpitensya. Ito ay kinakailangan upang mabilis na maunawaan kung ano ang kailangan ng kliyente at planuhin ang pagpapatupad ng ito o ang tampok na iyon - kadalasan ito ang hindi sapat para gumana ang DevOps at ang kumpanya upang makamit ang layunin nito. Samakatuwid, una sa lahat, sumang-ayon ang Raiffeisenbank sa negosyo na kinakailangan upang matutunan kung paano gamitin ang DevOps. Ang automation para sa kapakanan ng automation ay hindi makakatulong nang malaki sa paglaban para sa mga bagong customer.
Sa pangkalahatan, naniniwala si Misha na kailangang ipatupad ang DevOps, ngunit matalino. At dapat tayong maging handa sa katotohanan na sa simula ng pagbabagong-anyo ay bababa ang pagiging produktibo ng koponan, kikita ito ng mas kaunting pera, ngunit pagkatapos ay mabibigyang-katwiran ito.
Automation ng pagsubok sa Mango Telecom
Ang isa pang kawili-wiling ulat para sa akin bilang isang tester ay ibinigay ni Egor Maslov mula sa Mango Telecom. Ang pagtatanghal ay tinawag na "Pag-automate ng buong ikot ng pagsubok sa isang pangkat ng SCRUM." Naniniwala si Egor na ang DevOps ay partikular na nilikha para sa SCRUM, ngunit sa parehong oras, ang pagpapakilala ng DevOps sa isang SCRUM team ay medyo may problema. Nangyayari ito dahil ang koponan ng SCRUM ay palaging tumatakbo sa isang lugar, walang oras upang magambala ng mga pagbabago at muling itayo ang proseso. Ang problema ay nakasalalay din sa katotohanan na ang SCRUM ay hindi nagsasangkot ng paghihiwalay ng mga sub-team sa koponan (testing team, development team, at iba pa). Buweno, bukod sa, upang i-automate ang isang umiiral na proseso, kinakailangan ang dokumentasyon, at sa SCRUM, kadalasan ay walang ganap na dokumentasyon - "ang produkto ay mas mahalaga kaysa sa ilang uri ng pagsulat."
Pagkatapos lumipat sa SCRUM, nagsimulang kumunsulta ang mga tester sa mga developer kung paano subukan ang mga feature. Unti-unti, tumaas ang dami ng pag-andar, walang dokumentasyon, at nagsimula silang mahuli ng maraming mga bug sa pag-andar na hindi sakop ng mga pagsubok at sa pangkalahatan ay hindi na malinaw kung sino ang sumubok nito at kung kailan. Sa maikling salita - pagkalito at pagkabalisa. Nagpasya kaming lumipat sa testing automation. Ngunit kahit noon ay nagkaroon ng ganap na kabiguan. Kumuha sila ng mga outsourced na espesyalista sa automation na nagsulat sa isang stack na hindi alam ng mga in-house na tester. Ang balangkas para sa mga autotest ay gumana, siyempre, ngunit pagkaalis ng mga outsourcer, tumagal ito ng dalawang linggo. Sumunod ay isang pagtatangka na ipakilala ang autotesting number two. Nagsimula ito sa katotohanan na ang lahat ay kailangang itayo sa loob ng kumpanya, sa iyong sarili (ang tamang vector: bumuo ng kadalubhasaan sa loob), sa loob ng balangkas ng SCRUM, at lumikha ng dokumentasyon sa proseso. Ang stack para sa automation ay dapat na katumbas ng stack ng produkto (dito ko idinaragdag ito, huwag subukan ang iyong proyekto sa JavaScript sa anumang bagay). Sa pagtatapos ng sprint, gumawa sila ng demo kung paano gumagana ang autotest sa buong team (nakakatulong). Kaya, ang paglahok ng lahat ng mga miyembro ng koponan sa proseso ng automation ay tumaas, pati na rin ang tiwala sa mga autotest at ang pagkakataon na ang autotest na ito ay tiyak na gagamitin (at hindi magkomento sa isang buwan dahil sa patuloy na pagkabigo).
Sa pamamagitan ng paraan, sa DevOpsForum 2019 mayroong isang bukas na mikropono - isang matagal nang kilala at, sa palagay ko, kapaki-pakinabang na format ng mga talumpati. Naglalakad ka nang ganito, makinig sa mga ulat, at pagkatapos ay magpasya na sa kumperensya ito ay nagkakahalaga ng pagtalakay sa isang partikular na paksa o problema, pagbabahagi ng may-katuturang karanasan sa paglutas ng problema.
Napansin ko rin na ang mga organizer ay gumawa ng isang stream ng mga maikling ulat. Ang bawat ulat ay tumatagal ng hindi hihigit sa 10 minuto, na sinusundan ng mga tanong. Sa paraang ito maaari mong masakop ang maraming paksa nang sabay-sabay at magtanong sa mga tagapagsalita na interesado ka.
Sa pagitan ng mga presentasyon, naglibot ako sa mga booth ng mga kasosyo sa kumperensya at nagnakaw/nanalo ng maraming bagay. Eh, gusto ko yung handout!
Round table at DevOps isyu sa development director sa Alfastrakhovanie
Ang icing sa DevOpsForum 2019 cake para sa akin ay ang isang oras na plenaryo session kasama ang mga eksperto sa DevOps. Apat na kalahok sa session ang inimbitahan na tingnan ang DevOps mula sa iba't ibang anggulo: Anton Isanin (Alfastrakhovanie, development director), Nailya Zamashkina (Fintech Lab, operating director), Oleg Egorkin (Rostelecom, Agile coach) at Anton Martyanov (independent expert, tumingin sa DevOps mula sa pananaw ng negosyo).
Ang mga eksperto ay umupo nang mas malapit sa mga tao at pagkatapos ay nagsimulang mangyari ang mga bagay: sa loob ng isang buong oras, ang mga kalahok mula sa madla ay nagtanong ng kanilang mga katanungan, at ang mga eksperto ay kumuha ng rap. Minsan may mga totoong debate. Ang mga tanong ay ibang-iba, halimbawa: kailangan ba ng mga inhinyero ng DevOps, bakit hindi sila sanayin bilang mga tagapangasiwa ng system, kung ang DevOps ay iaalok sa lahat, ano ang halaga nito, at iba pa.
Pagkatapos, kinausap ko ng personal si Anton Isanin. Tinalakay namin ang pangangailangang dalhin ang kultura ng DevOps sa bawat tahanan at inihayag ang madilim na bahagi ng pagbabagong DevOps.
Isipin natin na ang lahat ay nagsama-sama at nagpasya na ang DevOps ay kailangan pareho ng produkto at ng negosyo at ng koponan. Ipatupad natin ito. Nagwork out ang lahat. Bumuntong hininga kami. Inilapit tayo ng DevOps sa kliyente, ngayon ay mabilis nating matutupad ang lahat ng kanyang mga hiling. Bilang resulta, mayroon kaming malaking departamento ng Ops na may mahigpit na mga regulasyon at kinakailangan, at patuloy itong nakakahanap ng mga depekto sa produkto at lumilikha ng isang grupo ng mga kahilingan. Bukod dito, ang lahat ng mga depekto ay itinalaga ang "kagyat" na katayuan, kahit na ang kliyente ay hindi inaasahang nais na kulayan ang pindutan ng dilaw sa halip na berde. Ang proyekto ay lumalaki, ang bilang ng mga release ay lumalaki at, nang naaayon, ang bilang ng mga depekto at hindi pagkakaunawaan ng bagong pag-andar ng mga kliyente. Ang Ops ay kumukuha ng 10 pang tao para makasabay sa pag-uulat ng mga depekto, at ang development ay kumukuha ng 15 pang tao para makasabay sa pagsasara ng mga ito. At sa halip na magpakilala ng mga bagong feature, gumagana ang team sa walang katapusang SD's, na nagpapaliwanag ng functionality sa user at suporta sa parehong oras. Bilang resulta, parehong gumagana ang Ops at development, ngunit hindi nasisiyahan ang kliyente at negosyo: natigil ang mga bagong feature. Lumalabas na tila umiiral ang DevOps, ngunit tila hindi ito umiiral.
Tungkol sa pangangailangang ipatupad ang DevOps, malinaw na sinabi ni Anton na direktang nakasalalay ito sa laki ng negosyo. Kung ang paglilingkod sa isang kliyente sa isang taon ay magdadala sa kumpanya ng isang bilyon, hindi kailangan ang DevOps (sa kondisyon na hindi mo kailangang regular na maglunsad ng mga bagong pagbabago sa kliyenteng ito). Ang lahat ay natatakpan ng tsokolate. Ngunit kung lumago ang negosyo at mas maraming kliyente ang lumitaw, kailangan mong sumunod. Bilang isang patakaran, walang cool na Ops sa kumpanya sa simula. Una naming pinutol ang produkto, at saka lang namin naiintindihan na para gumana ang produkto, kailangan naming bantayan ang mga server at subaybayan ang mga supply. Doon nagkakaroon ng Ops. Ito ay nananatiling maunawaan na ang Ops, bilang isang hiwalay na dibisyon, ay magsisimulang maglagay ng isang grupo ng mga hadlang sa pag-unlad at ang lahat ng paghahatid ay magsisimulang matigil. Iyon ay, sa kasong ito, ang kultura ng DevOps ay may kaugnayan na, ngunit hindi natin dapat kalimutan ang tungkol sa madilim na bahagi nito.
Pinagmulan: www.habr.com