Aku bubar nekani DevOpsForum 2019, sing dianakake dening Logrocon. Ing konferensi iki, para peserta nyoba golek solusi lan alat anyar kanggo interaksi efektif antarane bisnis lan pangembangan lan spesialis layanan teknologi informasi.
Konferensi kasebut sukses: ana akeh laporan sing migunani, format presentasi sing menarik lan akeh komunikasi karo pamicara. Lan iku utamané penting sing ora ana siji nyoba kanggo ngedol kula apa-apa, soko sing speaker ing konferensi gedhe wis guilty saka akhir-akhir iki.
Kutipan saka pidato Raiffeisenbank, Alfastrakhovanie, pengalaman Mango Telecom ing ngleksanakake otomatisasi lan rincian liyane ing potongan kasebut.
Jenengku Yana, aku kerja dadi tester, aku nindakake otomatisasi, uga DevOps, lan aku seneng melu konferensi lan rapat. Sajrone rong taun kepungkur, aku wis menyang konferensi Oleg Bunin (HighLoad ++, TeamLead Conf), acara Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Kaping pisanan, aku narik kawigaten marang program konferensi. Aku katon kurang ing apa laporan bakal bab, lan liyane ing speaker. Sanajan laporan kasebut dadi teknologi banget lan menarik, dudu kasunyatan manawa sampeyan bakal bisa ngetrapake sawetara praktik paling apik saka laporan ing perusahaan sampeyan. Banjur sampeyan butuh speaker.
Cahya ing mburi pipa ing Raiffeisenbank
Biasane, aku mburu speaker ing sela-sela sing narik minat aku. Ing DevOpsForum 2019, pamicara saka Raiffeisenbank, Mikhail Bizhan, narik kawigatenku. Sajrone pidato kasebut, dheweke ngomong babagan kepiye tim bisa kecanthol ing DevOps, kenapa dheweke butuh, lan kepiye adol ide transformasi DevOps menyang bisnis. Inggih, umume, aku ngomong babagan carane ndeleng cahya ing mburi pipa.
Mikhail Bizhan, direktur otomatisasi ing Raiffeisenbank
Saiki dheweke ora duwe "DevOps" ing perusahaane. Yaiku, dheweke kerja, nanging ora ing kabeh tim. Nalika ngetrapake DevOps, dheweke ngandelake kesiapan tim, ing babagan insinyur khusus, lan babagan kabutuhan produk lan kedewasaan platform sing digawe produk iki. Misha ngandhani carane nerangake bisnis kenapa DevOps dibutuhake.
Segmen perbankan duwe sawetara pembalap pertumbuhan: biaya layanan lan ekspansi basis klien. Nambah biaya layanan ora dadi pembalap sing apik, nanging nambah basis klien yaiku sebaliknya. Yen saingan ngeculake produk sing apik banget, kabeh pelanggan menyang kana, banjur tingkat pasar metu. Mulane, ngenalake produk anyar menyang pasar lan kacepetan introduksi minangka perkara utama sing fokus ing bank. Iki persis kanggo DevOps, lan bisnis ngerti iki.
Cathetan penting sabanjure: DevOps ora mesthi nyuda wektu menyang pasar. DevOps ora bisa mlaku dhewe, mung minangka bagean saka proses nggawe lan nggawa produk menyang pasar saka pangembangan menyang produksi (saka kode menyang pelanggan). Nanging kabeh sadurunge kode kasebut ora ana hubungane langsung karo DevOps. Tegese, para pemasar bisa nyinaoni pasar nganti pirang-pirang taun lan nglampahi kabeh uripe karo pesaing. Sampeyan kudu ngerti kanthi cepet apa sing dibutuhake klien lan ngrancang implementasine fitur iki utawa kasebut - asring iki sing ora cukup kanggo DevOps bisa digunakake lan perusahaan bisa nggayuh tujuane. Mulane, pisanan, Raiffeisenbank sarujuk karo bisnis sing perlu kanggo sinau carane nggunakake DevOps. Otomasi kanggo otomatisasi ora bakal mbantu akeh ing perang kanggo pelanggan anyar.
Umumé, Misha percaya yen DevOps kudu ditindakake, nanging kanthi wicaksana. Lan kita kudu disiapake kanggo kasunyatan sing ing wiwitan transformasi produktivitas tim bakal mudhun, bakal entuk dhuwit kurang, nanging banjur bakal sabdho.
Otomasi tes ing Mango Telecom
Laporan liyane sing menarik kanggo kula minangka tester diwenehake dening Egor Maslov saka Mango Telecom. Presentasi kasebut diarani "Otomasi siklus tes lengkap ing tim SCRUM." Egor percaya yen DevOps digawe khusus kanggo SCRUM, nanging ing wektu sing padha, ngenalake DevOps dadi tim SCRUM cukup masalah. Iki kedadeyan amarga tim SCRUM tansah mlaku ing endi wae, ora ana wektu kanggo diganggu dening inovasi lan mbangun maneh proses kasebut. Masalahe uga ana ing kasunyatan manawa SCRUM ora nglibatake pemisahan sub-tim ing tim (tim testing, tim pangembangan, lan liya-liyane). Kajaba iku, kanggo ngotomatisasi proses sing ana, dokumentasi dibutuhake, lan ing SCRUM, paling asring ora ana dokumentasi lengkap - "produk luwih penting tinimbang sawetara jinis tulisan."
Sawise ngalih menyang SCRUM, penguji wiwit takon karo pangembang babagan cara nguji fitur. Mboko sithik, volume fungsi tambah, ora ana dokumentasi, lan padha wiwit nyekel akeh kewan omo ing fungsi sing ora dijamin dening tes lan ing umum iku ora cetha maneh sing dites lan nalika. Ing ringkesan - kebingungan lan kebingungan. Kita mutusake kanggo ngalih menyang tes otomatisasi. Nanging malah banjur ana gagal lengkap. Dheweke nyewa spesialis otomatisasi outsourcing sing nulis ing tumpukan sing ora dingerteni kanggo penguji ing omah. Framework kanggo autotests makarya, mesthi, nanging sawise outsourcing ninggalake, iku langgeng kanggo rong minggu. Sabanjure ana upaya kanggo ngenalake autotesting nomer loro. Diwiwiti kanthi kasunyatan manawa kabeh kudu dibangun ing perusahaan, dhewe (vektor tengen: mbangun keahlian internal), ing kerangka SCRUM, lan nggawe dokumentasi ing proses kasebut. Tumpukan kanggo otomatisasi kudu padha karo tumpukan produk (kene aku nambahake, aja nyoba proyek JavaScript sampeyan karo apa wae). Ing pungkasan sprint, dheweke nindakake demo babagan cara autotest bisa digunakake karo kabeh tim (mbantu). Mangkono, keterlibatan kabeh anggota tim ing proses otomatisasi tambah, uga kapercayan ing tes otomatis lan kemungkinan tes otomatis iki bakal digunakake (lan ora bakal dikomentari sajrone sasi amarga gagal tetep).
Miturut cara, ing DevOpsForum 2019 ana mikropon sing mbukak - sing wis suwe dikenal lan, miturut pendapatku, format pidato sing migunani. Sampeyan mlaku-mlaku kaya mangkene, ngrungokake laporan, banjur mutusake yen ing konferensi kasebut kudu ngrembug topik utawa masalah tartamtu, nuduhake pengalaman sing relevan kanggo ngrampungake masalah kasebut.
Aku uga ngerteni manawa panitia nggawe laporan singkat. Saben laporan ora luwih saka 10 menit, disusul pitakon. Kanthi cara iki sampeyan bisa nutupi akeh topik sekaligus lan takon marang pamicara sing sampeyan minati.
Ing antarane presentasi, aku mlaku-mlaku ngubengi stan para mitra konferensi lan nyolong / menang akeh barang. Eh, aku seneng handout!
Meja bunder lan masalah DevOps karo direktur pangembangan ing Alfastrakhovanie
Icing ing kue DevOpsForum 2019 kanggo aku yaiku sesi pleno suwene jam karo ahli DevOps. Papat peserta sesi diundang kanggo ndeleng DevOps saka macem-macem sudut: Anton Isanin (Alfastrakhovanie, direktur pembangunan), Nailya Zamashkina (Fintech Lab, direktur operasi), Oleg Egorkin (Rostelecom, pelatih Agile) lan Anton Martyanov (ahli independen, nyawang DevOps). saka sudut pandang bisnis).
Para ahli njagong nyedhaki wong-wong mau banjur kedadeyan: sejam, peserta saka pamirsa takon, lan para ahli njupuk rap. Kadhangkala ana debat nyata. Pitakonan kasebut beda banget, contone: apa insinyur DevOps dibutuhake, kenapa ora bisa dilatih minangka administrator sistem, yen DevOps ditawakake kanggo kabeh wong, apa regane, lan liya-liyane.
Banjur, aku ngobrol karo Anton Isanin kanthi pribadi. Kita ngrembug babagan kabutuhan nggawa budaya DevOps menyang saben omah lan mbukak sisih peteng transformasi DevOps.
Bayangake yen kabeh wong ngumpul lan mutusake manawa DevOps dibutuhake dening produk lan bisnis lan tim. Ayo padha ngleksanakake. Kabeh bisa. We exhaled. DevOps wis nggawa kita nyedhaki klien, saiki kita bisa cepet nepaki kabeh kepinginan. Akibaté, kita duwe departemen Ops gedhe karo angger-angger ketat lan syarat, lan terus-terusan nemokake cacat ing produk lan nggawe Bunch saka panjalukan. Kajaba iku, kabeh cacat diwenehi status "urgent", sanajan klien ora sengaja pengin warna tombol kuning tinimbang ijo. Proyèk iki saya akeh, jumlah rilis saya tambah lan, kanthi mangkono, jumlah cacat lan salah pangerten saka fungsi anyar dening klien. Ops nyewa 10 wong liyane kanggo nglaporake cacat, lan pembangunan nyewa 15 liyane supaya bisa nutup. Lan tinimbang ngenalake fitur-fitur anyar, tim nggarap SD tanpa wates, nerangake fungsi kasebut menyang pangguna lan dhukungan bebarengan. Akibaté, Ops lan pangembangan bisa digunakake, nanging klien lan bisnis ora seneng: fitur anyar macet. Pranyata DevOps katon ana, nanging ora ana.
Babagan kabutuhan kanggo ngetrapake DevOps, Anton kanthi jelas nyatakake yen iki langsung gumantung saka skala bisnis. Yen nglayani siji klien saben taun nggawa perusahaan milyar, DevOps ora dibutuhake (yen sampeyan ora perlu ngowahi owah-owahan anyar menyang klien iki kanthi rutin). Kabeh ditutupi coklat. Nanging yen bisnis tuwuh lan luwih akeh klien katon, mula sampeyan kudu tundhuk. Minangka aturan, ora ana Ops keren ing perusahaan ing wiwitan. Kaping pisanan, kita ngethok produk kasebut, banjur kita ngerti manawa supaya produk kasebut bisa digunakake, kita kudu ngawasi server lan ngawasi pasokan. Nalika iku Ops dumadi. Perlu dimangerteni manawa Ops, minangka divisi sing kapisah, bakal miwiti nggawe akeh alangan kanggo pangembangan lan kabeh kiriman bakal mandheg. Yaiku, ing kasus iki, budaya DevOps wis relevan, nanging kita ora kudu lali babagan sisih peteng.
Source: www.habr.com