Ez vê dawiyê beşdarî DevOpsForum 2019 bûm, ku ji hêla Logrocon ve hatî mêvandar kirin. Di vê konferansê de, beşdaran hewl dan ku çareserî û amûrên nû ji bo danûstendina bi bandor di navbera karsaz û pêşkeftin û pisporên karûbarê teknolojiya agahdariyê de bibînin.
Konferans serketî bû: bi rastî gelek raporên bikêrhatî, formên pêşkêşkirina balkêş û gelek danûstandin bi axaftvanan re hebûn. Û bi taybetî girîng e ku kes hewl neda ku tiştek ji min re bifroşe, tiştek ku axaftvanên konferansên mezin di van demên dawî de sûcdar in.
Parçeyek ji axaftinên Raiffeisenbank, Alfastrakhovanie, ezmûna Mango Telecom di pêkanîna otomasyonê de û hûrguliyên din ên di bin qutbûnê de.
Navê min Yana ye, ez wekî ceribandinek dixebitim, ez otomasyonê dikim, û hem jî DevOps, û ez hez dikim biçim konferans û civînan. Di van du salên çûyî de, ez li konferansên Oleg Bunin (HighLoad ++, TeamLead Conf), bûyerên Jug (Heisenbug, JPoint), TestCon Moskow, DevOps Pro Moskow, Big Data Moskow bûm.
Berî her tiştî ez balê dikişînim ser bernameya konferansê. Ez kêm li ser çi rapor dê li ser be, û bêtir li axaftvan dinêrim. Her çend rapor pir teknolojîk û balkêş derkeve jî, ne rastiyek e ku hûn ê bikaribin hin pratîkên çêtirîn ên raporê di pargîdaniya xwe de bicîh bikin. Û paşê hûn hewceyê axaftvanek.
Ronahî li dawiya boriyê li Raiffeisenbank
Bi gelemperî, ez li ser axaftvanên ku ji min re eleqedar dibin digerin. Li DevOpsForum 2019, axaftvanek ji Raiffeisenbank, Mikhail Bizhan, bala min kişand. Di dema axaftina xwe de, wî behsa wê yekê kir ku ew çawa hêdî hêdî tîmên xwe bi DevOps ve girêdidin, çima hewcedariya wan bi wê heye, û meriv çawa ramana veguherîna DevOps bi karsaziyê difiroşe. Welê, bi gelemperî, min li ser ku meriv çawa ronahiyê di dawiya boriyê de dibîne axivî.
Mikhail Bizhan, rêveberê otomasyonê li Raiffeisenbank
Naha di pargîdaniya wan de "DevOps" tune. Yanî ew kar dike, lê ne di hemû tîman de. Dema ku DevOps bicîh dikin, ew hem di warê endezyarên taybetî de, hem jî di warê hewcedariya hilber û mezinbûna platforma ku ev hilber li ser tê çêkirin, xwe dispêrin amadebûna tîmê. Misha got ka meriv çawa ji karsaziyek re rave dike ka çima DevOps hewce ye.
Di beşa bankingê de çend ajokarên mezinbûnê hene: lêçûna karûbar û berfirehkirina bingeha xerîdar. Zêdekirina lêçûna karûbaran ne ajokerek pir baş e, lê mezinbûna bingeha xerîdar berevajî ye. Ger hevrik hilberek bêkêmasî ya xweş derxînin, hemî xerîdar diçin wir, wê hingê bi demê re sûk asta xwe bilind dike. Ji ber vê yekê danasîna berhemên nû bo bazarê û leza danasîna wan tişta sereke ye ku bank li ser disekine. Ya ku DevOps ji bo vê yekê ye, û karsazî vê yekê fêm dikin.
Nîşeya girîng a din: DevOps her gav wextê bazarê kêm nake. DevOps nekare bi tenê bixebite, ew tenê beşek ji pêvajoya afirandin û anîna hilberek ji pêşkeftinê heya hilberînê (ji kodê heya xerîdar) ye. Lê her tiştê berî kodê rasterast bi DevOps ve ne girêdayî ye. Ango, bazarkar dikarin bi salan li sûkê lêkolîn bikin û tevahiya jiyana xwe bi hevrikan re derbas bikin. Pêdivî ye ku meriv zû fam bike ka xerîdar çi hewce dike û plansazkirina pêkanîna vê an wê taybetmendiyê - pir caran ev e ya ku ne bes e ku DevOps bixebite û pargîdanî bigihîje armanca xwe. Ji ber vê yekê, berî her tiştî, Raiffeisenbank bi karsaziyê re li hev kir ku pêdivî ye ku meriv fêr bibe ka meriv çawa DevOps bikar tîne. Otomasyon ji bo xweseriyê dê di şerê xerîdarên nû de pir alîkar neke.
Bi gelemperî, Misha bawer dike ku DevOps pêdivî ye ku were bicîh kirin, lê bi aqilmendî. Û divê em ji vê rastiyê re amade bin ku di destpêka veguherînê de dê hilberîna tîmê dakeve, ew ê kêmtir drav qezenc bike, lê paşê ew ê rastdar be.
Otomasyona ceribandinê li Mango Telecom
Raporek din a balkêş ji bo min wekî ceribandinek ji hêla Egor Maslov ji Mango Telecom ve hat dayîn. Pêşniyar bi navê "Xweseriya çerxa ceribandinê ya tevahî di tîmek SCRUM de." Egor bawer dike ku DevOps bi taybetî ji bo SCRUM hate afirandin, lê di heman demê de, danasîna DevOps di tîmek SCRUM de pir pirsgirêk e. Ev diqewime ji ber ku tîmê SCRUM her gav li deverek dimeşîne, wext tune ku meriv ji nûbûnên ve mijûl bibe û pêvajoyê ji nû ve ava bike. Pirsgirêk jî di vê rastiyê de ye ku SCRUM di tîmê de veqetandina jêr-tîmê (tîmê ceribandinê, tîmê pêşkeftinê, û hwd.) venagire. Welê, ji bilî vê yekê, ji bo otomatîkkirina pêvajoyek heyî, belgekirin hewce ye, û di SCRUM de, pir caran belgeyek bi tevahî tune - "hilber ji cûreyek nivîsandinê girîngtir e."
Piştî guheztina SCRUM, ceribandinvanan dest bi şêwirdariyê bi pêşdebiran re kirin ka meriv çawa taybetmendiyan ceribandine. Hêdî hêdî, qebareya fonksiyonê zêde bû, tu belgeyek tune bû, û wan dest pê kir ku di fonksiyona ku ji hêla ceribandinan ve nehatibû vegirtin û bi gelemperî ne diyar bû ku kê û kengê ew ceriband. Bi kurtî - tevlihevî û bêhêvî. Me biryar da ku em derbasî ceribandina otomatîkê bibin. Lê wê demê jî bi temamî têkçûnek hebû. Wan pisporên otomasyonê yên derveyî yên ku li ser stûnek ku ji ceribandinên hundurîn re nenas dinivîsandin kir. Çarçoveya testên otomatê, bê guman, xebitî, lê piştî derketina derve, ew du hefte dom kir. Dûv re hewldanek ji bo danasîna ototestkirina hejmara du bû. Ew bi vê yekê dest pê kir ku pêdivî ye ku her tişt di hundurê pargîdaniyê de, bi tena serê xwe (vektora rast: di hundurê de pisporiyê ava bikin), di çarçoveya SCRUM de, û di pêvajoyê de belgeyan biafirînin dest pê kir. Pêdivî ye ku stûna ji bo otomatê bi stûna hilberê re wekhev be (li vir ez lê zêde dikim, projeya xweya JavaScriptê bi tiştek din neceribîne). Di dawiya sprintê de, wan demoyek kir ku ka ototest bi tevahî tîmê re çawa dixebite (alîkar). Bi vî rengî, tevlêbûna hemî endamên tîmê di pêvajoya otomasyonê de zêde bû, û her weha pêbaweriya bi ototest û şansê ku ev ototest bê guman were bikar anîn (û dê di mehekê de ji ber têkçûnên domdar neyê şîrove kirin) zêde bû.
Bi awayê, li DevOpsForum 2019 mîkrofonek vekirî hebû - formek axaftinên dirêj-naskirî û, bi dîtina min, kêrhatî. Hûn bi vî rengî li dora xwe digerin, li raporan guhdarî dikin, û dûv re biryar didin ku di konferansê de hêja ye ku mijarek an pirsgirêkek diyarkirî nîqaş bikin, di çareserkirina pirsgirêkê de ezmûna têkildar parve bikin.
Min jî dît ku organîzatoran raporek kurt çêkir. Her rapor ji 10 hûrdeman zêdetir dom nake, li dûv wan pirsan. Bi vî awayî hûn dikarin gelek mijaran bi yekcarî veşêrin û pirsan ji axaftvanên ku we eleqedar dikin bipirsin.
Di navbera pêşkêşiyan de, ez li dor standên hevkarên konferansê geriyam û gelek tişt dizîn/qezencim. Eh, ez ji destanê hez dikim!
Maseya dor û pirsgirêkên DevOps bi derhênerê pêşkeftinê re li Alfastrakhovanie
Nîqaşa li ser kekê DevOpsForum 2019 ji bo min rûniştina plenary-saetê ya bi pisporên DevOps re bû. Çar beşdarên danişînê hatin vexwendin ku ji aliyên cihêreng li DevOps binihêrin: Anton Isanin (Alfastrakhovanie, derhênerê pêşkeftinê), Nailya Zamashkina (Fintech Lab, rêvebirê xebitandinê), Oleg Egorkin (Rostelecom, rahênerê Agile) û Anton Martyanov (pisporê serbixwe, li DevOps nêrî. ji nêrînek karsaziyê).
Pispor nêzîkî xelkê rûniştin û dûv re tişt dest pê kirin: Saetek tevahî, beşdaran ji temaşevanan pirsên xwe pirsîn, û pisporan rapê girtin. Carinan rastî nîqaşan dihatin. Pirs pir cûda bûn, mînakî: ma endezyarên DevOps bi tevahî hewce ne, çima ew nikarin wekî rêveberên pergalê werin perwerde kirin, gelo divê DevOps ji her kesî re were pêşkêş kirin, nirxa wê çi ye û hwd.
Paşê ez bi Anton Îsan re bi xwe re axivîm. Me li ser hewcedariya anîna çanda DevOps li her malê nîqaş kir û aliyê tarî yê veguherîna DevOps eşkere kir.
Ka em bifikirin ku her kes li hev civiyan û biryar da ku DevOps hem ji hêla hilber û hem jî ji hêla karsaz û tîmê ve hewce ye. Ka em herin wê bicîh bînin. Her tişt derket holê. Me hilanîn. DevOps me nêzî xerîdar kir, naha em dikarin zû hemî daxwazên wî bicîh bînin. Wekî encamek, me dezgehek mezin a Ops-ê bi rêzik û hewcedariyên hişk heye, û ew bi domdarî kêmasiyan di hilberê de dibîne û komek daxwazan diafirîne. Digel vê yekê, hemî kêmasiyan statûya "lezgîn" têne destnîşan kirin, hetta ku xerîdar ji nedîtî ve xwest ku bişkojê li şûna kesk zer bike. Proje mezin dibe, hejmara berdanan zêde dibe û, li gorî vê yekê, hejmara kêmasî û têgihîştina fonksiyonên nû ji hêla xerîdaran ve. Ops 10 kesên din dixebitîne da ku bi kêmasiyên ragihandinê re bidome, û pêşkeftin 15 kesên din jî kar dike da ku bi girtina wan re bidome. Û li şûna danasîna taybetmendiyên nû, tîmê bi SD-yên bêdawî re dixebite, fonksiyonê ji bikarhêner re rave dike û di heman demê de piştgirî dike. Wekî encamek, hem Ops û hem jî pêşkeftin dixebitin, lê xerîdar û karsaz nerazî ne: taybetmendiyên nû diqewimin. Derket holê ku DevOps xuya dike ku heye, lê ew xuya nake.
Di derbarê hewcedariya pêkanîna DevOps de, Anton bi eşkere diyar kir ku ev rasterast bi pîvana karsaziyê ve girêdayî ye. Ger salek xizmetkirina yek xerîdar ji pargîdanî re mîlyarek tîne, DevOps ne hewce ye (bi şertê ku hûn ne hewce ne ku hûn bi rêkûpêk guhertinên nû li ser vê xerîdar bixin). Her tişt bi çikolata ve girêdayî ye. Lê heke karsazî mezin bibe û bêtir xerîdar xuya bibin, wê hingê hûn hewce ne ku tevbigerin. Wekî qaîdeyek, di destpêkê de di pargîdaniyê de Opsên xweş tune. Pêşî em hilberê qut dikin, û tenê wê hingê em fam dikin ku ji bo ku hilber kar bike, pêdivî ye ku em çavê xwe li serveran bigirin û çavdêriya peyda bikin. Wê demê Ops derdikeve holê. Dimîne ku were fêm kirin ku Ops, wekî dabeşek cihêreng, dê dest bi danîna komek astengan li pêşkeftinê bike û hemî radestkirin dê dest pê bikin. Ango, di vê rewşê de, çanda DevOps jixwe têkildar e, lê divê em aliyên wê yên tarî ji bîr nekin.
Source: www.habr.com