Kita tau nyedhiyakake sistem manajemen dokumen elektronik menyang pelanggan ing salah sawijining fasilitas. Lan banjur menyang obyek liyane. Lan siji maneh. Lan ing kaping papat, lan ing kaping lima. Kita entuk banget nganti tekan 10 obyek sing disebarake. Ternyata kanthi kuat ... utamane nalika ngirim owah-owahan. Minangka bagéan saka pangiriman menyang sirkuit produksi, 5 skenario saka sistem testing wekasanipun mbutuhake 10 jam lan 6-7 karyawan. Biaya kasebut meksa kita ngirim kiriman kanthi arang banget. Sawise telung taun operasi, kita ora bisa tahan lan mutusake kanggo nggawe proyek kasebut kanthi jiwit DevOps.
Saiki kabeh tes ditindakake sajrone 3 jam, lan 3 wong melu: insinyur lan loro penguji. Dandan kasebut kanthi jelas ditulis ing nomer lan nyebabake nyuda TTM sing ditresnani. Ing pengalaman kita, ana luwih akeh pelanggan sing bisa entuk manfaat saka DevOps tinimbang sing ngerti babagan iki. Mulane, kanggo nggawa DevOps luwih cedhak karo wong, kita wis ngembangake konstruktor sing prasaja, sing bakal dibahas kanthi luwih rinci ing kiriman iki.
Saiki ayo ngomong kanthi luwih rinci. Siji perusahaan energi nyebarake sistem manajemen dokumen teknis ing 10 fasilitas gedhe. Ora gampang navigasi proyek skala iki tanpa DevOps, amarga bagean gedhe saka tenaga kerja manual banget tundha karya lan uga nyuda kualitas - kabeh karya manual kebak kesalahan. Ing sisih liya, ana proyek sing mung ana siji instalasi, nanging kabeh kudu bisa kanthi otomatis, terus-terusan lan tanpa gagal - contone, sistem aliran dokumen sing padha ing organisasi monolitik gedhe. Yen ora, wong bakal nggawe setelan kanthi manual, lali babagan instruksi panyebaran - lan minangka asil, ing produksi setelan bakal ilang lan kabeh bakal ambruk.
Biasane kita kerja bareng karo pelanggan liwat kontrak, lan ing kasus iki kapentingan kita rada beda. Pelanggan katon ing proyek kasebut kanthi ketat ing anggaran lan spesifikasi teknis. Bisa uga angel kanggo nerangake babagan mupangat saka macem-macem praktik DevOps sing ora kalebu ing spesifikasi teknis. Apa yen dheweke kasengsem ing rilis cepet kanthi nilai bisnis sing ditambahake, utawa mbangun pipa otomatis?
Sayange, nalika nggarap biaya sing wis disetujoni, kapentingan iki ora tansah ditemokake. Ing laku kita, ana kasus nalika kita kudu njupuk pembangunan kontraktor unscrupulous lan careless. Pancen elek: ora ana kode sumber sing paling anyar, basis kode sistem sing padha beda-beda ing instalasi sing beda-beda, dokumentasi sebagian ora ana, lan sebagian kualitase elek. Mesthine, pelanggan ora bisa ngontrol kode sumber, perakitan, rilis, lsp.
Nganti saiki, ora kabeh wong ngerti babagan DevOps, nanging sanalika kita ngomong babagan kaluwihan, babagan tabungan sumber daya nyata, mripate kabeh pelanggan padhang. Dadi jumlah panjaluk sing kalebu DevOps saya tambah akeh. Ing kene, supaya gampang nganggo basa sing padha karo para pelanggan, kita kudu cepet nyambungake masalah bisnis lan praktik DevOps sing bakal mbantu mbangun pipa pangembangan sing cocog.
Dadi, kita duwe sawetara masalah ing sisih siji, kita duwe kawruh, praktik lan alat DevOps ing sisih liyane. Apa ora nuduhake pengalaman karo kabeh wong?
Nggawe konstruktor DevOps
Agile duwe manifesto dhewe. ITIL duwe metodologi dhewe. DevOps kurang beruntung - durung entuk template lan standar. sanadyan nemtokake kadewasan perusahaan adhedhasar evaluasi pangembangan lan praktik operasional.
Untunge, perusahaan kondhang Gartner ing 2014 lan nganalisa praktik DevOps utama lan hubungane. Adhedhasar iki, aku nerbitake infographic:
We njupuk minangka basis kanggo kita . Saben patang wilayah duwe set alat - diklumpukake dadi database, ngenali sing paling populer, nemtokake titik integrasi lan mekanisme optimasi sing cocog. Secara total ternyata 36 praktik lan 115 alat, seprapat saka piranti lunak open source utawa gratis. Sabanjure, kita bakal ngomong babagan apa sing wis digayuh ing saben wilayah lan, minangka conto, babagan carane iki dileksanakake ing proyek kanggo nggawe manajemen dokumen teknis, sing diwiwiti kiriman.
Pangolahan
Ing proyek EDMS sing kondhang, sistem manajemen dokumentasi teknis disebarake miturut skema sing padha ing saben obyek 10. Instalasi kalebu 4 server: server database, server aplikasi, indeksasi teks lengkap lan manajemen konten. Ing instalasi, padha operate ing siji simpul lan dumunung ing pusat data ing fasilitas. Kabeh obyek rada beda ing infrastruktur, nanging iki ora ngganggu interaksi global.
Pisanan, miturut praktik DevOps, kita ngotomatisasi infrastruktur sacara lokal, banjur dikirim menyang sirkuit uji, banjur menyang produk pelanggan. Saben proses digarap langkah demi langkah. Setelan lingkungan tetep ing sistem kode sumber, njupuk menyang akun kang kit distribusi nyawiji kanggo nganyari otomatis. Yen ana owah-owahan konfigurasi, insinyur mung kudu nggawe owah-owahan sing cocog karo sistem kontrol versi - banjur nganyari otomatis bakal ditindakake tanpa masalah.
Thanks kanggo pendekatan iki, proses tes wis disederhanakake. Sadurunge, proyek kasebut duwe panguji sing ora nindakake apa-apa nanging nganyari stands kanthi manual. Saiki dheweke mung teka, ndeleng manawa kabeh bisa digunakake lan nindakake perkara sing luwih migunani. Saben nganyari dites kanthi otomatis - saka tingkat permukaan nganti otomatisasi skenario bisnis. Asil dikirim minangka laporan kapisah ing TestRail.
Budaya
Eksperimen terus-terusan paling apik diterangake liwat conto desain tes. Nguji sistem sing durung ana yaiku karya kreatif. Nalika nulis rencana tes, sampeyan kudu ngerti cara nguji kanthi bener lan cabang sing kudu ditindakake. Lan uga golek imbangan antarane wektu lan budget kanggo nemtokake jumlah optimal mriksa. Penting kanggo milih persis tes sing dibutuhake, mikir babagan cara pangguna bakal sesambungan karo sistem, njupuk lingkungan lan faktor eksternal sing bisa ditindakake. Ora bisa ditindakake tanpa eksperimen terus-terusan.
Saiki babagan budaya interaksi. Sadurungé, ana rong pihak sing nentang - insinyur lan pangembang. Pangembang ngandika: "Kita ora peduli carane bakal diluncurake. Sampeyan insinyur, sampeyan pinter, priksa manawa bisa digunakake tanpa gagal ". Para insinyur mangsuli: "Sampeyan para pangembang banget ceroboh. Ayo dadi luwih ati-ati, lan kita bakal muter release Panjenengan kurang asring. Amarga saben-saben sampeyan menehi kode sing bocor, ora jelas kanggo kita carane sesambungan.. Iki minangka masalah interaksi budaya sing disusun kanthi beda saka perspektif DevOps. Ing kene, insinyur lan pangembang minangka bagean saka tim siji sing fokus ing owah-owahan terus-terusan, nanging piranti lunak sing bisa dipercaya.
Ing tim sing padha, spesialis ditemtokake kanggo mbantu saben liyane. Kaya sadurunge? Contone, sawetara instruksi penyebaran kandel lagi disiapake, kira-kira kaca 50. Insinyur maca, ora ngerti apa-apa, ngipat-ipati lan takon pangembang ing jam telu esuk kanggo menehi komentar. Pangembang komentar lan uga ngipat-ipati - ing pungkasan, ora ana sing seneng. Kajaba iku, mesthi ana sawetara kesalahan, amarga sampeyan ora bisa ngelingi kabeh instruksi kasebut. Lan saiki insinyur, bebarengan karo pangembang, nulis skrip kanggo panyebaran otomatis infrastruktur piranti lunak aplikasi. Lan padha ngomongake saben liyane ing basa sing padha.
wong
Ukuran tim ditemtokake dening ruang lingkup nganyari. Tim kasebut direkrut sajrone pambentukan pangiriman; kalebu sing kasengsem saka tim proyek umum. Banjur rencana nganyari ditulis karo sing tanggung jawab kanggo saben tahapan, lan laporan tim nalika maju. Kabeh anggota tim bisa diganti. Minangka bagéan saka tim, kita uga duwe gawe serep, nanging meh ora tau nyambung.
teknologi
Ing diagram teknologi, sawetara titik disorot, nanging ing ngisor iki ana akeh teknologi - sampeyan bisa nerbitake buku kanthi deskripsi. Dadi, kita bakal nyorot sing paling menarik.
Infrastruktur minangka Kode
Saiki, mesthine, konsep iki ora bakal kaget sapa wae, nanging sadurunge deskripsi infrastruktur isih akeh sing dikarepake. , lingkungan test padha unik, padha ngurmati lan ngormati, partikel bledug padha diunekake mati.
Saiki ora ana sing wedi eksperimen. Ana gambar dhasar saka mesin virtual, lan skenario siap kanggo deploying lingkungan. Kabeh cithakan lan skrip disimpen ing sistem kontrol versi lan dianyari kanthi cepet. Sadurunge, nalika perlu kanggo ngirim paket menyang stand, longkangan konfigurasi katon. Saiki sampeyan mung kudu nambah baris menyang kode sumber.
Saliyane skrip infrastruktur lan saluran pipa, pendekatan Dokumentasi minangka Kode uga digunakake kanggo dokumentasi. Thanks kanggo iki, gampang nyambungake wong anyar menyang proyek kasebut, ngenalake menyang sistem adhedhasar fungsi sing diterangake, contone, ing rencana tes, lan uga nggunakake kasus uji coba maneh.
Pangiriman lan pemantauan terus-terusan
babagan DevOps, kita ngomong babagan cara milih alat kanggo ngetrapake pangiriman lan pemantauan terus-terusan. Asring ora perlu nulis maneh - cukup nggunakake skrip sing wis ditulis sadurunge, kanthi bener mbangun integrasi antarane komponen lan nggawe konsol manajemen umum. Lan kabeh proses bisa diluncurake kanthi nggunakake siji tombol utawa jadwal.
Ing basa Inggris ana konsep sing beda, Continuous Delivery lan Continuous Deployment. Loro-lorone bisa diterjemahake minangka "pangiriman terus-terusan", nanging nyatane ana bedane tipis ing antarane. Ing project kita kanggo aliran document technical saka perusahaan energi mbagekke, rodo, Delivery digunakake - nalika instalasi kanggo produksi ana ing printah. Ing Panyebaran, instalasi dumadi kanthi otomatis. Pangiriman terus-terusan ing proyek iki umume dadi bagean tengah DevOps.
Umumé, kanthi ngumpulake paramèter tartamtu, sampeyan bisa ngerti kanthi jelas kenapa praktik DevOps migunani. Lan ngirim iki kanggo manajemen, sing pancene tresna nomer. Jumlah total peluncuran, wektu eksekusi tahapan skrip, bagean peluncuran sing sukses - kabeh iki langsung mengaruhi wektu favorit saben wong menyang pasar, yaiku, wektu saka komitmen menyang sistem kontrol versi nganti rilis versi ing a lingkungan produksi. Kanthi implementasine saka alat sing perlu, engineers nampa pratondho terkenal dening mail, lan manager project ndeleng wong ing dashboard. Kanthi cara iki sampeyan bisa langsung ngevaluasi keuntungan saka piranti anyar. Lan sampeyan bisa nyoba ing infrastruktur sampeyan nggunakake desainer DevOps.
Sapa sing butuh kita ?
Aja ndalang: kanggo wiwitan, dheweke dadi migunani kanggo kita. Kaya sing wis dakkandhakake, sampeyan kudu nganggo basa sing padha karo pelanggan, lan kanthi bantuan desainer DevOps, kita bisa nggawe sketsa dhasar kanggo obrolan kasebut. Spesialis bisnis bakal bisa netepake dhewe apa sing dibutuhake lan kanthi mangkono berkembang luwih cepet. Kita nyoba nggawe desainer kanthi rinci, nambahake akeh deskripsi supaya pangguna ngerti apa sing dipilih.
Format desainer ngidini sampeyan nganggep pangembangan perusahaan sing ana ing proses bangunan lan otomatisasi. Ora perlu nyuwek kabeh lan mbangun maneh yen sampeyan mung bisa milih solusi sing bisa nggabungake kanthi apik karo proses sing ana lan mung bisa ngisi kesenjangan.
Mbok menawa pangembangan sampeyan wis pindhah menyang tingkat sing luwih dhuwur lan alat kita bakal katon banget "kapten". Nanging kita nemokake iku migunani kanggo awake dhewe lan ngarep-arep bisa migunani kanggo sawetara sing maca. We ngelingake sampeyan kanggo desainer - yen ana, sampeyan nampa diagram sanalika sawise ngetik data dhisikan. Kita bakal ngucapke matur nuwun kanggo saran lan tambahan.
Source: www.habr.com