Kami sakali nyayogikeun sistem manajemén dokumén éléktronik ka palanggan di hiji fasilitas. Lajeng ka objék séjén. Sareng hiji deui. Sarta dina kaopat, sarta dina kalima. Urang meunang jadi dibawa jauh nu urang ngahontal 10 objék disebarkeun. Tétéla powerfully ... utamana lamun urang kudu delivering perobahan. Salaku bagian tina pangiriman ka sirkuit produksi, 5 skenario sistem nguji pamustunganana diperlukeun 10 jam jeung 6-7 pagawé. Waragad sapertos kitu maksakeun kami ngirim kiriman jarang-gancang. Sanggeus tilu taun operasi, urang teu tahan jeung mutuskeun pikeun bungbu nepi proyék jeung ciwit tina DevOps.
Ayeuna sadaya tés lumangsung dina 3 jam, sareng 3 jalma ilubiung dina éta: insinyur sareng dua panguji. Perbaikan anu jelas dinyatakeun dina angka sarta ngabalukarkeun pangurangan dina TTM loba-dipikacinta. Dina pangalaman urang, aya langkung seueur palanggan anu tiasa nyandak kauntungan tina DevOps tibatan anu terang ngeunaan éta. Ku alatan éta, pikeun ngadeukeutkeun DevOps ka jalma, kami parantos ngembangkeun konstruktor saderhana, anu bakal urang bahas langkung rinci dina tulisan ieu.
Ayeuna hayu urang ngabejaan Anjeun leuwih jéntré. Hiji perusahaan énergi nyebarkeun sistem manajemén dokumén téknis di 10 fasilitas ageung. Henteu gampang pikeun nganapigasi proyék-proyék skala ieu tanpa DevOps, sabab sabagian ageung tenaga kerja manual pisan ngalambatkeun padamelan sareng ogé ngirangan kualitas - sadaya padamelan manual pinuh ku kasalahan. Di sisi séjén, aya proyék dimana aya ngan hiji instalasi, tapi sagalana perlu jalan otomatis, terus jeung tanpa gagal - contona, sistem aliran dokumen sarua dina organisasi monolithic badag. Upami teu kitu, batur bakal nyieun setélan sacara manual, poho ngeunaan parentah deployment - sarta salaku hasilna, dina produksi setelan bakal leungit tur sagalana bakal ambruk.
Biasana urang damel sareng nasabah ngalangkungan kontrak, sareng dina hal ieu kapentingan urang rada diverge. Konsumén ningali proyék sacara ketat dina anggaran sareng spésifikasi téknis. Éta tiasa sesah ngajelaskeun ka anjeunna mangpaat tina sababaraha prakték DevOps anu henteu kalebet dina spésifikasi téknis. Kumaha upami anjeunna kabetot dina sékrési gancang kalayan nilai bisnis tambihan, atanapi ngawangun jalur pipa otomatis?
Hanjakalna, nalika damel sareng biaya anu tos disatujuan, minat ieu henteu salawasna kapendak. Dina prakték urang, aya hiji pasualan nalika urang kudu nyokot ngembangkeun hiji kontraktor teu sopan tur cuek. Éta pikareueuseun: teu aya kodeu sumber anu énggal, dasar kode sistem anu sami béda dina pamasangan anu béda, dokuméntasi sawaréh henteu aya, sareng sawaréh kualitasna pikareueuseun. Tangtosna, palanggan henteu gaduh kontrol kana kode sumber, assembly, release, jsb.
Sajauh ieu, teu sadaya jelema weruh ngeunaan DevOps, tapi pas urang ngobrol ngeunaan kaunggulan na, ngeunaan tabungan sumberdaya nyata, panon sadaya konsumén caang. Janten jumlah pamundut anu kalebet DevOps naék kana waktosna. Di dieu, pikeun gampang nyarios basa anu sami sareng para nasabah, urang kedah gancang nyambungkeun masalah bisnis sareng prakték DevOps anu bakal ngabantosan ngawangun pipa pangembangan anu cocog.
Janten, urang gaduh set masalah dina hiji sisi, urang gaduh pangaweruh DevOps, prakték sareng alat di sisi anu sanés. Naha henteu babagi pangalaman jeung dulur?
Nyiptakeun konstruktor DevOps
Tangkas boga manifesto sorangan. ITIL gaduh metodologi sorangan. DevOps kurang untung - éta henteu acan ngagaduhan témplat sareng standar. Sanajan nangtukeun kematangan pausahaan dumasar kana hiji assessment tina ngembangkeun sarta prakték operasional maranéhanana.
Untungna, pausahaan kawentar Gartner di 2014 sareng nganalisis prakték DevOps konci sareng hubungan antara aranjeunna. Dumasar ieu, kuring ngaluarkeun infographic:
Kami nyandak éta salaku dasar pikeun kami . Masing-masing tina opat daérah ngagaduhan sakumpulan alat - kami kumpulkeun kana pangkalan data, ngaidentipikasi anu pang populerna, ngaidentipikasi titik integrasi sareng mékanisme optimasi anu cocog. Total tétéla 36 prakték sareng 115 alat, saparapatna nyaéta open source atanapi parangkat lunak gratis. Salajengna, urang bakal ngobrol ngeunaan naon geus kami kahontal di unggal wewengkon sarta, salaku conto, ngeunaan kumaha ieu dilaksanakeun dina proyék pikeun nyieun manajemén dokumén teknis, jeung nu urang ngamimitian pos.
Proses dina prosés
Dina proyék EDMS notorious, sistem manajemen dokuméntasi teknis ieu deployed nurutkeun skéma sarua dina unggal 10 objék. Pamasanganna kalebet 4 server: server database, server aplikasi, indéks téks lengkep sareng manajemén eusi. Dina pamasangan, aranjeunna beroperasi dina hiji titik sareng ayana di pusat data di fasilitas. Sadaya objék rada béda dina infrastruktur, tapi ieu henteu ngaganggu interaksi global.
Kahiji, nurutkeun prakték DevOps, urang ngajadikeun otomatis infrastruktur lokal, lajeng kami mawa pangiriman ka sirkuit test, lajeng ka produk customer urang. Unggal prosés digarap step by step. Setélan lingkungan dibenerkeun dina sistem kode sumber, kalayan ngitung kit distribusi anu disusun pikeun ngamutahirkeun otomatis. Dina hal parobihan konfigurasi, insinyur ngan ukur kedah ngadamel parobihan anu pas kana sistem kontrol versi - teras pembaruan otomatis bakal dilaksanakeun tanpa masalah.
Hatur nuhun kana pendekatan ieu, prosés tés parantos disederhanakeun pisan. Sateuacanna, proyék éta ngagaduhan panguji anu henteu ngalakukeun nanaon tapi sacara manual ngamutahirkeun lapak. Ayeuna aranjeunna sumping, ningali yén sadayana berpungsi sareng ngalakukeun hal anu langkung mangpaat. Unggal apdet diuji sacara otomatis - ti tingkat permukaan ka otomatisasi skenario bisnis. Hasilna dipasang salaku laporan anu misah dina TestRail.
kabudayaan
Percobaan kontinyu pangalusna dipedar ngaliwatan conto desain tés. Nguji sistem anu teu acan aya mangrupikeun karya kreatif. Nalika nyerat rencana tés, anjeun kedah ngartos kumaha cara nguji anu leres sareng cabang mana anu kedah diturutan. Sarta ogé manggihan kasaimbangan antara waktu jeung anggaran pikeun nangtukeun jumlah optimal cék. Penting pikeun milih persis tés anu diperyogikeun, pikirkeun kumaha pangguna bakal berinteraksi sareng sistem, tumut kana lingkungan sareng kamungkinan faktor éksternal. Teu mungkin mun ngalakukeun tanpa experimentation kontinyu.
Ayeuna ngeunaan budaya interaksi. Saméméhna, aya dua sisi lawan - insinyur sarta pamekar. Pamekar nyarios: "Kami henteu paduli kumaha éta bakal diluncurkeun. Anjeun insinyur, anjeun pinter, pastikeun yén éta beroperasi tanpa gagal ". Para insinyur ngawaler: "Anjeun pamekar teuing cuek. Hayu urang jadi leuwih ati, sarta kami bakal maén kaluaran anjeun kirang sering. Kusabab unggal waktos anjeun masihan kami kode bocor, éta henteu jelas kumaha urang kedah berinteraksi.. Ieu mangrupikeun masalah interaksi budaya anu terstruktur béda ti sudut pandang DevOps. Di dieu, insinyur sareng pamekar mangrupikeun bagian tina tim tunggal anu museurkeun kana terus-terusan robih, tapi dina waktos anu sami parangkat lunak anu tiasa dipercaya.
Dina tim anu sarua, spesialis ditangtukeun pikeun mantuan unggal lianna. Salaku éta saméméhna? Contona, sababaraha parentah deployment kandel keur disiapkeun, ngeunaan kaca panjangna 50. Insinyur nu maca eta, teu ngarti hiji hal, dilaknat sarta nanya pamekar jam tilu isuk-isuk pikeun mairan. Pamekar commented sarta ogé dilaknat - tungtungna taya sahijieun senang. Tambih Deui, sacara alami, aya sababaraha kasalahan, sabab anjeun teu tiasa nginget sadayana dina petunjuk. Sareng ayeuna insinyur, sareng pamekar, nyerat naskah pikeun panyebaran otomatis infrastruktur parangkat lunak aplikasi. Jeung maranéhna nyarita ka silih praktis dina basa anu sarua.
jelema
Ukuran tim ditangtukeun ku ruang lingkup update. Tim direkrut nalika formasi pangiriman; éta kalebet jalma anu kabetot ti tim proyék umum. Lajeng rencana update ditulis kalayan maranéhanana jawab unggal tahapan, sarta tim ngalaporkeun sakumaha eta progresses. Sadaya anggota tim tiasa ditukeurkeun. Salaku bagian tina tim, urang ogé boga pamekar cadangan, tapi anjeunna ampir pernah kudu nyambungkeun.
téknologi
Dina diagram téknologi, sababaraha titik disorot, tapi di handapeun éta aya sakumpulan téknologi - anjeun tiasa nyebarkeun buku sadayana kalayan déskripsina. Ku kituna urang bakal nyorot paling metot.
Infrastruktur salaku Code
Ayeuna, sigana, konsép ieu moal kaget saha waé, tapi saacanna déskripsi ngeunaan infrastruktur parantos seueur anu dipikahoyong. , lingkungan uji éta unik, aranjeunna cherished tur cherished, partikel lebu ditiup kaluar aranjeunna.
Kiwari teu aya anu sieun ékspérimén. Aya gambar dasar tina mesin virtual, jeung skenario siap-dijieun pikeun deploying lingkungan. Sadaya témplat sareng skrip disimpen dina sistem kontrol vérsi sareng énggal-énggal diropéa. Saméméhna, nalika perlu pikeun nganteurkeun pakét ka stand, gap konfigurasi mucunghul. Ayeuna anjeun ngan ukur kedah nambihan garis kana kode sumber.
Salian skrip infrastruktur sareng saluran pipa, pendekatan Dokuméntasi salaku Kode ogé dianggo pikeun dokuméntasi. Hatur nuhun kana ieu, gampang pikeun nyambungkeun jalma anyar kana proyék, ngenalkeun aranjeunna kana sistem dumasar kana fungsi anu dijelaskeun, contona, dina rencana uji, sareng ogé nganggo deui kasus uji.
pangiriman kontinyu sarta ngawaskeun
ngeunaan DevOps, urang ngobrol ngeunaan kumaha urang milih alat pikeun ngalaksanakeun pangiriman sareng ngawaskeun kontinyu. Mindeng teu perlu nulis balik nanaon - cukup ngagunakeun Aksara saméméhna ditulis, leres ngawangun integrasi antara komponén tur nyieun konsol manajemén umum. Sareng sadaya prosés tiasa diluncurkeun nganggo hiji tombol atanapi jadwal.
Dina basa Inggris aya konsép anu béda, Continuous Delivery sareng Continuous Deployment. Duanana bisa ditarjamahkeun salaku "pangiriman kontinyu", tapi dina kanyataanana aya bédana saeutik antara aranjeunna. Dina proyék kami on aliran dokumén teknis pikeun parusahaan énergi disebarkeun, rada, Pangiriman dipaké - nalika instalasi keur produksi lumangsung dina paréntah. Dina Deployment, pamasangan lumangsung sacara otomatis. Pangiriman kontinyu dina proyék ieu umumna janten bagian sentral tina DevOps.
Sacara umum, ku cara ngumpulkeun parameter anu tangtu, anjeun tiasa jelas ngartos naha prakték DevOps mangpaat. Sarta nepikeun ieu ka manajemén, anu bener mikanyaah angka. Jumlah total peluncuran, waktos palaksanaan tahapan naskah, pangsa peluncuran anu suksés - sadayana ieu langsung mangaruhan waktos karesep sadayana ka pasar, nyaéta, waktos ti komitmen ka sistem kontrol versi dugi ka sékrési versi dina a lingkungan produksi. Kalayan palaksanaan alat anu diperyogikeun, insinyur nampi indikator anu berharga ku mail, sareng manajer proyék ningali aranjeunna dina dasbor. Ku cara ieu anjeun tiasa langsung ngévaluasi mangpaat alat-alat énggal. Sareng anjeun tiasa nyobian aranjeunna dina infrastruktur anjeun nganggo desainer DevOps.
Anu bakal butuh urang ?
Hayu urang ulah pura-pura: pikeun ngamimitian, anjeunna janten mangpaat pikeun urang. Sakumaha anu parantos kami nyarios, anjeun kedah nyarios basa anu sami sareng palanggan, sareng kalayan bantosan desainer DevOps urang tiasa gancang ngagambar dasar pikeun paguneman sapertos kitu. Spesialis bisnis bakal tiasa meunteun pikeun diri naon anu diperyogikeun ku kituna ngembangkeun langkung gancang. Kami nyobian ngadamel desainer salaku detil sabisa, nambihan sakumpulan déskripsi supados pangguna ngartos naon anu anjeunna pilih.
Format desainer ngamungkinkeun anjeun pikeun tumut kana kamajuan perusahaan anu aya dina prosés ngawangun sareng automation. Henteu kedah ngarusak sadayana sareng ngawangun deui upami anjeun ngan ukur tiasa milih solusi anu ngahijikeun saé sareng prosés anu aya sareng anu ngan saukur tiasa ngeusian jurang.
Panginten pamekaran anjeun parantos ngalih ka tingkat anu langkung luhur sareng alat kami sigana ogé "kaptén". Tapi urang manggihan eta mangpaat pikeun diri urang jeung miharep éta bakal mangpaat pikeun sababaraha pamiarsa. Urang ngingetan ka desainer - lamun nanaon, anjeun nampi diagram langsung saatos ngasupkeun data awal. Kami bakal nganuhunkeun pikeun eupan balik anjeun sareng tambihan.
sumber: www.habr.com