Laporan itu akan membincangkan beberapa amalan DevOps, tetapi dari sudut pandangan pembangun. Biasanya, semua jurutera yang menyertai DevOps sudah mempunyai beberapa tahun pengalaman pentadbiran di bawah tali pinggang mereka. Tetapi ini tidak bermakna tiada tempat untuk pemaju di sini. Lebih kerap daripada tidak, pembangun sibuk membetulkan "pepijat kritikal seterusnya yang kritikal pada hari itu," dan mereka tidak mempunyai masa untuk melihat medan DevOps dengan pantas. Pada pemahaman penulis, DevOps adalah, pertama, akal. Kedua, ia adalah peluang untuk menjadi lebih berkesan. Jika anda seorang pembangun, mempunyai akal yang waras dan ingin menjadi lebih berkesan sebagai pemain pasukan, laporan ini adalah untuk anda.
Izinkan saya memperkenalkan diri saya, saya mengakui sepenuhnya bahawa ada orang di dalam bilik yang tidak mengenali saya. Nama saya Anton Boyko, saya seorang MVP Microsoft Azure. Apa itu MVP? Ini ialah Model-View-Presenter. Model-View-Presenter ialah saya.
Selain itu, saya kini memegang jawatan sebagai arkitek penyelesaian di Ciklum. Dan baru-baru ini saya membeli sendiri domain yang begitu indah, dan saya mengemas kini e-mel saya, yang biasanya saya tunjukkan pada pembentangan. Anda boleh menulis kepada saya di: me [dog] byokoant.pro. Anda boleh menghantar e-mel kepada saya dengan soalan. Saya biasanya menjawab mereka. Satu-satunya perkara ialah saya tidak mahu menerima soalan melalui e-mel yang berkaitan dengan dua topik: politik dan agama. Anda boleh menulis kepada saya tentang segala-galanya melalui e-mel. Beberapa masa akan berlalu, saya akan menjawab.
Sedikit perkataan tentang diri saya:
- Saya telah berkecimpung dalam bidang ini selama 10 tahun sekarang.
- Saya bekerja di Microsoft.
- Saya ialah bapa pengasas komuniti Azure Ukraine, yang kami asaskan di suatu tempat pada 2014. Dan kami masih memilikinya dan sedang membangunkannya.
- Saya juga bapa kepada pengasas persidangan Azure, yang kami anjurkan di Ukraine.
- Saya juga membantu menganjurkan Global Azure Bootcamp di Kyiv.
- Seperti yang saya katakan, saya seorang MVP Microsoft Azure.
- Saya sering bercakap di persidangan. Saya sangat suka bercakap di persidangan. Sepanjang tahun lalu saya dapat membuat persembahan kira-kira 40 kali. Jika anda melalui Ukraine, Belarus, Poland, Bulgaria, Sweden, Denmark, Belanda, Sepanyol atau memberi atau mengambil negara lain di Eropah, maka ada kemungkinan apabila anda pergi ke persidangan yang mempunyai tema awan dalam alirannya, anda mungkin melihat saya dalam senarai pembesar suara.
- Saya juga peminat Star Trek.
Mari kita bercakap sedikit tentang Agenda. Agenda kami sangat mudah:
- Kami akan bercakap tentang apa itu DevOps. Mari kita bincangkan mengapa ini penting. Sebelum ini, DevOps ialah kata kunci yang anda tulis pada resume anda dan serta-merta menerima +$500 gaji. Sekarang anda perlu menulis, sebagai contoh, blockchain dalam resume anda untuk mendapatkan +500 dolar kepada gaji anda.
- Dan kemudian, apabila kita memahami sedikit tentang perkara ini, kita akan bercakap tentang amalan DevOps. Tetapi tidak begitu banyak dalam konteks DevOps secara umum, tetapi mengenai amalan DevOps yang mungkin menarik minat pembangun. Saya akan memberitahu anda mengapa mereka mungkin menarik minat anda. Saya akan memberitahu anda mengapa anda perlu melakukan ini sama sekali dan bagaimana ia boleh membantu anda mengurangkan kesakitan.
Gambar tradisional yang ramai orang tunjukkan. Inilah yang berlaku dalam banyak projek. Ini adalah apabila kami mempunyai jabatan pembangunan dan operasi yang menyokong perisian kami. Dan jabatan-jabatan ini tidak berkomunikasi antara satu sama lain.
Mungkin, jika anda tidak dapat merasakannya dengan jelas di bahagian DevOps dan operasi, anda boleh membuat analogi dengan jabatan Dev dan QA. Ada orang yang membangunkan perisian dan ada orang QA yang buruk dari sudut pandangan pembangun. Sebagai contoh, saya menyerahkan kod indah saya kepada repositori, dan terdapat beberapa orang jahat duduk di sana yang mengembalikan kod ini kepada saya dan mengatakan bahawa kod anda adalah buruk.
Ini semua berlaku kerana manusia tidak berkomunikasi antara satu sama lain. Dan mereka membuang beberapa pakej, beberapa aplikasi antara satu sama lain melalui beberapa dinding salah faham dan cuba melakukan sesuatu dengan mereka.
Tepat dinding inilah budaya DevOps direka untuk memusnahkan, i.e. memaksa orang ramai untuk berkomunikasi antara satu sama lain dan sekurang-kurangnya memahami perkara yang dilakukan oleh orang yang berbeza dalam projek dan mengapa kerja mereka penting.
Dan apabila kita bercakap tentang DevOps, seseorang akan memberitahu anda bahawa DevOps ialah apabila projek itu mempunyai penyepaduan berterusan; seseorang akan mengatakan bahawa DevOps adalah jika projek itu melaksanakan amalan "infrastruktur sebagai kod"; seseorang akan mengatakan bahawa langkah pertama untuk DevOps ialah percabangan ciri, bendera ciri.
Pada asasnya, ini semua benar dengan caranya sendiri. Tetapi ini hanyalah amalan muktamad yang kita ada. Sebelum beralih kepada amalan ini, saya cadangkan melihat slaid ini, yang menunjukkan 3 peringkat pelaksanaan metodologi Dev-Ops dalam projek anda, dalam syarikat anda.
Slaid ini juga mempunyai nama tidak rasmi kedua. Anda boleh mencari dalam talian untuk mengetahui apakah itu 3 Musketeers of DevOps. Ada kemungkinan anda akan menemui artikel ini. Mengapa 3 Musketeers? Di bawahnya tertulis: orang, proses dan produk, i.e. PPP β Porthos, Porthos dan Porthos. Berikut ialah 3 musketeer DevOps. Artikel ini menerangkan dengan lebih terperinci mengapa ini penting dan apa yang diperlukan.
Apabila anda mula melaksanakan budaya DevOps, adalah sangat penting untuk ia dilaksanakan mengikut susunan berikut.
Pada mulanya anda perlu bercakap dengan orang. Dan anda perlu menerangkan kepada orang apa itu dan bagaimana mereka boleh mendapat beberapa faedah daripadanya.
Persidangan kami dipanggil DotNet Fest. Dan seperti yang diberitahu oleh penganjur, kami terutamanya menjemput penonton pemaju di sini, jadi saya berharap kebanyakan orang di dalam dewan terlibat dalam pembangunan.
Kami akan bercakap tentang orang, kami akan bercakap tentang apa yang pemaju mahu lakukan setiap hari. Apa yang paling mereka mahukan? Mereka mahu menulis beberapa kod baharu, menggunakan rangka kerja bermodel baharu, mencipta ciri baharu. Apakah yang paling tidak diingini oleh pembangun? Betulkan pepijat lama. Saya harap anda bersetuju dengan saya. Inilah yang dimahukan oleh pemaju. Mereka mahu menulis ciri baharu, mereka tidak mahu membetulkan pepijat.
Bilangan pepijat yang dihasilkan oleh pembangun tertentu bergantung pada sejauh mana lengannya lurus dan berapa banyak ia tumbuh dari bahunya, dan bukan dari poket punggungnya. Namun begitu, apabila kami mempunyai projek yang besar, kadang-kadang ia berlaku bahawa adalah mustahil untuk menjejaki segala-galanya, jadi adalah baik untuk kami menggunakan beberapa pendekatan yang akan membantu kami menulis kod yang lebih stabil dan berkualiti tinggi.
Apakah yang paling QA mahukan? Saya tidak tahu sama ada mereka berada di dalam dewan. Sukar untuk saya mengatakan bahawa saya mahukan QA, kerana saya tidak pernah melakukannya. Dan tiada kesalahan kepada lelaki, ia akan dikatakan bahawa saya harap saya tidak akan melakukannya. Tetapi bukan kerana saya menganggap kerja mereka tidak bermakna dan tidak berguna, tetapi kerana saya tidak menganggap diri saya seorang yang boleh melakukan kerja ini dengan cekap, jadi saya tidak akan cuba melakukannya. Tetapi daripada apa yang saya faham, perkara yang paling tidak disukai oleh QA ialah akan berfungsi pada waktu pagi, sentiasa menjalankan beberapa jenis ujian regresi, memijak pepijat yang sama yang mereka laporkan kepada pembangun 3 pecut yang lalu dan berkata: βBilakah anda akan , Tuan D 'Artagnan, betulkan pepijat ini.' Dan Monsieur D'Artagnan menjawabnya: "Ya, ya, ya, saya sudah membetulkannya." Dan bagaimana ia berlaku bahawa saya membetulkan satu pepijat dan membuat 5 di sepanjang jalan.
Orang yang menyokong penyelesaian ini dalam pengeluaran mahu penyelesaian ini berfungsi tanpa pepijat, supaya mereka tidak perlu but semula pelayan setiap hari Jumaat, apabila semua orang biasa pergi ke bar. Pembangun digunakan pada hari Jumaat, pentadbir duduk sehingga Sabtu, cuba untuk mendapatkan penggunaan ini dan diperbaiki.
Dan apabila anda menerangkan kepada orang ramai bahawa mereka bertujuan untuk menyelesaikan masalah yang sama, anda boleh meneruskan untuk memformalkan proses tersebut. Ianya sangat penting. kenapa? Kerana apabila kita menyebut "pemformalan," adalah penting untuk anda menerangkan cara proses anda berlaku sekurang-kurangnya di suatu tempat pada serbet. Anda perlu memahami bahawa jika anda, sebagai contoh, menggunakan persekitaran QA atau persekitaran pengeluaran, maka ia sentiasa berlaku dalam susunan ini; pada peringkat ini kami menjalankan, contohnya, ujian unit automatik dan ujian UI. Selepas penggunaan, kami menyemak sama ada penggunaan berjalan dengan baik atau teruk. Tetapi anda sudah mempunyai senarai tindakan yang jelas yang mesti diulang berulang kali apabila anda digunakan untuk pengeluaran.
Dan hanya apabila proses anda diformalkan, anda mula memilih produk yang akan membantu anda mengautomasikan proses ini.
Malangnya, saya sering melihat perkara ini berlaku secara terbalik. Sebaik sahaja seseorang mendengar perkataan "DevOps", mereka segera mencadangkan untuk memasang Jenkins, kerana mereka percaya bahawa sebaik sahaja mereka memasang Jenkins, mereka akan mempunyai DevOps. Mereka memasang Jenkins, membaca artikel "Cara" di tapak web Jenkins, cuba memasukkan proses ke dalam artikel Cara ini, dan kemudian datang kepada orang ramai dan membongkok orang, mengatakan bahawa buku itu mengatakan bahawa anda perlu melakukannya dengan cara ini, jadi kita buat macam ni.
Bukannya Jenkins adalah alat yang buruk. Saya tidak bermaksud untuk mengatakan itu dalam apa cara sekalipun. Tetapi ini hanya salah satu produk. Dan produk yang anda gunakan harus menjadi keputusan terakhir anda, dan bukan yang pertama anda. Produk anda tidak seharusnya dipacu oleh pelaksanaan budaya dan pendekatan. Ini sangat penting untuk difahami, itulah sebabnya saya menghabiskan banyak masa pada slaid ini dan menerangkan semua ini untuk sekian lama.
Mari bercakap tentang amalan DevOps secara umum. Apakah mereka? Apakah perbezaannya? Bagaimana untuk mencubanya? Mengapa mereka penting?
Amalan pertama yang mungkin anda pernah dengar dipanggil Integrasi Berterusan. Mungkin seseorang dalam projek itu mempunyai Integrasi Berterusan (CI).
Masalah terbesar ialah paling kerap apabila saya bertanya kepada seseorang: "Adakah anda mempunyai CI dalam projek itu?" dan dia berkata: "Ya," kemudian apabila saya bertanya apa yang dia lakukan, dia menerangkan kepada saya sepenuhnya keseluruhan proses automasi. Ini tidak sepenuhnya benar.
Malah, amalan CI hanya bertujuan untuk menyepadukan kod yang ditulis oleh orang yang berbeza ke dalam beberapa jenis asas kod tunggal. Itu sahaja.
Bersama-sama dengan CI, biasanya terdapat amalan lain di sepanjang jalan - seperti Penggunaan Berterusan, Pengurusan Pelepasan, tetapi kita akan membincangkannya kemudian.
CI sendiri memberitahu kita bahawa orang yang berbeza menulis kod dan kod ini mesti disepadukan secara berterusan ke dalam pangkalan kod tunggal.
Apakah yang diberikan ini kepada kita dan mengapa ia penting? Jika kita mempunyai DotNet, maka itu bagus, ia adalah bahasa yang disusun, kita boleh menyusun aplikasi kita. Jika ia menyusun, maka ini sudah menjadi petanda yang baik. Ini belum bermakna apa-apa lagi, tetapi ia adalah petanda baik pertama yang sekurang-kurangnya boleh kita susun.
Kemudian kita boleh menjalankan beberapa ujian, yang juga merupakan amalan yang berasingan. Ujian semuanya hijau - ini adalah petanda baik kedua. Tetapi sekali lagi, ini tidak bermakna apa-apa.
Tetapi mengapa anda melakukan ini? Semua amalan yang akan saya bincangkan hari ini membawa nilai yang lebih kurang sama, iaitu lebih kurang faedah yang sama dan juga diukur dengan cara yang sama.
Pertama, ia membolehkan anda mempercepatkan penghantaran. Bagaimanakah ini membolehkan anda mempercepatkan penghantaran? Apabila kami membuat beberapa perubahan baharu pada pangkalan kod kami, kami boleh segera mencuba melakukan sesuatu dengan kod ini. Kami tidak menunggu sehingga Khamis datang kerana pada hari Khamis kami mengeluarkannya kepada QA Environment, kami melakukannya di sini dan di sini.
Saya akan memberitahu anda satu kisah sedih dari hidup saya. Lama dahulu, semasa saya masih muda dan kacak. Sekarang saya sudah muda, cantik dan bijak, dan sederhana. Beberapa ketika dahulu saya berada dalam projek. Kami mempunyai pasukan besar kira-kira 30 pembangun. Dan kami mempunyai projek Perusahaan yang besar dan besar yang dibangunkan selama kira-kira 10 tahun. Dan kami mempunyai cawangan yang berbeza. Dalam repositori kami mempunyai cawangan di mana pemaju berjalan. Dan terdapat cawangan yang memaparkan versi kod yang sedang dalam pengeluaran.
Cawangan pengeluaran adalah 3 bulan di belakang cawangan yang tersedia untuk pemaju. Apakah maksud ini? Ini bermakna bahawa sebaik sahaja saya mempunyai pepijat di suatu tempat yang pergi ke pengeluaran disebabkan oleh kesalahan pemaju, kerana mereka membenarkannya, dan disebabkan oleh kesalahan QA, kerana mereka melihatnya, maka ini bermakna jika saya menerima tugas untuk hotfix untuk pengeluaran, maka saya perlu melancarkan semula perubahan kod saya 3 bulan yang lalu. Saya perlu ingat apa yang saya ada 3 bulan lalu dan cuba membetulkannya di sana.
Jika anda belum mempunyai pengalaman ini, anda boleh mencubanya pada projek rumah anda. Perkara utama ialah, jangan cuba pada yang komersial. Tulis beberapa baris kod, lupakan tentangnya selama enam bulan, dan kemudian kembali dan cuba terangkan dengan cepat tentang maksud baris kod tersebut dan cara anda boleh membetulkan atau mengoptimumkannya. Ia satu pengalaman yang sangat-sangat mengujakan.
Jika kita mempunyai amalan Integrasi Berterusan, maka ini membolehkan kita menyemaknya dengan beberapa alat automatik di sini dan sekarang, sebaik sahaja saya menulis kod saya. Ini mungkin tidak memberi saya gambaran penuh, tetapi bagaimanapun, ia akan menghapuskan sekurang-kurangnya beberapa risiko. Dan jika terdapat sebarang pepijat yang berpotensi, saya akan mengetahuinya sekarang, iaitu, secara literal dalam beberapa minit. Saya tidak perlu berpatah balik 3 bulan. Saya hanya perlu berpatah balik 2 minit. Mesin kopi yang baik tidak akan mempunyai masa untuk membancuh kopi dalam masa 2 minit, jadi ia sangat bagus.
Ini mempunyai nilai yang boleh diulang dari semasa ke semasa pada setiap projek, i.e. bukan sahaja yang anda sediakan. Anda boleh mengulangi kedua-dua amalan itu sendiri dan CI itu sendiri akan diulang untuk setiap perubahan baharu yang anda buat pada projek. Ini membolehkan anda mengoptimumkan sumber kerana pasukan anda bekerja dengan lebih cekap. Anda tidak akan mengalami situasi di mana pepijat datang kepada anda daripada kod yang anda gunakan 3 bulan lalu. Anda tidak akan mempunyai penukaran konteks lagi apabila anda duduk dan menghabiskan dua jam pertama cuba memahami perkara yang berlaku kemudian dan memahami intipati konteks sebelum anda mula membetulkan sesuatu.
Bagaimanakah kita boleh mengukur kejayaan atau kegagalan amalan ini? Jika anda melaporkan kepada bos besar apa yang kami laksanakan pada projek CI, dia mendengar bla bla bla. Kami melaksanakannya, OK, tetapi mengapa, apa yang ia bawa kepada kami, bagaimana kami mengukurnya, sejauh mana betul atau salah kami melaksanakannya?
Yang pertama ialah, terima kasih kepada CI, kami boleh menggunakan lebih banyak dan lebih kerap, dan lebih kerap dengan tepat kerana kod kami berpotensi lebih stabil. Dengan cara yang sama, masa kami untuk mencari ralat dikurangkan dan masa untuk membetulkan ralat ini dikurangkan dengan tepat atas sebab kami menerima jawapan daripada sistem di sini dan sekarang, apa yang salah dengan kod kami.
Amalan lain yang kami ada ialah amalan Ujian Automasi, yang paling kerap disertakan dengan amalan CI. Mereka berjalan seiring.
Apa yang penting untuk difahami di sini? Adalah penting untuk memahami bahawa ujian kami berbeza. Dan setiap ujian automatik bertujuan untuk menyelesaikan masalahnya sendiri. Kami mempunyai, sebagai contoh, ujian unit yang membolehkan kami menguji modul secara berasingan, i.e. Bagaimanakah ia berfungsi dalam vakum? Ini baik.
Kami juga mempunyai ujian penyepaduan yang membolehkan kami memahami cara modul berbeza berintegrasi antara satu sama lain. Ia juga bagus.
Kami mungkin mempunyai ujian automasi UI yang membolehkan kami menyemak sejauh mana kerja dengan UI memenuhi keperluan tertentu yang ditetapkan oleh pelanggan, dsb.
Ujian khusus yang anda jalankan boleh mempengaruhi kekerapan anda menjalankannya. Ujian unit biasanya ditulis pendek dan kecil. Dan ia boleh dilancarkan secara berkala.
Jika kita bercakap tentang ujian automasi UI, maka adalah baik jika projek anda kecil. Ujian automasi UI anda boleh mengambil sedikit masa yang mencukupi. Tetapi biasanya ujian automasi UI adalah sesuatu yang mengambil masa beberapa jam untuk projek besar. Dan ia adalah baik jika ia beberapa jam. Satu-satunya perkara ialah tidak ada gunanya menjalankannya untuk setiap binaan. Ia masuk akal untuk menjalankannya pada waktu malam. Dan apabila semua orang datang bekerja pada waktu pagi: kedua-dua penguji dan pembangun, mereka menerima beberapa jenis laporan bahawa kami menjalankan autoujian UI pada waktu malam dan mendapat hasil ini. Dan di sini, satu jam kerja pelayan yang akan menyemak bahawa produk anda memenuhi beberapa keperluan akan jauh lebih murah daripada satu jam kerja jurutera QA yang sama, walaupun dia seorang jurutera QA Junior yang bekerja untuk makanan dan terima kasih. Walau bagaimanapun, satu jam operasi mesin akan menjadi lebih murah. Itulah sebabnya masuk akal untuk melabur di dalamnya.
Saya mempunyai satu lagi projek yang telah saya kerjakan. Kami melakukan larian pecut selama dua minggu dalam projek ini. Projek itu besar, penting untuk sektor kewangan, dan kesilapan tidak boleh dilakukan. Dan selepas pecut dua minggu, kitaran pembangunan diikuti dengan proses ujian, yang mengambil masa 4 minggu lagi. Cuba bayangkan skala tragedi itu. Kami menulis kod selama dua minggu, kemudian kami melakukannya secara CodeFreeze, membungkusnya ke dalam versi baharu aplikasi dan melancarkannya kepada penguji. Penguji mengujinya selama 4 minggu lagi, i.e. Semasa mereka mengujinya, kami mempunyai masa untuk menyediakan dua lagi versi untuk mereka. Ini adalah kes yang sangat menyedihkan.
Dan kami memberitahu mereka bahawa jika anda ingin menjadi lebih produktif, masuk akal untuk anda melaksanakan amalan Ujian Automatik, kerana inilah yang menyakitkan anda di sini, sekarang.
Amalkan Penggunaan Berterusan. Hebat, anda telah selesai membina. Ini sudah bagus. Kod anda telah disusun. Sekarang adalah baik untuk menggunakan binaan ini pada beberapa persekitaran. Katakan dalam persekitaran untuk pembangun.
Mengapa ia penting? Pertama, anda boleh melihat sejauh mana kejayaan anda dengan proses penempatan itu sendiri. Saya telah menemui projek seperti ini, apabila saya bertanya: "Bagaimana anda menggunakan versi baharu aplikasi?", Lelaki itu memberitahu saya: "Kami memasangnya dan membungkusnya ke dalam arkib zip. Kami menghantarnya kepada pentadbir melalui pos. Pentadbir memuat turun dan mengembangkan arkib ini. Dan seluruh pejabat mula berdoa agar pelayan akan mengambil versi baharu.β
Mari kita mulakan dengan sesuatu yang mudah. Sebagai contoh, mereka terlupa untuk meletakkan CSS dalam arkib atau terlupa menukar hashtag dalam nama fail skrip java. Dan apabila kami membuat permintaan kepada pelayan, penyemak imbas berfikir bahawa ia sudah mempunyai fail skrip java ini dan memutuskan untuk tidak memuat turunnya. Dan ada versi lama, ada yang hilang. Secara umum, terdapat banyak masalah. Oleh itu, amalan Penerapan Berterusan membolehkan anda sekurang-kurangnya menguji perkara yang akan berlaku jika anda mengambil imej rujukan yang bersih dan memuat naiknya ke persekitaran baharu yang bersih sepenuhnya. Anda boleh melihat ke mana arahnya.
Juga, apabila anda menyepadukan kod antara satu sama lain, i.e. antara arahan, ini membolehkan anda juga melihat penampilannya pada UI.
Salah satu masalah yang berlaku di mana banyak skrip java vanila digunakan ialah dua pembangun secara tergesa-gesa mengisytiharkan pembolehubah dengan nama yang sama dalam objek tetingkap. Dan kemudian, bergantung pada nasib anda. Fail skrip java yang ditarik keluar kedua akan menimpa perubahan yang lain. Ia juga sangat mengujakan. Anda masuk: satu perkara berfungsi untuk seseorang, yang lain tidak berfungsi untuk yang lain. Dan ia "indah" apabila semuanya keluar dalam pengeluaran.
Amalan seterusnya yang kami ada ialah amalan Pemulihan Automatik, iaitu kembali ke versi aplikasi sebelumnya.
Mengapa ini penting untuk pembangun? Masih ada yang ingat 90-an yang jauh, jauh, ketika komputer besar dan program kecil. Dan satu-satunya cara untuk pembangunan web adalah melalui PHP. Bukannya PHP adalah bahasa yang buruk, walaupun begitu.
Tetapi masalahnya berbeza. Apabila kami menggunakan versi baharu tapak php kami, bagaimana kami menggunakannya? Selalunya kami membuka Pengurus Jauh atau sesuatu yang lain. Dan memuat naik fail ini ke FTP. Dan kami tiba-tiba menyedari bahawa kami mempunyai beberapa pepijat kecil, sebagai contoh, kami terlupa untuk meletakkan koma bertitik atau terlupa untuk menukar kata laluan untuk pangkalan data, dan terdapat kata laluan untuk pangkalan data, yang terdapat pada hos tempatan. Dan kami memutuskan untuk menyambung dengan cepat ke FTP dan mengedit fail di sana. Ini hanya api! Inilah yang popular pada tahun 90-an.
Tetapi, jika anda tidak melihat kalendar, tahun 90-an adalah hampir 30 tahun yang lalu. Sekarang semuanya berlaku sedikit berbeza. Dan cuba bayangkan skala tragedi itu apabila mereka memberitahu anda: βKami mengerahkan untuk pengeluaran, tetapi ada sesuatu yang tidak kena di sana. Inilah log masuk dan kata laluan FTP anda, sambung ke pengeluaran dan betulkan di sana dengan cepat." Jika anda Chuck Norris, ini akan berkesan. Jika tidak, maka anda berisiko bahawa jika anda membetulkan satu pepijat, anda akan membuat 10 pepijat lagi. Inilah sebabnya mengapa amalan beralih kembali ke versi sebelumnya membolehkan anda mencapai banyak perkara.
Walaupun sesuatu yang buruk entah bagaimana masuk ke dalam prod di suatu tempat, maka ia buruk, tetapi tidak membawa maut. Anda boleh kembali ke versi sebelumnya yang anda miliki. Panggil ia sandaran, jika lebih mudah untuk melihatnya dalam istilah itu. Anda boleh kembali ke versi sebelumnya dan pengguna masih boleh bekerja dengan produk anda dan anda akan mempunyai masa penimbal yang mencukupi. Anda boleh dengan tenang, tanpa tergesa-gesa, mengambil semua ini dan mengujinya secara setempat, membetulkannya, dan kemudian memuat naik versi baharu. Ia benar-benar masuk akal untuk melakukan ini.
Sekarang mari kita cuba menggabungkan entah bagaimana dua amalan sebelumnya bersama-sama. Kami akan mendapat yang ketiga yang dipanggil Pengurusan Keluaran.
Apabila kita bercakap tentang Deployment Berterusan dalam bentuk klasiknya, kita katakan bahawa kita mesti menarik kod daripada beberapa cawangan daripada repositori, menyusunnya dan menggunakannya. Lagi bagus kalau kita ada persekitaran yang sama. Jika kita mempunyai beberapa persekitaran, ini bermakna kita perlu menarik kod setiap kali, walaupun dari komit yang sama. Kami akan mengeluarkannya setiap kali, kami akan membinanya setiap kali dan kami akan menggunakan ia ke persekitaran baharu. Pertama, inilah masanya, kerana untuk membina projek, jika anda mempunyai projek yang besar dan berasal dari tahun 90-an, maka ia boleh mengambil masa beberapa jam.
Selain itu, ada satu lagi kesedihan. Apabila anda membina, walaupun pada mesin yang sama, anda akan membina sumber yang sama, anda masih tidak mempunyai jaminan bahawa mesin ini berada dalam keadaan yang sama seperti semasa binaan terakhir.
Katakan seseorang masuk dan mengemas kini DotNet untuk anda atau, sebaliknya, seseorang memutuskan untuk memadamkan sesuatu. Dan kemudian anda mempunyai percanggahan kognitif bahawa daripada komit ini dua minggu lalu kami sedang membina binaan dan semuanya baik-baik saja, tetapi kini nampaknya mesin yang sama, komit yang sama, kod yang sama yang kami cuba bina, tetapi ia tidak berfungsi . Anda akan berurusan dengan ini untuk masa yang lama dan bukan fakta bahawa anda akan memikirkannya. Sekurang-kurangnya, anda akan banyak merosakkan saraf anda.
Oleh itu, amalan Pengurusan Keluaran mencadangkan memperkenalkan abstraksi tambahan yang dipanggil repositori artifak atau galeri atau perpustakaan. Anda boleh memanggilnya apa sahaja yang anda mahu.
Idea utama ialah sebaik sahaja kami mempunyai beberapa jenis komitmen di sana, katakan, dalam cawangan yang kami sedia untuk digunakan ke persekitaran kami yang berbeza, kami mengumpul aplikasi daripada komit ini dan semua yang kami perlukan untuk aplikasi ini, kami membungkusnya ke dalam arkib zip dan simpan dalam beberapa storan yang boleh dipercayai. Dan daripada storan ini kita boleh mendapatkan arkib zip ini pada bila-bila masa.
Kemudian kami mengambilnya dan menggunakan secara automatik ke persekitaran dev. Kami berlumba di sana, dan jika semuanya baik, maka kami kerahkan ke pentas. Jika semuanya baik, maka kami menggunakan arkib yang sama untuk pengeluaran, binari yang sama, disusun tepat sekali.
Di samping itu, apabila kami mempunyai galeri seperti ini, ia juga membantu kami menangani risiko yang kami tangani pada slaid terakhir apabila kami bercakap tentang rollback ke versi sebelumnya. Jika anda menggunakan sesuatu yang salah secara tidak sengaja, anda sentiasa boleh mengambil mana-mana versi sebelumnya yang lain daripada galeri ini dan menyahgunakannya ke persekitaran ini dengan cara yang sama. Ini membolehkan anda dengan mudah kembali ke versi sebelumnya jika berlaku masalah.
Terdapat satu lagi amalan yang hebat. Anda dan saya semua faham bahawa apabila kami melancarkan semula aplikasi kami kepada versi sebelumnya, ini mungkin bermakna kami juga memerlukan infrastruktur versi sebelumnya.
Apabila kita bercakap tentang infrastruktur maya, ramai orang berfikir bahawa ini adalah sesuatu yang disediakan oleh pentadbir. Dan jika anda perlu, katakan, untuk mendapatkan pelayan baharu yang mana anda ingin menguji versi baharu aplikasi anda, maka anda mesti menulis tiket kepada pentadbir atau devops. Devops akan mengambil masa 3 minggu untuk ini. Dan selepas 3 minggu mereka akan memberitahu anda bahawa kami telah memasang mesin maya untuk anda, dengan satu teras, dua gigabait RAM dan pelayan Windows tanpa DotNet. Anda berkata: "Tetapi saya mahukan DotNet." Mereka: "Ok, kembali dalam 3 minggu."
Ideanya ialah dengan menggunakan Infrastruktur sebagai amalan Kod, anda boleh menganggap infrastruktur maya anda hanya sebagai sumber lain.
Mungkin, jika mana-mana daripada anda sedang membangunkan aplikasi di DotNet, anda mungkin pernah mendengar tentang perpustakaan yang dipanggil Rangka Kerja Entiti. Dan anda mungkin pernah mendengar bahawa Rangka Kerja Entiti adalah salah satu pendekatan yang didorong oleh Microsoft secara aktif. Untuk bekerja dengan pangkalan data, ini ialah pendekatan yang dipanggil Kod Pertama. Ini adalah apabila anda menerangkan dalam kod bagaimana anda mahu pangkalan data anda kelihatan. Dan kemudian anda menggunakan aplikasi itu. Ia bersambung ke pangkalan data, ia sendiri menentukan jadual mana yang ada dan jadual mana yang tidak, dan mencipta semua yang anda perlukan.
Anda boleh melakukan perkara yang sama dengan infrastruktur anda. Tidak ada perbezaan antara sama ada anda memerlukan pangkalan data untuk projek atau sama ada anda memerlukan pelayan Windows untuk projek. Ia hanya sumber. Dan anda boleh mengautomasikan penciptaan sumber ini, anda boleh mengautomasikan konfigurasi sumber ini. Sehubungan itu, setiap kali anda ingin menguji beberapa konsep baharu, beberapa pendekatan baharu, anda tidak perlu menulis tiket ke devops, anda hanya boleh menggunakan infrastruktur terpencil untuk diri anda daripada templat siap sedia, daripada skrip siap sedia dan melaksanakannya di sana semua percubaan anda. Anda boleh memadam ini, mendapatkan beberapa hasil dan melaporkan lebih lanjut mengenainya.
Amalan seterusnya, yang juga wujud dan juga penting, tetapi yang digunakan oleh segelintir orang, ialah Pemantauan Prestasi Aplikasi.
Saya ingin mengatakan hanya satu perkara tentang Pemantauan Prestasi Aplikasi. Apakah yang paling penting tentang amalan ini? Inilah yang hampir sama dengan Pemantauan Prestasi Aplikasi seperti membaiki apartmen. Ini bukan keadaan akhir, ia adalah satu proses. Anda perlu melakukannya dengan kerap.
Dengan cara yang baik, adalah baik untuk menjalankan Pemantauan Prestasi Aplikasi pada hampir setiap binaan, walaupun, seperti yang anda faham, ini tidak selalu mungkin. Tetapi, sekurang-kurangnya, ia perlu dijalankan untuk setiap keluaran.
Mengapa ia penting? Kerana jika anda tiba-tiba mengalami penurunan prestasi, maka anda perlu memahami dengan jelas mengapa. Jika pasukan anda mempunyai, katakan, pecut dua minggu, maka sekurang-kurangnya sekali setiap dua minggu anda harus menggunakan aplikasi anda ke beberapa pelayan yang berasingan, di mana anda mempunyai pemproses tetap, RAM, cakera, dll. Dan jalankan ujian prestasi yang sama . Anda mendapat hasilnya. Lihat bagaimana ia telah berubah daripada pecut sebelumnya.
Dan jika anda mengetahui bahawa pengeluaran menurun secara mendadak di suatu tempat, ini bermakna ia hanya disebabkan oleh perubahan yang berlaku sepanjang dua minggu yang lalu. Ini akan membolehkan anda mengenal pasti dan menyelesaikan masalah dengan lebih cepat. Dan sekali lagi, ini adalah kira-kira metrik yang sama yang anda boleh mengukur sejauh mana anda berjaya melakukannya.
Amalan seterusnya yang kami ada ialah amalan Pengurusan Konfigurasi. Terdapat sangat sedikit yang mengambil serius perkara ini. Tetapi percayalah, ini sebenarnya perkara yang sangat serius.
Ada cerita lucu baru-baru ini. Lelaki itu datang kepada saya dan berkata: "Bantu kami menjalankan audit keselamatan permohonan kami." Kami melihat kod bersama untuk masa yang lama, mereka memberitahu saya tentang aplikasi itu, melukis gambar rajah. Dan tambah atau tolak semuanya adalah logik, boleh difahami, selamat, tetapi ada satu TETAPI! Mereka mempunyai fail konfigurasi dalam kawalan sumber mereka, termasuk fail dari pengeluaran dengan pangkalan data IP, dengan log masuk dan kata laluan untuk menyambung ke pangkalan data ini, dsb.
Dan saya berkata: "Kawan-kawan, okey, anda telah menutup persekitaran pengeluaran anda dengan tembok api, tetapi hakikat bahawa anda mempunyai log masuk dan kata laluan untuk pangkalan data pengeluaran betul-betul dalam kawalan sumber dan mana-mana pembangun boleh membacanya sudah menjadi risiko keselamatan yang besar. . Dan tidak kira betapa selamatnya aplikasi anda dari sudut pandangan kod, jika anda membiarkannya dalam kawalan sumber, maka anda tidak akan lulus mana-mana audit di mana-mana sahaja.β Itulah yang saya cakapkan.
Pengurusan konfigurasi. Kami mungkin mempunyai konfigurasi yang berbeza dalam persekitaran yang berbeza. Sebagai contoh, kami mungkin mempunyai log masuk dan kata laluan yang berbeza untuk pangkalan data untuk QA, demo, persekitaran pengeluaran, dsb.
Konfigurasi ini juga boleh diautomatikkan. Ia hendaklah sentiasa berasingan daripada aplikasi itu sendiri. kenapa? Oleh kerana anda membina aplikasi sekali, dan kemudian aplikasi itu tidak peduli sama ada anda menyambung ke pelayan SQL melalui IP ini dan itu atau IP ini dan sedemikian, ia sepatutnya berfungsi sama. Oleh itu, jika tiba-tiba salah seorang daripada anda masih mengekod rentetan sambungan dalam kod, maka ingat bahawa saya akan mencari anda dan menghukum anda jika anda mendapati diri anda berada dalam projek yang sama dengan saya. Ini sentiasa diletakkan dalam konfigurasi berasingan, contohnya, dalam web.config.
Dan konfigurasi ini telah pun diuruskan secara berasingan, iaitu ini adalah saat apabila pembangun dan pentadbir boleh datang dan duduk di dalam bilik yang sama. Dan pembangun boleh berkata: "Lihat, berikut adalah binari aplikasi saya. Mereka bekerja. Aplikasi memerlukan pangkalan data untuk berfungsi. Di sini bersebelahan binari terdapat fail. Dalam fail ini, medan ini bertanggungjawab untuk log masuk, ini untuk kata laluan, ini untuk IP. Sebarkan ia di mana-mana sahaja." Dan ia mudah dan jelas kepada pentadbir. Dia boleh menggunakannya di mana-mana sahaja dengan menguruskan konfigurasi ini.
Dan amalan terakhir yang ingin saya bicarakan adalah amalan yang sangat-sangat berkaitan dengan awan. Dan ia membawa kesan maksimum jika anda bekerja di awan. Ini ialah Pembuangan automatik persekitaran anda.
Saya tahu terdapat beberapa orang di persidangan ini daripada pasukan yang saya bekerjasama. Dan dengan semua pasukan yang saya bekerjasama, kami menggunakan amalan ini.
kenapa? Sudah tentu, adalah bagus jika setiap pembangun mempunyai mesin maya yang akan berfungsi 24/7. Tetapi mungkin ini adalah berita kepada anda, mungkin anda tidak memberi perhatian, tetapi pemaju sendiri tidak berfungsi 24/7. Pemaju biasanya bekerja 8 jam sehari. Walaupun dia datang bekerja awal, dia mempunyai makan tengah hari yang besar di mana dia pergi ke gim. Biarkan 12 jam sehari apabila pembangun benar-benar menggunakan sumber ini. Menurut undang-undang kami, kami mempunyai 5 daripada 7 hari dalam seminggu yang dianggap hari bekerja.
Oleh itu, pada hari bekerja mesin ini tidak boleh berfungsi 24 jam, tetapi hanya 12 jam, dan pada hujung minggu mesin ini tidak boleh berfungsi sama sekali. Nampaknya semuanya sangat mudah, tetapi apa yang penting untuk dikatakan di sini? Dengan melaksanakan amalan mudah ini pada jadual asas ini, ia membolehkan anda mengurangkan kos penyelenggaraan persekitaran ini sebanyak 70%, iaitu anda mengambil harga pembangun, QA, demo, persekitaran anda dan membahagikannya dengan 3.
Persoalannya, apa yang perlu dilakukan dengan baki wang itu? Sebagai contoh, pembangun harus membeli ReSharper jika mereka belum melakukannya. Atau buat pesta koktel. Jika anda sebelum ini mempunyai satu persekitaran di mana kedua-dua dev dan QA meragut, dan itu sahaja, kini anda boleh membuat 3 persekitaran berbeza yang akan diasingkan dan orang tidak akan mengganggu satu sama lain.
Mengenai slaid dengan pengukuran prestasi berterusan, bagaimana kita boleh membandingkan prestasi jika kita mempunyai 1 rekod dalam pangkalan data dalam projek, dua bulan kemudian ada sejuta? Bagaimana untuk memahami mengapa dan apa gunanya mengukur prestasi?
Ini adalah soalan yang bagus, kerana anda harus sentiasa mengukur prestasi pada sumber yang sama. Iaitu, anda melancarkan kod baharu, anda mengukur prestasi pada kod baharu. Sebagai contoh, anda perlu menguji senario prestasi yang berbeza, katakan anda ingin menguji prestasi aplikasi pada beban ringan, di mana terdapat 1 pengguna dan saiz pangkalan data ialah 000 gigabait. Anda mengukurnya dan mendapat nombornya. Seterusnya kita ambil senario lain. Contohnya, 5 pengguna, saiz pangkalan data 5 terabait. Kami menerima hasilnya dan mengingatinya.
Apa yang penting di sini? Perkara penting di sini ialah bergantung pada senario, jumlah data, bilangan pengguna serentak, dsb., anda mungkin menghadapi had tertentu. Contohnya, kepada had kad rangkaian, atau kepada had cakera keras, atau kepada had keupayaan pemproses. Inilah yang penting untuk anda fahami. Dalam senario yang berbeza anda menghadapi had tertentu. Dan anda perlu memahami nombor apabila anda memukulnya.
Adakah kita bercakap tentang mengukur prestasi dalam persekitaran ujian khas? Maksudnya, ini bukan pengeluaran?
Ya, ini bukan pengeluaran, ini adalah persekitaran ujian, yang sentiasa sama supaya anda boleh membandingkannya dengan ukuran sebelumnya.
Difahamkan terima kasih!
Jika tiada soalan, saya rasa kita boleh selesaikan. Terima kasih!
Sumber: www.habr.com