Laporan kasebut bakal ngomong babagan sawetara praktik DevOps, nanging saka sudut pandang pangembang. Biasane, kabeh insinyur sing gabung karo DevOps wis duwe sawetara taun pengalaman administratif ing sabuk. Nanging iki ora ateges ora ana papan kanggo pangembang ing kene. Sing luwih kerep tinimbang ora, pangembang sibuk ndandani "bug kritis sabanjure dina iki," lan ora duwe wektu kanggo ndeleng lapangan DevOps kanthi cepet. Ing pangerten penulis, DevOps, pisanan, akal sehat. Kapindho, iki minangka kesempatan kanggo luwih efektif. Yen sampeyan pangembang, duwe akal sehat lan pengin luwih efektif minangka pemain tim, laporan iki kanggo sampeyan.
Ayo kula ngenalake aku, aku ngakoni kanthi lengkap yen ana wong ing kamar sing ora ngerti aku. Jenengku Anton Boyko, aku MVP Microsoft Azure. Apa MVP? Iki Model-View-Presenter. Model-View-Presenter persis aku.
Kajaba iku, aku saiki nyekel posisi arsitek solusi ing Ciklum. Lan bubar aku tuku domain sing apik banget, lan aku nganyari email, sing biasane ditampilake ing presentasi. Sampeyan bisa nulis kanggo kula ing: kula [asu] byokoant.pro. Sampeyan bisa email kula karo pitakonan. Aku biasane mangsuli. Siji-sijine aku ora pengin nampa pitakonan liwat email sing ana hubungane karo rong topik: politik lan agama. Sampeyan bisa nulis kanggo kula babagan kabeh liyane liwat email. Sawetara wektu bakal liwat, aku bakal mangsuli.
Sawetara tembung babagan aku:
- Aku wis 10 taun ing lapangan iki.
- Aku kerja ing Microsoft.
- Aku minangka bapak pendiri komunitas Azure Ukrainia, sing diadegake ing endi wae ing 2014. Lan kita isih duwe lan ngembangake.
- Aku uga rama pangadeg konferensi Azure, kang kita hosting ing Ukraina.
- Aku uga mbantu ngatur Global Azure Bootcamp ing Kyiv.
- Kaya sing dakkandhakake, aku dadi MVP Microsoft Azure.
- Aku kerep ngomong ing konferensi. Aku seneng banget ngomong ing konferensi. Ing taun kepungkur aku bisa tampil udakara 40 kali. Yen sampeyan ngliwati Ukraina, Belarus, Polandia, Bulgaria, Swedia, Denmark, Walanda, Spanyol utawa menehi utawa njupuk negara liya ing Eropa, mula bisa uga yen sampeyan menyang konferensi sing duwe tema awan ing alirane, sampeyan bisa ndeleng kula ing dhaftar speaker.
- Aku uga penggemar Star Trek.
Ayo ngobrol sethithik babagan Agenda. Agenda kita gampang banget:
- Kita bakal ngomong babagan apa DevOps. Ayo dadi ngomong apa iki penting. Sadurunge, DevOps minangka tembung kunci sing sampeyan tulis ing resume lan langsung nampa gaji +$500. Saiki sampeyan kudu nulis, contone, blockchain ing resume supaya entuk +500 dolar kanggo gaji sampeyan.
- Banjur, yen kita ngerti sethithik babagan apa iki, kita bakal ngomong babagan praktik DevOps. Nanging ora akeh ing konteks DevOps umume, nanging babagan praktik DevOps sing bisa uga dadi kapentingan kanggo pangembang. Aku bakal pitutur marang kowe kok padha bisa dadi kapentingan kanggo sampeyan. Aku bakal ngandhani apa sebabe sampeyan kudu nindakake iki lan kepiye carane bisa nyuda rasa lara.
Gambar tradisional sing ditampilake akeh wong. Iki kedadeyan ing pirang-pirang proyek. Iki nalika kita duwe departemen pangembangan lan operasi sing ndhukung piranti lunak kita. Lan departemen iki ora komunikasi karo saben liyane.
Bisa uga, yen sampeyan ora bisa ngrasakake kanthi jelas ing departemen DevOps lan operasi, sampeyan bisa nggambar analogi karo departemen Dev lan QA. Ana wong sing ngembangake piranti lunak lan ana wong QA sing ala saka sudut pandang pangembang. Contone, aku tundhuk kode sandi apik kanggo gudang, lan ana sawetara scoundrel lungguh ana sing bali kode iki kanggo kula lan ngandika sing kode iku ala.
Iki kabeh kedaden amarga wong ora komunikasi karo saben liyane. Lan padha uncalan sawetara paket, sawetara aplikasi kanggo saben liyane liwat sawetara tembok misunderstanding lan nyoba kanggo nindakake soko karo wong-wong mau.
Iku sabenere tembok iki sing DevOps budaya dirancang kanggo numpes, i.e. meksa wong kanggo komunikasi karo saben liyane lan ing paling ngerti apa wong beda ing project apa lan apa karya sing penting.
Lan nalika kita ngomong babagan DevOps, ana sing bakal ngandhani yen DevOps yaiku nalika proyek kasebut nduweni integrasi sing terus-terusan; wong bakal ngomong yen DevOps yen proyek kasebut nindakake praktik "infrastruktur minangka kode"; ana sing bakal ujar manawa langkah pertama kanggo DevOps yaiku ngepang fitur, bendera fitur.
Ateges, iki kabeh bener kanthi cara dhewe. Nanging iki mung praktik pokok sing kita duwe. Sadurunge pindhah menyang praktik kasebut, aku saranake ndeleng slide iki, sing nuduhake 3 tahapan ngleksanakake metodologi Dev-Ops ing proyek sampeyan, ing perusahaan sampeyan.
Slide iki uga duwe jeneng ora resmi nomer loro. Sampeyan bisa nggoleki online kanggo ngerteni apa 3 Musketeers saka DevOps. Sampeyan bisa uga bakal nemokake artikel iki. Kenapa 3 Musketeers? Ing ngisor iki ngandika: wong, pangolahan lan produk, i.e. PPP - Porthos, Porthos lan Porthos. Mangkene 3 musketeers DevOps. Artikel iki njlèntrèhaké luwih rinci apa iki penting lan apa iku entails.
Nalika sampeyan miwiti ngetrapake budaya DevOps, penting banget yen dileksanakake ing urutan ing ngisor iki.
Kaping pisanan sampeyan kudu ngomong karo wong. Lan sampeyan kudu nerangake kanggo wong apa iku lan carane bisa entuk sawetara keuntungan saka iku.
Konferensi kita diarani DotNet Fest. Lan kaya sing diomongake dening panitia, utamane ngundang pamirsa para pangembang ing kene, mula aku ngarep-arep supaya akeh wong ing bale melu pembangunan.
Kita bakal ngomong babagan wong, kita bakal ngomong babagan apa sing dikarepake para pangembang saben dina. Apa sing paling dikarepake? Dheweke pengin nulis kode anyar, nggunakake kerangka kerja anyar, nggawe fitur anyar. Apa sing paling dikarepake para pangembang? Ndandani bug lawas. Muga-muga sampeyan setuju karo aku. Iki sing dikarepake para pangembang. Dheweke pengin nulis fitur anyar, dheweke ora pengin ndandani bug.
Jumlah kewan omo sing diprodhuksi dening pangembang tartamtu gumantung saka carane lengen sing lurus lan akeh sing tuwuh saka pundhake, lan ora saka kanthong bokong. Nanging, nalika kita duwe proyek gedhe, kadhangkala ora bisa nglacak kabeh, mula luwih becik nggunakake sawetara pendekatan sing bakal mbantu nulis kode sing luwih stabil lan luwih dhuwur.
Apa sing paling dikarepake QAs? Aku ora ngerti yen dheweke ana ing aula. Iku angel kanggo aku ngomong yen aku pengin QA, amarga aku ora tau dadi siji. Lan ora pelanggaran kanggo wong lanang, iku bakal ngandika sing Mugi aku ora bakal. Nanging ora amarga aku nganggep karyane ora ana gunane lan ora ana gunane, nanging amarga aku ora nganggep awake dhewe minangka wong sing bisa nindakake pakaryan iki kanthi efisien, mula aku ora bakal nyoba nindakake. Nanging saka sing dakkarepake, apa sing paling ora disenengi QA bakal ditindakake ing wayah esuk, terus-terusan nganakake tes kemunduran, mlaku ing kewan omo sing padha dilaporake menyang pangembang 3 sprint kepungkur lan ujar: "Kapan sampeyan bakal , Monsieur D 'Artagnan, ndandani bug iki.' Lan Monsieur D'Artagnan mangsuli: "Ya, ya, ya, aku wis ndandani." Lan kepiye kedadeyan aku ndandani siji bug lan nggawe 5 ing dalan.
Wong-wong sing ndhukung solusi iki ing produksi pengin solusi iki bisa tanpa kewan omo, supaya padha ora kudu urip maneh server saben ana, nalika kabeh wong normal menyang bar. Pangembang disebarake ing dina Jumuah, para admin njagong nganti dina Setu, nyoba nggawe penyebaran lan tetep.
Lan nalika nerangake wong sing padha ngarahke ing mecahaken masalah padha, sampeyan bisa nerusake kanggo formalizing pangolahan. Iku penting banget. Kenging punapa? Amarga nalika kita ngomong "formalisasi," iku penting kanggo njlèntrèhaké carane pangolahan Panjenengan kedaden ing paling nang endi wae ing napkin. Sampeyan kudu ngerti yen sampeyan, umpamane, nyebar menyang lingkungan QA utawa lingkungan produksi, mula mesthi kedadeyan ing urutan iki; ing tahap iki, kita mbukak, contone, tes unit otomatis lan tes UI. Sawise panyebaran, kita priksa manawa panyebaran kasebut apik utawa ora apik. Nanging sampeyan wis duwe dhaptar tumindak sing jelas sing kudu diulang maneh nalika sampeyan nyebarake menyang produksi.
Lan mung nalika proses sampeyan wis resmi, sampeyan miwiti milih produk sing bakal mbantu sampeyan ngotomatisasi proses kasebut.
Sayange, aku kerep ndeleng iki kedadeyan ing mbalikke. Sanalika ana wong sing krungu tembung "DevOps", dheweke langsung nyaranake nginstal Jenkins, amarga dheweke percaya yen sawise nginstal Jenkins, dheweke bakal duwe DevOps. Dheweke nginstal Jenkins, maca artikel "Carane" ing situs web Jenkins, nyoba ngolah proses menyang artikel Cara iki, banjur nemoni wong lan mbengkongake wong, ujar manawa buku kasebut ujar manawa sampeyan kudu nindakake kanthi cara iki, supaya kita nindakaken cara iki.
Iku ora yen Jenkins minangka alat sing ala. Aku ora maksud ngomong kaya ngono. Nanging iki mung salah sawijining produk. Lan produk sing sampeyan gunakake kudu dadi keputusan sing pungkasan, lan dudu sing pertama. Produk sampeyan ora kudu didorong dening implementasine budaya lan pendekatan. Iki penting banget kanggo dimangerteni, mula aku mbuwang wektu akeh ing slide iki lan nerangake kabeh iki nganti suwe.
Ayo ngobrol babagan praktik DevOps umume. Apa iku? Apa bedane? Kepiye carane nyoba? Apa sebabe penting?
Praktek pisanan sing sampeyan wis krungu diarani Integrasi Terus-terusan. Mbok menawa ana wong ing proyek kasebut duwe Integrasi Terus (CI).
Masalah paling gedhe yaiku sing paling kerep nalika aku takon marang wong: "Apa sampeyan duwe CI ing proyek kasebut?" lan ngandika: "Ya," banjur nalika aku takon apa apa, kang njlèntrèhaké kanggo kula pancen kabeh proses otomatis. Iki ora sakabehe bener.
Nyatane, praktik CI mung ngarahake nggabungake kode sing ditulis wong sing beda-beda menyang sawetara basis kode tunggal. Mekaten.
Bebarengan karo CI, biasane ana praktik liyane ing dalan - kayata Penyebaran Terus-terusan, Manajemen Rilis, nanging kita bakal ngomong babagan iki mengko.
CI dhewe ngandhani yen wong beda-beda nulis kode lan kode iki kudu terus-terusan diintegrasi dadi basis kode siji.
Apa iki menehi kita lan apa iku penting? Yen kita duwe DotNet, banjur sing apik, iku basa kompilasi, kita bisa ngumpulake aplikasi kita. Yen kompilasi, iki wis dadi tandha apik. Iki ora ateges apa-apa durung, nanging iku tandha apik pisanan sing paling bisa kita ngumpulake.
Banjur kita bisa mbukak sawetara tes, sing uga minangka praktik sing kapisah. Tes kabeh ijo - iki minangka tandha apik kaloro. Nanging maneh, iki ora ateges apa-apa.
Nanging kenapa sampeyan nindakake iki? Sedaya laku ingkang badhe kula aturaken ing dinten menika nggadhahi ajinipun ingkang kirang langkung sami, inggih menika paedahipun kirang langkung sami saha dipunukur kanthi cara ingkang sami.
Kaping pisanan, ngidini sampeyan nyepetake pangiriman. Kepiye carane iki ngidini sampeyan nyepetake pangiriman? Nalika kita nggawe sawetara owah-owahan anyar ing basis kode, kita bisa langsung nyoba kanggo nindakake soko karo kode iki. Kita ora ngenteni nganti Kamis teka amarga dina Kamis kita ngeculake menyang QA Environment, kita nindakake ing kene lan ing kene.
Aku bakal nyritakake siji crita sedih saka uripku. Jaman biyen, nalika aku isih enom lan nggantheng. Saiki aku wis enom, ayu lan pinter, lan andhap asor. Sawetara wektu kepungkur aku ana ing proyek. Kita duwe tim gedhe udakara 30 pangembang. Lan kita duwe proyek Enterprise gedhe sing dikembangake udakara 10 taun. Lan kita duwe macem-macem cabang. Ing repositori kita duwe cabang ing ngendi pangembang mlaku. Lan ana cabang sing nampilake versi kode sing ana ing produksi.
Cabang produksi ana 3 wulan sawise cabang sing kasedhiya kanggo pangembang. Apa tegese iki? Iki tegese sanalika aku duwe bug nang endi wae sing dadi produksi amarga fault saka pangembang, amarga padha ngidini, lan amarga fault saka QA, amarga padha katon ing, banjur iki tegese yen aku nampa a tugas kanggo hotfix kanggo produksi, banjur aku kudu muter maneh owahan kode sandi 3 months ago. Aku kudu ngelingi apa aku wis 3 months ago lan nyoba kanggo ndandani iku ana.
Yen sampeyan durung duwe pengalaman iki, sampeyan bisa nyoba ing proyek omah sampeyan. Sing utama, aja nyoba ing komersial. Tulis sawetara baris kode, lali babagan iki kanggo nem sasi, banjur bali lan nyoba kanggo cepet nerangake apa baris kode lan carane sampeyan bisa ndandani utawa ngoptimalake. Iku pengalaman banget, macem.
Yen kita duwe praktik Integrasi Terus-terusan, mula iki ngidini kita mriksa karo sawetara alat otomatis ing kene lan saiki, sanalika aku wis nulis kodeku. Iki bisa uga ora menehi kula Gambar lengkap, nanging Nanging, iku bakal mbusak paling sawetara saka risiko. Lan yen ana bug potensial, aku bakal ngerti saiki, yaiku, secara harfiah sajrone sawetara menit. Aku ora perlu muter maneh 3 sasi. Aku mung kudu muter maneh 2 menit. Mesin kopi sing apik ora bakal duwe wektu kanggo nyedhot kopi sajrone 2 menit, dadi apik banget.
Iki nduweni nilai sing bisa bola-bali saben wektu ing saben proyek, i.e. ora mung sing sampeyan atur. Sampeyan bisa mbaleni loro laku dhewe lan CI dhewe bakal bola kanggo saben owah-owahan anyar sing digawe kanggo project. Iki ngidini sampeyan ngoptimalake sumber daya amarga tim sampeyan bisa kerja luwih efisien. Sampeyan ora bakal duwe kahanan maneh nalika ana bug teka saka kode sing sampeyan gunakake 3 wulan kepungkur. Sampeyan ora bakal duwe owah-owahan konteks maneh nalika sampeyan njagong lan nglampahi rong jam pisanan nyoba mangertos kedadeyan kasebut lan mlebu ing inti konteks sadurunge sampeyan miwiti mbenerake.
Kepiye carane bisa ngukur sukses utawa gagal praktik iki? Yen sampeyan nglaporake marang bos gedhe apa sing ditindakake ing proyek CI, dheweke krungu bla bla bla. Kita ngleksanakake, OK, nanging kenapa, apa sing digawa menyang kita, kepiye carane kita ngukur, carane bener utawa salah kita ngleksanakake?
Ingkang kapisan inggih punika, thanks kanggo CI, kita bisa masang liyane lan liyane asring, lan luwih asring sabenere amarga kode kita duweni potensi luwih stabil. Kanthi cara sing padha, wektu kanggo nemokake kesalahan wis suda lan wektu kanggo mbenerake kesalahan iki dikurangi kanthi tepat amarga kita nampa jawaban saka sistem ing kene lan saiki, apa sing salah karo kode kita.
Praktek liyane sing kita duwe yaiku praktik Pengujian Otomasi, sing paling kerep disedhiyakake karo praktik CI. Padha mlaku bebarengan.
Apa sing penting dimangerteni ing kene? Penting kanggo ngerti yen tes kita beda. Lan saben tes otomatis dituju kanggo ngrampungake masalah dhewe. Kita duwe, contone, tes unit sing ngidini kita nyoba modul kanthi kapisah, i.e. Kepiye cara kerjane ing vakum? Iki apik.
Kita uga duwe tes integrasi sing ngidini kita ngerti carane modul beda bisa nggabungake siji liyane. Iku uga apik.
Kita bisa uga duwe tes otomatisasi UI sing ngidini kita mriksa kepiye kerja karo UI nyukupi syarat tartamtu sing disetel dening pelanggan, lsp.
Tes khusus sing sampeyan lakoni bisa mengaruhi sepira kerepe sampeyan nindakake. Tes unit biasane ditulis cekak lan cilik. Lan bisa diluncurake kanthi rutin.
Yen kita ngomong babagan tes otomatisasi UI, luwih becik yen proyek sampeyan cilik. Tes otomatisasi UI sampeyan bisa njupuk sawetara wektu sing cukup. Nanging biasane tes otomatisasi UI mbutuhake sawetara jam ing proyek gedhe. Lan apik yen sawetara jam. Ing bab mung iku ora ana gunane kanggo mbukak kanggo saben mbangun. Iku ndadekake pangertèn kanggo mbukak mau ing wayah wengi. Lan nalika kabeh wong teka kerja ing wayah esuk: loro penguji lan pangembang, dheweke nampa sawetara laporan yen kita mbukak tes otomatis UI ing wayah wengi lan entuk asil kasebut. Lan ing kene, jam kerja saka server sing bakal mriksa manawa produk sampeyan memenuhi sawetara syarat bakal luwih murah tinimbang jam kerja insinyur QA sing padha, sanajan insinyur QA Junior sing kerja kanggo panganan lan matur nuwun. Kabeh padha, jam operasi mesin bakal luwih murah. Iki kok ndadekake pangertèn kanggo nandur modal ing.
Aku duwe proyek liyane sing wis dakgarap. Kita duwe sprint rong minggu ing proyek iki. Proyek kasebut gedhe, penting kanggo sektor finansial, lan kesalahan ora bisa ditindakake. Lan sawise sprint rong minggu, siklus pangembangan diterusake kanthi proses tes, sing butuh 4 minggu maneh. Coba mbayangno skala tragedi kasebut. Kita nulis kode kanggo rong minggu, banjur kita nindakake ala CodeFreeze, paket menyang versi anyar saka aplikasi, lan muter metu kanggo testers. Testers nyoba kanggo liyane 4 minggu, i.e. Nalika lagi nyoba, kita duwe wektu kanggo nyiapake rong versi liyane kanggo dheweke. Iki kasus sedhih tenan.
Lan kita ngandhani yen sampeyan pengin luwih produktif, mula sampeyan kudu ngetrapake praktik Tes Otomatis, amarga iki sing nglarani sampeyan ing kene, saiki.
Praktek Penyebaran Terus-terusan. Apik, sampeyan wis rampung mbangun. Iki wis apik. Kode sampeyan wis dikompilasi. Saiki luwih becik nggunakake bangunan iki ing sawetara lingkungan. Ayo ngomong ing lingkungan kanggo pangembang.
Apa sebabe penting? Pisanan, sampeyan bisa ndeleng carane sukses sampeyan karo proses penyebaran dhewe. Aku wis ketemu proyek kaya iki, nalika aku takon: "Kepiye sampeyan masang versi anyar saka aplikasi?", wong-wong mau marang kula: "We ngumpul lan Pack menyang arsip zip. Kita ngirim menyang admin liwat mail. Admin ngundhuh lan nggedhekake arsip iki. Lan kabeh kantor wiwit ndedonga supaya server njupuk versi anyar.
Ayo dadi miwiti karo soko prasaja. Contone, dheweke kelalen nglebokake CSS ing arsip utawa kelalen ngganti hashtag ing jeneng file java-script. Lan nalika kita njaluk panjalukan kanggo server, browser mikir sing wis file java-script iki lan mutusaké ora kanggo ngundhuh. Lan ana versi lawas, ana sing ilang. Umumé, bisa uga ana akeh masalah. Mulane, praktik Penyebaran Terus-terusan ngidini sampeyan nyoba paling ora apa sing bakal kelakon yen sampeyan njupuk gambar referensi sing resik lan diunggah menyang lingkungan anyar sing resik. Sampeyan bisa ndeleng ngendi iki ndadékaké.
Uga, nalika sampeyan nggabungake kode antarane saben liyane, i.e. antarane printah, iki ngidini sampeyan uga ndeleng carane katon ing UI.
Salah siji saka masalah sing occurs ngendi akeh vanilla java-script digunakake iku loro gawe rashly ngumumaké variabel karo jeneng sing padha ing obyek jendhela. Banjur, gumantung ing luck. Sing file java-script ditarik metu kapindho bakal nimpa owah-owahan saka liyane. Iku uga banget macem. Sampeyan mlebu: siji bab bisa kanggo wong siji, liyane ora bisa kanggo liyane. Lan iku "apik" nalika kabeh metu ing produksi.
Praktek sabanjure sing ditindakake yaiku praktik Pemulihan Otomatis, yaiku bali menyang versi aplikasi sadurunge.
Napa iki penting kanggo pangembang? Isih ana sing ngelingi taun 90an sing adoh, adoh, nalika komputer gedhe lan program cilik. Lan siji-sijine cara kanggo pangembangan web yaiku liwat PHP. Ora PHP iku basa ala, sanajan iku.
Nanging masalahe beda. Nalika kita masang versi anyar saka situs php kita, carane kita masang iku? Paling asring kita mbukak Far Manager utawa liya. Lan upload file kasebut menyang FTP. Lan kita dumadakan temen maujud sing kita duwe sawetara cilik, bug cilik, contone, kita kelalen sijine titik koma utawa kelalen kanggo ngganti sandi kanggo database, lan ana sandi kanggo database, kang ing host lokal. Lan kita mutusake kanggo nyambung menyang FTP kanthi cepet lan ngowahi file ing kana. Iki mung geni! Iki sing populer ing taun 90-an.
Nanging, yen sampeyan ora ndeleng tanggalan, taun 90-an wis meh 30 taun kepungkur. Saiki kabeh kedadeyan rada beda. Lan coba mbayangno ukuran tragedi kasebut nalika sampeyan ujar: "Kita nyebar ing produksi, nanging ana sing salah. Iki login lan sandhi FTP sampeyan, sambung menyang produksi lan cepet ndandani ing kana. Yen sampeyan Chuck Norris, iki bakal bisa. Yen ora, sampeyan duwe risiko yen sampeyan ndandani siji bug, sampeyan bakal nggawe luwih akeh 10. Iki pancen sebabe praktik muter maneh menyang versi sadurunge ngidini sampeyan entuk akeh.
Sanadyan ana sing ala, nanging ora bisa nyebabake pati. Sampeyan bisa muter bali menyang versi sadurunge sampeyan duwe. Sebutake serep, yen luwih gampang kanggo ngerteni ing terminologi kasebut. Sampeyan bisa muter maneh kanggo versi sadurungé iki, lan pangguna isih bakal bisa karo produk, lan sampeyan bakal duwe wektu buffer nyukupi. Sampeyan bisa kanthi tenang, tanpa kesusu, njupuk kabeh iki lan nyoba sacara lokal, ndandani, banjur upload versi anyar. Iku pancene ndadekake pangertèn kanggo nindakake iki.
Saiki ayo nyoba nggabungake rong praktik sadurunge. Kita bakal entuk sing katelu sing diarani Manajemen Rilis.
Nalika kita ngomong babagan Panyebaran Terus-terusan ing wangun klasik, kita ujar manawa kita kudu narik kode saka sawetara cabang saka gudang, ngumpulake lan nyebarake. Luwih becik yen kita duwe lingkungan sing padha. Yen kita duwe sawetara lingkungan, iki tegese kita kudu narik kode saben wektu, sanajan saka komitmen sing padha. Kita bakal narik metu saben wektu, kita bakal mbangun saben wektu lan kita bakal masang menyang lingkungan anyar. Kaping pisanan, iki wektu, amarga kanggo mbangun proyek, yen sampeyan duwe gedhe lan teka saka 90s, iku bisa njupuk sawetara jam.
Kajaba iku, ana sedhih liyane. Nalika sampeyan mbangun, malah ing mesin padha, sampeyan bakal mbangun sumber padha, sampeyan isih ora njamin sing mesin iki ing negara sing padha nalika mbangun pungkasan.
Contone, ana wong sing mlebu lan nganyari DotNet kanggo sampeyan utawa, kosok balene, ana sing mutusake mbusak apa wae. Banjur sampeyan duwe disonansi kognitif sing saka komitmen iki rong minggu kepungkur, kita mbangun bangunan lan kabeh apik, nanging saiki katon kaya mesin sing padha, komitmen sing padha, kode sing padha sing kita coba gawe, nanging ora bisa digunakake. . Sampeyan bakal ngatasi iki nganti suwe lan dudu kasunyatan manawa sampeyan bakal ngerti. Paling ora, sampeyan bakal ngrusak saraf sampeyan.
Mula, praktik Manajemen Rilis nyaranake ngenalake abstraksi tambahan sing diarani gudang artefak utawa galeri utawa perpustakaan. Sampeyan bisa nelpon apa wae sing dikarepake.
Ide utama yaiku yen kita duwe sawetara jinis komitmen ing kana, ujar, ing cabang sing wis siyap disebarake menyang lingkungan sing beda-beda, kita ngumpulake aplikasi saka komitmen iki lan kabeh sing dibutuhake kanggo aplikasi iki, kita bungkus. menyang arsip zip lan simpen ing sawetara panyimpenan sing bisa dipercaya. Lan saka panyimpenan iki, kita bisa entuk arsip zip iki kapan wae.
Banjur kita njupuk lan kanthi otomatis masang menyang lingkungan dev. Kita balapan ing kana, lan yen kabeh apik, banjur kita nyebar menyang panggung. Yen kabeh apik, banjur kita nyebarake arsip sing padha menyang produksi, binari sing padha, disusun persis sapisan.
Kajaba iku, nalika kita duwe galeri kaya iki, uga mbantu ngatasi risiko sing diatasi ing slide pungkasan nalika kita ngomong babagan rollback menyang versi sadurunge. Yen sampeyan ora sengaja nyebarke sing salah, sampeyan bisa tansah njupuk versi sadurungé saka galeri iki lan undeploy menyang lingkungan iki kanthi cara sing padha. Iki ngidini sampeyan gampang muter maneh menyang versi sadurunge yen ana masalah.
Ana liyane laku gedhe. Sampeyan lan aku kabeh ngerti yen nalika muter maneh aplikasi menyang versi sadurunge, iki bisa uga ateges kita uga butuh infrastruktur versi sadurunge.
Nalika kita ngomong babagan infrastruktur virtual, akeh wong sing mikir yen iki minangka sing diatur dening admin. Lan yen sampeyan perlu, ngomong, kanggo njaluk server anyar sing pengin nyoba versi anyar saka aplikasi, sampeyan kudu nulis tiket kanggo admins utawa devops. Devops bakal njupuk 3 minggu kanggo iki. Lan sawise 3 minggu padha bakal pitutur marang kowe sing kita wis diinstal mesin virtual kanggo sampeyan, karo siji inti, rong gigabyte RAM lan server Windows tanpa DotNet. Sampeyan ngomong: "Nanging aku pengin DotNet." Dheweke: "Oke, bali ing 3 minggu."
Ide kasebut yaiku kanthi nggunakake Infrastruktur minangka praktik Kode, sampeyan bisa nganggep infrastruktur virtual minangka sumber daya liyane.
Mbok menawa, yen ana sing ngembangake aplikasi ing DotNet, sampeyan bisa uga wis krungu babagan perpustakaan sing diarani Entity Framework. Lan sampeyan bisa uga wis krungu manawa Entity Framework minangka salah sawijining pendekatan sing ditindakake Microsoft kanthi aktif. Kanggo nggarap database, iki minangka pendekatan sing diarani Code First. Iki nalika sampeyan njlèntrèhaké ing kode carane sampeyan pengin database katon. Banjur sampeyan masang aplikasi kasebut. Iku nyambung menyang database, iku dhewe nemtokake kang tabel ana lan kang ora tabel, lan nggawe kabeh sing perlu.
Sampeyan bisa nindakake padha karo infrastruktur sampeyan. Ora ana bedane apa sampeyan butuh database kanggo proyek utawa sampeyan butuh server Windows kanggo proyek. Iku mung sumber daya. Lan sampeyan bisa ngotomatisasi nggawe sumber daya iki, sampeyan bisa ngotomatisasi konfigurasi sumber daya iki. Patut, saben-saben sampeyan pengin nyoba sawetara konsep anyar, sawetara pendekatan anyar, sampeyan ora perlu kanggo nulis tiket kanggo devops, sampeyan mung bisa masang infrastruktur terisolasi kanggo dhewe saka cithakan siap-digawe, saka skrip siap-digawe lan ngleksanakake. ana kabeh eksperimen sampeyan. Sampeyan bisa mbusak iki, entuk sawetara asil lan laporan luwih lengkap babagan iki.
Praktek sabanjure, sing uga ana lan uga penting, nanging sawetara wong nggunakake, yaiku Pemantauan Kinerja Aplikasi.
Aku pengin ngomong mung siji bab Pemantauan Kinerja Aplikasi. Apa sing paling penting babagan praktik iki? Iki minangka Pemantauan Kinerja Aplikasi meh padha karo ndandani apartemen. Iki dudu negara pungkasan, nanging proses. Sampeyan kudu nindakake kanthi rutin.
Kanthi cara sing apik, luwih becik nindakake Pemantauan Kinerja Aplikasi ing meh kabeh bangunan, sanajan sampeyan ngerti, iki ora mesthi bisa ditindakake. Nanging, paling ora, kudu ditindakake kanggo saben rilis.
Apa sebabe penting? Amarga yen sampeyan tiba-tiba ngalami penurunan kinerja, mula sampeyan kudu ngerti sebabe. Yen tim sampeyan duwe, umpamane, sprint rong minggu, banjur paling ora saben rong minggu sampeyan kudu masang aplikasi menyang sawetara server sing kapisah, ing ngendi sampeyan duwe prosesor, RAM, disk, lan sapiturute sing jelas. . Sampeyan entuk asil. Waca carane wis diganti saka sprint sadurungé.
Lan yen sampeyan ngerteni manawa drawdown mudhun banget ing endi wae, tegese mung amarga owah-owahan sing kedadeyan sajrone rong minggu kepungkur. Iki bakal ngidini sampeyan ngenali lan ndandani masalah luwih cepet. Lan maneh, iki kira-kira metrik sing padha karo sampeyan bisa ngukur sepira sukses sampeyan nindakake.
Praktek sabanjure yaiku praktik Manajemen Konfigurasi. Ana sawetara banget sing njupuk iki serius. Nanging pracaya kula, iki bener bab banget serius.
Ana crita lucu bubar. Wong lanang teka lan ujar: "Bantuan kita nindakake audit keamanan aplikasi kita." Kita nyawang kode bebarengan kanggo wektu sing suwe, dheweke ngandhani babagan aplikasi kasebut, nggambar diagram. Lan plus utawa minus kabeh logis, dingerteni, aman, nanging ana siji TAPI! Padha duwe file konfigurasi ing kontrol sumber, kalebu sing saka produksi karo database IP, karo logins lan sandhi kanggo nyambung menyang database iki, etc.
Lan aku kandha: "Guys, oke, sampeyan wis nutup lingkungan produksi sampeyan nganggo firewall, nanging kasunyatan manawa sampeyan duwe login lan sandhi kanggo database produksi langsung ing kontrol sumber lan pangembang apa wae sing bisa maca wis dadi resiko keamanan sing gedhe. . Lan ora ketompo carane super aman aplikasi sampeyan saka sudut pandang kode, yen sampeyan ninggalake ing kontrol sumber, sampeyan ora bakal ngliwati audit ing ngendi wae. Sing dakkandhakake.
Manajemen konfigurasi. Kita bisa uga duwe konfigurasi sing beda ing lingkungan sing beda. Contone, kita bisa uga duwe login lan sandhi sing beda kanggo database kanggo QA, demo, lingkungan produksi, lsp.
Konfigurasi iki uga bisa otomatis. Iku kudu tansah kapisah saka aplikasi dhewe. Kenging punapa? Amarga sampeyan mbangun aplikasi sapisan, banjur aplikasi ora peduli apa sampeyan nyambungake menyang server SQL liwat IP kuwi lan kuwi utawa IP kuwi lan kuwi, iku kudu bisa padha. Mulane, yen dumadakan salah siji saka sampeyan isih hardcoding senar sambungan ing kode, banjur elinga yen aku bakal nemokake sampeyan lan ngukum sampeyan yen sampeyan nemokake dhewe ing project padha karo kula. Iki tansah diselehake ing konfigurasi kapisah, contone, ing web.config.
Lan konfigurasi iki wis diatur kanthi kapisah, yaiku, iki persis nalika pangembang lan administrator bisa teka lan lungguh ing kamar sing padha. Lan pangembang bisa ngomong: "Deleng, iki binari aplikasiku. Padha kerja. Aplikasi kasebut mbutuhake database supaya bisa digunakake. Ing jejere binari ana file. Ing file iki, lapangan iki tanggung jawab kanggo login, iki kanggo sandi, iki kanggo IP. Sebarake ing ngendi wae." Lan prasaja lan jelas kanggo admin. Dheweke bisa nyebarake ing endi wae kanthi ngatur konfigurasi iki.
Dene praktik ingkang pungkasan ingkang badhe kula aturaken inggih menika praktik ingkang gayut sanget kaliyan mega. Lan nggawa efek maksimal yen sampeyan kerja ing awan. Iki minangka mbusak lingkungan kanthi otomatis.
Aku ngerti ana sawetara wong ing konferensi iki saka tim aku kerjo karo. Lan karo kabeh tim sing kerja bareng, kita nggunakake latihan iki.
Kenging punapa? Mesthi, bakal apik yen saben pangembang duwe mesin virtual sing bisa digunakake 24/7. Nanging mbok menawa iki warta kanggo sampeyan, mbok menawa sampeyan ora mbayar manungsa waé, nanging pangembang dhewe ora bisa 24/7. Pangembang biasane kerja 8 jam saben dina. Sanajan dheweke teka kerja luwih awal, dheweke duwe nedha awan gedhe nalika dheweke menyang gedung olahraga. Ayo dadi 12 jam dina nalika pangembang bener nggunakake sumber daya kasebut. Miturut undang-undang kita, kita duwe 5 saka 7 dina ing seminggu sing dianggep dina kerja.
Mulane, ing dina kerja mesin iki ora bisa digunakake 24 jam, nanging mung 12 jam, lan ing akhir minggu mesin iki ora bisa digunakake. Iku bakal katon yen kabeh iku prasaja banget, nanging apa penting kanggo ngomong kene? Kanthi ngetrapake praktik prasaja iki ing jadwal dhasar iki, sampeyan bisa nyuda biaya njaga lingkungan kasebut nganti 70%, yaiku sampeyan njupuk rega dev, QA, demo, lingkungan lan dibagi dadi 3.
Pitakonan, apa sing kudu dilakoni karo sisa dhuwit? Contone, pangembang kudu tuku ReSharper yen durung. Utawa duwe pesta koktail. Yen sampeyan sadurunge duwe siji lingkungan kang loro dev lan QA grazed, lan iku, saiki sampeyan bisa nggawe 3 beda sing bakal diisolasi, lan wong ora bakal ngganggu saben liyane.
Babagan slide kanthi pangukuran kinerja terus-terusan, kepiye kita bisa mbandhingake kinerja yen kita duwe 1 cathetan ing database ing proyek kasebut, rong wulan mengko ana yuta? Kepiye carane ngerti sebabe lan apa gunane ngukur kinerja?
Iki minangka pitakonan sing apik, amarga sampeyan kudu ngukur kinerja ing sumber daya sing padha. Sing, sampeyan muter metu kode anyar, sampeyan ngukur kinerja ing kode anyar. Contone, sampeyan kudu nguji skenario kinerja sing beda-beda, umpamane sampeyan pengin nyoba kinerja aplikasi ing beban sing entheng, ing ngendi ana 1 pangguna lan ukuran database 000 gigabyte. Sampeyan ngukur lan entuk nomer. Sabanjure kita njupuk skenario liyane. Contone, 5 pangguna, ukuran database 5 terabyte. Kita nampa asil lan ngelingi.
Apa sing penting ing kene? Sing penting ing kene yaiku gumantung saka skenario, volume data, jumlah pangguna simultan, lan liya-liyane, sampeyan bisa ngalami watesan tartamtu. Contone, kanggo watesan kertu jaringan, utawa watesan hard drive, utawa watesan kapasitas prosesor. Iki sing penting sampeyan ngerti. Ing macem-macem skenario sampeyan mbukak menyang watesan tartamtu. Lan sampeyan kudu ngerti nomer nalika sampeyan mencet.
Apa kita ngomong babagan ngukur kinerja ing lingkungan tes khusus? Sing, iki ora produksi?
Ya, iki dudu produksi, iki minangka lingkungan tes, sing mesthi padha supaya sampeyan bisa mbandhingake karo pangukuran sadurunge.
Matur nuwun mangertos!
Yen ora ana pitakonan, aku rumangsa bisa rampung. Matur nuwun!
Source: www.habr.com