Laporan ini akan membahas beberapa praktik DevOps, tetapi dari sudut pandang pengembang. Biasanya, semua insinyur yang bergabung dengan DevOps sudah memiliki pengalaman administratif selama beberapa tahun. Namun bukan berarti tidak ada tempat bagi pengembang di sini. Sering kali, pengembang sibuk memperbaiki “bug penting berikutnya yang mendesak hari ini,” dan mereka bahkan tidak punya waktu untuk melihat sekilas bidang DevOps. Dalam pemahaman penulis, DevOps, pertama, adalah akal sehat. Kedua, ini adalah peluang untuk menjadi lebih efektif. Jika Anda seorang pengembang, memiliki akal sehat, dan ingin menjadi lebih efektif sebagai pemain tim, laporan ini cocok untuk Anda.
Izinkan saya memperkenalkan diri, saya akui sepenuhnya bahwa ada orang di ruangan ini yang tidak mengenal saya. Nama saya Anton Boyko, saya MVP Microsoft Azure. Apa itu MVP? Ini adalah Model-View-Presenter. Model-View-Presenter adalah saya.
Selain itu, saat ini saya juga menjabat sebagai Solution Architect di Ciklum. Dan baru-baru ini saya membeli sendiri domain yang begitu indah, dan memperbarui email saya, yang biasanya saya tampilkan saat presentasi. Anda dapat menulis kepada saya di: saya [anjing] byokoant.pro. Anda dapat mengirim email kepada saya dengan pertanyaan. Saya biasanya menjawabnya. Satu-satunya hal adalah saya tidak ingin menerima pertanyaan melalui email yang berhubungan dengan dua topik: politik dan agama. Anda dapat menulis kepada saya tentang segala hal lainnya melalui email. Beberapa waktu akan berlalu, saya akan menjawab.
Beberapa kata tentang dirimu:
- Saya sudah berkecimpung di bidang ini selama 10 tahun sekarang.
- Saya bekerja di Microsoft.
- Saya adalah pendiri komunitas Azure Ukraina, yang kami dirikan pada tahun 2014. Dan kami masih memilikinya dan sedang mengembangkannya.
- Saya juga ayah dari pendiri konferensi Azure, yang kami selenggarakan di Ukraina.
- Saya juga membantu mengatur Global Azure Bootcamp di Kyiv.
- Seperti yang saya katakan, saya adalah MVP Microsoft Azure.
- Saya cukup sering berbicara di konferensi. Saya sangat suka berbicara di konferensi. Selama setahun terakhir saya mampu tampil sekitar 40 kali. Jika Anda melewati Ukraina, Belarus, Polandia, Bulgaria, Swedia, Denmark, Belanda, Spanyol atau memberi atau menerima negara lain di Eropa, maka sangat mungkin ketika Anda menghadiri konferensi yang bertema cloud di alirannya, Anda mungkin melihat saya di daftar pembicara.
- Saya juga penggemar Star Trek.
Mari kita bicara sedikit tentang Agenda. Agenda kami sangat sederhana:
- Kami akan berbicara tentang apa itu DevOps. Mari kita bahas mengapa ini penting. Sebelumnya, DevOps adalah kata kunci yang Anda tulis di resume Anda dan langsung menerima gaji +$500. Sekarang Anda perlu menulis, misalnya, blockchain di resume Anda untuk mendapatkan +500 dolar untuk gaji Anda.
- Lalu, setelah kita memahami sedikit tentang hal ini, kita akan membahas tentang apa itu praktik DevOps. Namun tidak terlalu banyak dalam konteks DevOps secara umum, melainkan tentang praktik DevOps yang mungkin menarik bagi pengembang. Saya akan memberi tahu Anda mengapa hal itu mungkin menarik bagi Anda. Saya akan memberi tahu Anda mengapa Anda harus melakukan ini dan bagaimana hal ini dapat membantu Anda mengurangi rasa sakit.
Sebuah gambaran tradisional yang diperlihatkan banyak orang. Inilah yang terjadi di banyak proyek. Inilah saatnya kami memiliki departemen pengembangan dan operasi yang mendukung perangkat lunak kami. Dan departemen-departemen ini tidak berkomunikasi satu sama lain.
Mungkin, jika Anda tidak dapat merasakannya dengan jelas di departemen DevOps dan operasi, Anda dapat membuat analogi dengan departemen Dev dan QA. Ada orang yang mengembangkan perangkat lunak dan ada orang QA yang buruk dari sudut pandang pengembang. Misalnya, saya memasukkan kode luar biasa saya ke dalam repositori, dan ada bajingan yang duduk di sana yang mengembalikan kode ini kepada saya dan mengatakan bahwa kode Anda buruk.
Ini semua terjadi karena orang tidak berkomunikasi satu sama lain. Dan mereka melemparkan beberapa paket, beberapa aplikasi satu sama lain melalui dinding kesalahpahaman dan mencoba melakukan sesuatu dengan mereka.
Justru tembok inilah yang dirancang untuk dihancurkan oleh budaya DevOps, yaitu. memaksa orang untuk berkomunikasi satu sama lain dan setidaknya memahami apa yang dilakukan oleh orang-orang yang berbeda dalam proyek dan mengapa pekerjaan mereka penting.
Dan ketika kita berbicara tentang DevOps, seseorang akan memberi tahu Anda bahwa DevOps adalah saat proyek memiliki integrasi berkelanjutan; seseorang akan mengatakan bahwa DevOps adalah jika proyek menerapkan praktik “infrastruktur sebagai kode”; seseorang akan mengatakan bahwa langkah pertama menuju DevOps adalah percabangan fitur, tanda fitur.
Pada dasarnya, semua ini benar dengan caranya masing-masing. Namun ini hanyalah praktik utama yang kami miliki. Sebelum melanjutkan ke praktik ini, saya sarankan untuk melihat slide ini, yang menunjukkan 3 tahap penerapan metodologi Dev-Ops dalam proyek Anda, di perusahaan Anda.
Slide ini juga memiliki nama tidak resmi kedua. Anda dapat mencari secara online untuk mengetahui apa itu 3 Musketeers of DevOps. Mungkin saja Anda akan menemukan artikel ini. Mengapa 3 Musketeer? Di bawahnya tertulis: orang, proses dan produk, mis. PPP – Porthos, Porthos dan Porthos. Berikut adalah 3 penembak DevOps. Artikel ini menjelaskan secara lebih rinci mengapa hal ini penting dan apa saja yang diperlukan.
Saat Anda mulai menerapkan budaya DevOps, sangat penting untuk menerapkannya dalam urutan berikut.
Awalnya Anda perlu berbicara dengan orang-orang. Dan Anda perlu menjelaskan kepada orang-orang apa itu dan bagaimana mereka bisa mendapatkan manfaat darinya.
Konferensi kami disebut DotNet Fest. Dan seperti yang dikatakan penyelenggara kepada saya, kami terutama mengundang audiensi pengembang di sini, jadi saya berharap sebagian besar orang di aula terlibat dalam pengembangan.
Kami akan berbicara tentang orang-orang, kami akan berbicara tentang apa yang ingin dilakukan pengembang setiap hari. Apa yang paling mereka inginkan? Mereka ingin menulis beberapa kode baru, menggunakan kerangka kerja bermodel baru, membuat fitur baru. Apa yang paling tidak diinginkan pengembang? Perbaiki bug lama. Saya harap Anda setuju dengan saya. Inilah yang diinginkan para pengembang. Mereka ingin menulis fitur baru, mereka tidak ingin memperbaiki bug.
Jumlah bug yang dihasilkan pengembang tertentu bergantung pada seberapa lurus lengannya dan seberapa besar bug tersebut tumbuh dari bahunya, dan bukan dari saku pantatnya. Namun demikian, ketika kita memiliki proyek besar, terkadang tidak mungkin untuk melacak semuanya, jadi alangkah baiknya jika kita menggunakan beberapa pendekatan yang akan membantu kita menulis kode yang lebih stabil dan berkualitas lebih tinggi.
Apa yang paling diinginkan QA? Saya tidak tahu apakah mereka ada di aula. Sulit bagi saya untuk mengatakan bahwa saya menginginkan QA, karena saya belum pernah melakukannya. Dan jangan tersinggung teman-teman, akan dikatakan bahwa saya harap saya tidak akan pernah melakukannya. Tetapi bukan karena saya menganggap pekerjaan mereka tidak ada artinya dan tidak berguna, tetapi karena saya tidak menganggap diri saya orang yang dapat melakukan pekerjaan ini dengan efisien, jadi saya bahkan tidak akan mencoba melakukannya. Tapi dari apa yang saya pahami, apa yang paling tidak disukai QA adalah bekerja di pagi hari, terus-menerus menjalankan semacam tes regresi, menginjak bug yang sama yang mereka laporkan ke pengembang 3 sprint yang lalu dan berkata: “Kapan kamu akan melakukannya? , Tuan D 'Artagnan, perbaiki bug ini.' Dan Monsieur D'Artagnan menjawabnya: "Ya, ya, ya, saya sudah memperbaikinya." Dan bagaimana saya bisa memperbaiki satu bug dan membuat 5 bug di sepanjang jalan.
Orang-orang yang mendukung solusi ini dalam produksi ingin solusi ini bekerja tanpa bug, sehingga mereka tidak perlu me-reboot server setiap hari Jumat, ketika semua orang normal pergi ke bar. Pengembang menerapkan pada hari Jumat, admin duduk hingga hari Sabtu, mencoba untuk menerapkan dan memperbaiki penerapan ini.
Dan ketika Anda menjelaskan kepada orang-orang bahwa mereka bertujuan untuk memecahkan masalah yang sama, Anda dapat melanjutkan ke formalisasi prosesnya. Ini sangat penting. Mengapa? Karena ketika kami mengatakan “formalisasi,” penting bagi Anda untuk menggambarkan bagaimana proses Anda terjadi setidaknya di suatu tempat di atas serbet. Anda perlu memahami bahwa jika Anda, misalnya, menerapkan ke lingkungan QA atau lingkungan produksi, maka hal itu selalu terjadi dalam urutan ini; pada tahap ini kami menjalankan, misalnya, pengujian unit otomatis dan pengujian UI. Setelah penerapan, kami memeriksa apakah penerapan berjalan dengan baik atau buruk. Namun Anda sudah memiliki daftar tindakan yang jelas yang harus diulang berulang kali saat Anda menerapkannya ke produksi.
Dan hanya ketika proses Anda diformalkan, barulah Anda mulai memilih produk yang akan membantu Anda mengotomatiskan proses ini.
Sayangnya, saya sering melihat hal ini terjadi secara terbalik. Begitu seseorang mendengar kata “DevOps”, mereka langsung menyarankan untuk menginstal Jenkins, karena mereka percaya bahwa begitu mereka menginstal Jenkins, mereka akan memiliki DevOps. Mereka menginstal Jenkins, membaca artikel “Cara” di situs web Jenkins, mencoba memasukkan proses ke dalam artikel Cara ini, lalu mendatangi orang-orang dan membujuk orang-orang, mengatakan bahwa buku tersebut mengatakan bahwa Anda perlu melakukannya dengan cara ini, jadi kami melakukannya dengan cara ini.
Bukan berarti Jenkins adalah alat yang buruk. Saya tidak bermaksud mengatakan itu dengan cara apa pun. Tapi ini hanyalah salah satu produknya. Dan produk mana yang Anda gunakan harus menjadi keputusan terakhir Anda, dan bukan yang pertama. Produk Anda tidak boleh didorong oleh penerapan budaya dan pendekatan. Ini sangat penting untuk dipahami, itulah sebabnya saya menghabiskan begitu banyak waktu pada slide ini dan menjelaskan semua ini begitu lama.
Mari kita bahas tentang praktik DevOps secara umum. Apakah mereka? Apa bedanya? Bagaimana cara mencobanya? Mengapa hal tersebut penting?
Praktik pertama yang mungkin pernah Anda dengar disebut Integrasi Berkelanjutan. Mungkin seseorang di proyek tersebut memiliki Continuous Integration (CI).
Masalah terbesar adalah yang paling sering terjadi ketika saya bertanya kepada seseorang: “Apakah Anda memiliki CI di proyek tersebut?” dan dia berkata: "Ya," lalu ketika saya bertanya apa yang dia lakukan, dia menjelaskan kepada saya seluruh proses otomatisasi. Hal ini tidak sepenuhnya benar.
Faktanya, praktik CI hanya bertujuan untuk mengintegrasikan kode yang ditulis oleh berbagai orang ke dalam basis kode tunggal. Itu saja.
Selain CI, biasanya ada praktik lain yang juga dilakukan - seperti Penerapan Berkelanjutan, Manajemen Rilis, namun kita akan membicarakannya nanti.
CI sendiri memberi tahu kita bahwa orang yang berbeda menulis kode dan kode ini harus terus diintegrasikan ke dalam satu basis kode.
Apa manfaatnya bagi kita dan mengapa ini penting? Kalau kita punya DotNet, baguslah, itu bahasa yang dikompilasi, kita bisa mengkompilasi aplikasi kita. Jika dikompilasi, maka ini pertanda baik. Ini belum berarti apa-apa, tapi ini pertanda baik pertama yang setidaknya bisa kita kumpulkan.
Kemudian kita bisa menjalankan beberapa tes, yang juga merupakan latihan tersendiri. Semua tes berwarna hijau – ini adalah pertanda baik kedua. Tapi sekali lagi, ini tidak berarti apa-apa.
Tapi kenapa kamu melakukan ini? Semua amalan yang akan saya bicarakan hari ini memiliki nilai yang kurang lebih sama, yaitu manfaat yang kurang lebih sama dan juga diukur dengan cara yang kurang lebih sama.
Pertama, ini memungkinkan Anda mempercepat pengiriman. Bagaimana hal ini memungkinkan Anda mempercepat pengiriman? Ketika kita membuat beberapa perubahan baru pada basis kode kita, kita dapat segera mencoba melakukan sesuatu dengan kode ini. Kami tidak menunggu sampai hari Kamis tiba karena hari Kamis kami rilis ke QA Environment, kami melakukannya di sini dan di sini.
Saya akan menceritakan satu kisah sedih dalam hidup saya. Itu sudah lama sekali, ketika saya masih muda dan tampan. Sekarang saya sudah muda, cantik, pintar, dan rendah hati. Beberapa waktu yang lalu saya sedang dalam sebuah proyek. Kami memiliki tim besar yang terdiri dari sekitar 30 pengembang. Dan kami memiliki proyek Perusahaan yang sangat besar yang berkembang selama sekitar 10 tahun. Dan kami memiliki cabang yang berbeda. Di repositori kami memiliki cabang tempat pengembang berjalan. Dan ada cabang yang menampilkan versi kode yang sedang diproduksi.
Cabang produksi tertinggal 3 bulan dari cabang yang tersedia untuk pengembang. Apa artinya ini? Artinya, segera setelah saya memiliki bug di suatu tempat yang masuk ke produksi karena kesalahan pengembang, karena mereka mengizinkannya, dan karena kesalahan QA, karena mereka melihatnya, maka ini berarti jika saya menerima a tugas untuk perbaikan terbaru untuk produksi, maka saya harus mengembalikan perubahan kode saya 3 bulan yang lalu. Saya harus mengingat apa yang saya alami 3 bulan lalu dan mencoba memperbaikinya di sana.
Jika Anda belum memiliki pengalaman ini, Anda dapat mencobanya pada proyek rumah Anda. Pokoknya, jangan coba-coba di komersial. Tulis beberapa baris kode, lupakan selama enam bulan, lalu kembali lagi dan coba jelaskan dengan cepat tentang baris kode tersebut dan bagaimana Anda dapat memperbaiki atau mengoptimalkannya. Ini adalah pengalaman yang sangat, sangat menarik.
Jika kita memiliki praktik Integrasi Berkelanjutan, maka ini memungkinkan kita untuk memeriksanya dengan sejumlah alat otomatis di sini dan saat ini, segera setelah saya menulis kode saya. Ini mungkin tidak memberi saya gambaran lengkap, namun demikian, ini akan menghilangkan setidaknya beberapa risiko. Dan jika ada potensi bug, saya akan mengetahuinya sekarang, dalam beberapa menit. Saya tidak perlu memutar kembali 3 bulan. Saya hanya perlu memutar kembali 2 menit. Mesin kopi yang bagus bahkan tidak punya waktu untuk menyeduh kopi dalam 2 menit, jadi itu keren.
Hal ini memiliki nilai yang dapat diulangi dari waktu ke waktu pada setiap proyek, mis. bukan hanya tempat Anda mengaturnya. Anda dapat mengulangi praktik itu sendiri dan CI itu sendiri akan diulangi untuk setiap perubahan baru yang Anda buat pada proyek. Hal ini memungkinkan Anda mengoptimalkan sumber daya karena tim Anda bekerja lebih efisien. Anda tidak akan lagi menghadapi situasi di mana bug datang kepada Anda dari kode yang Anda gunakan 3 bulan lalu. Anda tidak akan lagi mengalami peralihan konteks ketika Anda duduk dan menghabiskan dua jam pertama mencoba memahami apa yang terjadi kemudian dan memahami inti konteksnya sebelum Anda mulai mengoreksi sesuatu.
Bagaimana kita mengukur keberhasilan atau kegagalan praktik ini? Jika Anda melaporkan kepada bos besar apa yang kami terapkan pada proyek CI, dia akan mendengar bla bla bla. Kita menerapkannya, oke, tapi mengapa, apa dampaknya bagi kita, bagaimana kita mengukurnya, seberapa benar atau salahnya kita menerapkannya?
Yang pertama adalah, berkat CI, kami dapat melakukan penerapan lebih sering, dan lebih sering lagi, justru karena kode kami berpotensi lebih stabil. Dengan cara yang sama, waktu kita untuk menemukan kesalahan berkurang dan waktu untuk memperbaiki kesalahan ini berkurang justru karena kita menerima jawaban dari sistem di sini dan saat ini, apa yang salah dengan kode kita.
Praktik lain yang kami miliki adalah praktik Pengujian Otomasi, yang paling sering disertakan dengan praktik CI. Mereka berjalan beriringan.
Apa yang penting untuk dipahami di sini? Penting untuk dipahami bahwa pengujian kami berbeda. Dan setiap pengujian otomatis ditujukan untuk memecahkan masalahnya sendiri. Kami memiliki, misalnya, pengujian unit yang memungkinkan kami menguji modul secara terpisah, mis. Bagaimana cara kerjanya dalam ruang hampa? Ini bagus.
Kami juga memiliki tes integrasi yang memungkinkan kami memahami bagaimana berbagai modul berintegrasi satu sama lain. Itu juga bagus.
Kami mungkin memiliki pengujian otomatisasi UI yang memungkinkan kami memeriksa seberapa baik pekerjaan dengan UI memenuhi persyaratan tertentu yang ditetapkan oleh pelanggan, dll.
Tes spesifik yang Anda jalankan dapat memengaruhi seberapa sering Anda menjalankannya. Tes unit biasanya ditulis pendek dan kecil. Dan mereka dapat diluncurkan secara rutin.
Jika kita berbicara tentang pengujian otomatisasi UI, ada baiknya jika proyek Anda kecil. Pengujian otomatisasi UI Anda mungkin memerlukan waktu yang cukup lama. Namun biasanya pengujian otomatisasi UI membutuhkan waktu beberapa jam pada proyek besar. Dan ada baiknya jika beberapa jam. Satu-satunya hal adalah tidak ada gunanya menjalankannya untuk setiap build. Masuk akal untuk menjalankannya di malam hari. Dan ketika semua orang mulai bekerja di pagi hari: baik penguji maupun pengembang, mereka menerima semacam laporan bahwa kami menjalankan tes otomatis UI di malam hari dan mendapatkan hasil ini. Dan di sini, satu jam kerja server yang akan memeriksa apakah produk Anda memenuhi beberapa persyaratan akan jauh lebih murah daripada satu jam kerja insinyur QA yang sama, meskipun dia adalah insinyur QA Junior yang bekerja untuk makanan dan terima kasih. Meski begitu, satu jam pengoperasian mesin akan lebih murah. Inilah mengapa masuk akal untuk berinvestasi di dalamnya.
Saya memiliki proyek lain yang sedang saya kerjakan. Kami melakukan sprint selama dua minggu untuk proyek ini. Proyek ini besar, penting bagi sektor keuangan, dan tidak boleh ada kesalahan. Dan setelah sprint selama dua minggu, siklus pengembangan dilanjutkan dengan proses pengujian, yang memakan waktu 4 minggu berikutnya. Coba bayangkan skala tragedi tersebut. Kami menulis kode selama dua minggu, kemudian kami melakukannya ala CodeFreeze, mengemasnya ke dalam versi aplikasi yang baru, dan meluncurkannya ke penguji. Penguji mengujinya selama 4 minggu lagi, mis. Selagi mereka mengujinya, kami punya waktu untuk menyiapkan dua versi lagi untuk mereka. Ini adalah kasus yang sangat menyedihkan.
Dan kami memberi tahu mereka bahwa jika Anda ingin menjadi lebih produktif, masuk akal bagi Anda untuk menerapkan praktik Pengujian Otomatis, karena inilah yang merugikan Anda saat ini.
Berlatih Penerapan Berkelanjutan. Bagus, Anda sudah selesai membangun. Ini sudah bagus. Kode Anda telah dikompilasi. Sekarang akan menyenangkan untuk menerapkan build ini di beberapa lingkungan. Katakanlah di lingkungan untuk pengembang.
Mengapa ini penting? Pertama, Anda dapat melihat seberapa sukses Anda dengan proses penerapan itu sendiri. Saya telah bertemu proyek seperti ini, ketika saya bertanya: “Bagaimana cara menerapkan versi baru aplikasi?”, orang-orang tersebut memberi tahu saya: “Kami merakitnya dan mengemasnya ke dalam arsip zip. Kami mengirimkannya ke admin melalui surat. Admin mengunduh dan memperluas arsip ini. Dan seluruh kantor mulai berdoa agar server dapat mengambil versi baru.”
Mari kita mulai dengan sesuatu yang sederhana. Misalnya saja mereka lupa memasukkan CSS ke dalam arsip atau lupa mengganti hashtag pada nama file java-script. Dan ketika kita membuat permintaan ke server, browser mengira ia sudah memiliki file java-script ini dan memutuskan untuk tidak mendownloadnya. Dan ada versi lama, ada yang hilang. Secara umum, mungkin terdapat banyak masalah. Oleh karena itu, praktik Penerapan Berkelanjutan memungkinkan Anda setidaknya menguji apa yang akan terjadi jika Anda mengambil gambar referensi yang bersih dan mengunggahnya ke lingkungan baru yang benar-benar bersih. Anda dapat melihat ke mana arahnya.
Juga, ketika Anda mengintegrasikan kode satu sama lain, mis. di antara perintah, ini memungkinkan Anda juga melihat tampilannya di UI.
Salah satu masalah yang terjadi jika banyak menggunakan java-script vanilla adalah dua pengembang secara terburu-buru mendeklarasikan variabel dengan nama yang sama pada objek window. Dan kemudian, tergantung pada keberuntungan Anda. File java-script siapa yang ditarik keluar kedua akan menimpa perubahan yang lain. Ini juga sangat menarik. Anda masuk: satu hal berhasil untuk satu orang, hal lain tidak berhasil untuk orang lain. Dan sungguh “luar biasa” ketika semuanya keluar dalam produksi.
Praktek selanjutnya yang kita lakukan adalah praktek Automatic Restore yaitu melakukan rollback ke aplikasi versi sebelumnya.
Mengapa ini penting bagi pengembang? Masih ada orang yang mengingat tahun 90-an yang sangat jauh, ketika komputer masih berukuran besar dan program masih berukuran kecil. Dan satu-satunya cara untuk mengembangkan web adalah melalui PHP. Bukan berarti PHP adalah bahasa yang buruk, meskipun memang demikian.
Tapi masalahnya berbeda. Saat kami menerapkan versi baru situs php kami, bagaimana kami menerapkannya? Paling sering kami membuka Far Manager atau yang lainnya. Dan mengunggah file-file ini ke FTP. Dan tiba-tiba kami menyadari bahwa kami memiliki beberapa bug yang sangat kecil, misalnya kami lupa memberi tanda titik koma atau lupa mengganti kata sandi untuk database, dan ada kata sandi untuk database, yang ada di host lokal. Dan kami memutuskan untuk segera terhubung ke FTP dan mengedit file di sana. Ini hanyalah api! Inilah yang populer di tahun 90an.
Tapi, kalau belum melihat kalender, tahun 90an sudah hampir 30 tahun yang lalu. Sekarang semuanya terjadi sedikit berbeda. Dan coba bayangkan skala tragedi tersebut ketika mereka memberi tahu Anda: “Kami mulai melakukan produksi, tetapi ada yang tidak beres di sana. Ini login dan kata sandi FTP Anda, sambungkan ke produksi dan segera perbaiki di sana.” Jika Anda Chuck Norris, ini akan berhasil. Jika tidak, maka Anda berisiko jika Anda memperbaiki satu bug, Anda akan mendapatkan 10 bug lagi.Inilah mengapa praktik mengembalikan ke versi sebelumnya memungkinkan Anda mencapai banyak hal.
Bahkan jika sesuatu yang buruk entah bagaimana terjadi di suatu tempat, itu buruk, tapi tidak fatal. Anda dapat memutar kembali ke versi sebelumnya yang Anda miliki. Sebut saja cadangan, jika lebih mudah untuk memahaminya dalam terminologi tersebut. Anda dapat memutar kembali ke versi sebelumnya, dan pengguna masih dapat bekerja dengan produk Anda, dan Anda akan memiliki waktu buffer yang memadai. Anda dapat dengan tenang, tanpa tergesa-gesa, mengambil semua ini dan mengujinya secara lokal, memperbaikinya, lalu mengunggah versi baru. Sangat masuk akal untuk melakukan ini.
Sekarang mari kita coba menggabungkan dua praktik sebelumnya. Kami akan mendapatkan yang ketiga yang disebut Manajemen Rilis.
Ketika kita berbicara tentang Penerapan Berkelanjutan dalam bentuk klasiknya, kita mengatakan bahwa kita harus menarik kode dari beberapa cabang dari repositori, mengompilasinya, dan menerapkannya. Ada baiknya jika kita memiliki lingkungan yang sama. Jika kita memiliki beberapa lingkungan, ini berarti kita harus menarik kode setiap saat, bahkan dari commit yang sama. Kami akan mengeluarkannya setiap saat, kami akan membangunnya setiap saat, dan kami akan menerapkannya ke lingkungan baru. Pertama, ini saatnya, karena untuk membangun sebuah proyek, jika Anda punya proyek besar dan berasal dari tahun 90-an, maka bisa memakan waktu beberapa jam.
Selain itu, ada kesedihan lainnya. Saat Anda membangun, bahkan pada mesin yang sama, Anda akan membangun sumber yang sama, Anda tetap tidak memiliki jaminan bahwa mesin ini berada dalam kondisi yang sama seperti pada pembuatan terakhir.
Katakanlah seseorang masuk dan memperbarui DotNet untuk Anda atau, sebaliknya, seseorang memutuskan untuk menghapus sesuatu. Dan kemudian Anda memiliki disonansi kognitif bahwa dari penerapan ini dua minggu lalu kami sedang membangun sebuah build dan semuanya baik-baik saja, tetapi sekarang sepertinya mesin yang sama, penerapan yang sama, kode yang sama yang kami coba buat, tetapi tidak berfungsi . Anda akan menghadapi hal ini untuk waktu yang lama dan bukan fakta bahwa Anda akan mengetahuinya. Paling tidak, Anda akan sangat merusak saraf Anda.
Oleh karena itu, praktik Manajemen Rilis menyarankan untuk memperkenalkan abstraksi tambahan yang disebut repositori artefak, galeri, atau perpustakaan. Anda dapat menyebutnya apa pun yang Anda inginkan.
Ide utamanya adalah segera setelah kami memiliki semacam komitmen di sana, katakanlah, di cabang yang siap kami terapkan ke lingkungan kami yang berbeda, kami mengumpulkan aplikasi dari komitmen ini dan semua yang kami butuhkan untuk aplikasi ini, kami mengemasnya ke dalam arsip zip dan menyimpannya di beberapa penyimpanan yang dapat diandalkan. Dan dari penyimpanan ini kita bisa mendapatkan arsip zip ini kapan saja.
Kemudian kami mengambilnya dan secara otomatis menerapkannya ke lingkungan pengembang. Kami berlomba di sana, dan jika semuanya baik-baik saja, maka kami turunkan ke panggung. Jika semuanya baik-baik saja, maka kami menyebarkan arsip yang sama ke produksi, biner yang sama, dikompilasi tepat satu kali.
Selain itu, ketika kami memiliki galeri seperti ini, ini juga membantu kami mengatasi risiko yang kami bahas pada slide terakhir ketika kami berbicara tentang rollback ke versi sebelumnya. Jika Anda tidak sengaja menerapkan sesuatu yang salah, Anda selalu dapat mengambil versi sebelumnya lainnya dari galeri ini dan membatalkan penerapannya ke lingkungan ini dengan cara yang sama. Ini memungkinkan Anda dengan mudah memutar kembali ke versi sebelumnya jika terjadi kesalahan.
Ada latihan bagus lainnya. Anda dan saya semua memahami bahwa saat kita mengembalikan aplikasi ke versi sebelumnya, ini mungkin berarti kita juga memerlukan infrastruktur versi sebelumnya.
Ketika kita berbicara tentang infrastruktur virtual, banyak orang berpikir bahwa ini adalah sesuatu yang diatur oleh admin. Dan jika Anda perlu, katakanlah, untuk mendapatkan server baru di mana Anda ingin menguji versi baru aplikasi Anda, maka Anda harus menulis tiket ke admin atau devops. Devops akan memakan waktu 3 minggu untuk ini. Dan setelah 3 minggu mereka akan memberitahu Anda bahwa kami telah menginstal mesin virtual untuk Anda, dengan satu inti, dua gigabyte RAM dan server Windows tanpa DotNet. Anda berkata: “Tetapi saya menginginkan DotNet.” Mereka: “Oke, kembalilah dalam 3 minggu.”
Idenya adalah dengan menggunakan praktik Infrastruktur sebagai Kode, Anda dapat memperlakukan infrastruktur virtual Anda hanya sebagai sumber daya lain.
Mungkin, jika ada di antara Anda yang mengembangkan aplikasi di DotNet, Anda mungkin pernah mendengar tentang perpustakaan bernama Entity Framework. Dan Anda mungkin pernah mendengar bahwa Entity Framework adalah salah satu pendekatan yang secara aktif didorong oleh Microsoft. Untuk bekerja dengan database, pendekatan ini disebut Code First. Ini adalah saat Anda menjelaskan dalam kode bagaimana Anda ingin database Anda terlihat. Dan kemudian Anda menyebarkan aplikasi tersebut. Itu terhubung ke database, itu sendiri menentukan tabel mana yang ada dan tabel mana yang tidak, dan membuat semua yang Anda butuhkan.
Anda dapat melakukan hal yang sama dengan infrastruktur Anda. Tidak ada perbedaan antara apakah Anda memerlukan database untuk suatu proyek atau apakah Anda memerlukan server Windows untuk suatu proyek. Itu hanya sumber daya. Dan Anda dapat mengotomatiskan pembuatan sumber daya ini, Anda dapat mengotomatiskan konfigurasi sumber daya ini. Oleh karena itu, setiap kali Anda ingin menguji beberapa konsep baru, beberapa pendekatan baru, Anda tidak perlu menulis tiket ke devops, Anda cukup menerapkan infrastruktur terisolasi untuk diri Anda sendiri dari templat yang sudah jadi, dari skrip yang sudah jadi, dan mengimplementasikannya. itu semua eksperimenmu. Anda dapat menghapus ini, mendapatkan beberapa hasil dan melaporkannya lebih lanjut.
Praktek selanjutnya yang juga ada dan juga penting namun jarang digunakan orang adalah Application Performance Monitoring.
Saya hanya ingin mengatakan satu hal tentang Pemantauan Kinerja Aplikasi. Apa yang paling penting dari praktik ini? Inilah yang dimaksud dengan Application Performance Monitoring yang hampir sama dengan memperbaiki apartemen. Ini bukanlah sebuah keadaan final, ini adalah sebuah proses. Anda perlu melakukannya secara teratur.
Dalam cara yang baik, sebaiknya lakukan Pemantauan Kinerja Aplikasi di hampir setiap build, meskipun, seperti yang Anda pahami, hal ini tidak selalu memungkinkan. Namun minimal perlu dilakukan pada setiap rilis.
Mengapa ini penting? Karena jika Anda tiba-tiba mengalami penurunan performa, maka Anda perlu memahami dengan jelas penyebabnya. Jika tim Anda memiliki, katakanlah, sprint dua minggu, maka setidaknya sekali setiap dua minggu Anda harus menyebarkan aplikasi Anda ke beberapa server terpisah, di mana Anda memiliki prosesor, RAM, disk, dll. Dan jalankan tes kinerja yang sama . Anda mendapatkan hasilnya. Lihat perubahannya dari sprint sebelumnya.
Dan jika ternyata drawdownnya turun tajam di suatu tempat, itu berarti itu hanya karena perubahan yang terjadi selama dua minggu terakhir. Ini akan memungkinkan Anda mengidentifikasi dan memperbaiki masalah lebih cepat. Dan sekali lagi, ini kira-kira merupakan metrik yang sama yang dapat digunakan untuk mengukur seberapa sukses Anda melakukannya.
Praktik selanjutnya yang kami miliki adalah praktik Manajemen Konfigurasi. Sangat sedikit orang yang menganggap hal ini serius. Tapi percayalah, ini sebenarnya adalah hal yang sangat serius.
Ada cerita lucu baru-baru ini. Orang-orang itu mendatangi saya dan berkata: “Bantu kami melakukan audit keamanan terhadap aplikasi kami.” Kami melihat kodenya bersama untuk waktu yang lama, mereka memberi tahu saya tentang aplikasinya, menggambar diagram. Dan plus atau minusnya semuanya logis, bisa dimengerti, aman, tapi ada satu TAPI! Mereka memiliki file konfigurasi di kontrol sumbernya, termasuk yang berasal dari produksi dengan database IP, dengan login dan kata sandi untuk menghubungkan ke database ini, dll.
Dan saya berkata: “Teman-teman, oke, Anda telah menutup lingkungan produksi Anda dengan firewall, tetapi fakta bahwa Anda memiliki login dan kata sandi untuk database produksi tepat di kontrol sumber dan pengembang mana pun dapat membacanya sudah merupakan risiko keamanan yang sangat besar. . Dan betapapun super amannya aplikasi Anda dari sudut pandang kode, jika Anda membiarkannya dalam kendali sumber, Anda tidak akan pernah lulus audit apa pun di mana pun.” Itulah yang saya bicarakan.
Manajemen konfigurasi. Kami mungkin memiliki konfigurasi berbeda di lingkungan berbeda. Misalnya, kami mungkin memiliki login dan kata sandi yang berbeda untuk database untuk QA, demo, lingkungan produksi, dll.
Konfigurasi ini juga dapat diotomatisasi. Itu harus selalu terpisah dari aplikasi itu sendiri. Mengapa? Karena Anda membuat aplikasinya satu kali, lalu aplikasi tersebut tidak peduli apakah Anda terhubung ke server SQL melalui IP ini dan itu atau IP ini dan itu, seharusnya cara kerjanya sama. Oleh karena itu, jika tiba-tiba salah satu dari Anda masih melakukan hardcoding pada string koneksi dalam kode tersebut, maka ingatlah bahwa saya akan menemukan Anda dan menghukum Anda jika Anda berada pada proyek yang sama dengan saya. Ini selalu ditempatkan dalam konfigurasi terpisah, misalnya di web.config.
Dan konfigurasi ini sudah dikelola secara terpisah, yaitu saat inilah pengembang dan administrator dapat datang dan duduk di ruangan yang sama. Dan pengembang dapat berkata: “Lihat, ini biner aplikasi saya. Mereka bekerja. Aplikasi memerlukan database agar dapat berfungsi. Di sini, di sebelah binari ada file. Dalam file ini, bidang ini bertanggung jawab untuk login, ini untuk kata sandi, ini untuk IP. Sebarkan di mana saja." Dan itu sederhana dan jelas bagi admin. Dia dapat menerapkannya di mana saja dengan mengelola konfigurasi ini.
Dan amalan terakhir yang ingin saya bahas adalah amalan yang sangat-sangat berkaitan dengan awan. Dan ini memberikan efek maksimal jika Anda bekerja di cloud. Ini adalah penghapusan otomatis lingkungan Anda.
Saya tahu ada beberapa orang di konferensi ini dari tim tempat saya bekerja. Dan dengan semua tim tempat saya bekerja, kami menggunakan latihan ini.
Mengapa? Tentu saja, akan sangat bagus jika setiap pengembang memiliki mesin virtual yang dapat bekerja 24/7. Tapi mungkin ini berita baru bagi Anda, mungkin Anda tidak memperhatikannya, tetapi pengembangnya sendiri tidak bekerja 24/7. Seorang pengembang biasanya bekerja 8 jam sehari. Bahkan jika dia datang bekerja lebih awal, dia makan siang yang banyak sambil pergi ke gym. Biarkan 12 jam sehari ketika pengembang benar-benar menggunakan sumber daya ini. Menurut undang-undang kami, kami memiliki 5 dari 7 hari dalam seminggu yang dianggap sebagai hari kerja.
Oleh karena itu, pada hari kerja mesin ini tidak boleh bekerja 24 jam, melainkan hanya 12 jam, dan pada akhir pekan mesin ini tidak boleh bekerja sama sekali. Tampaknya semuanya sangat sederhana, tetapi apa yang penting untuk dikatakan di sini? Dengan menerapkan praktik sederhana ini pada jadwal dasar ini, Anda dapat mengurangi biaya pemeliharaan lingkungan ini sebesar 70%, yaitu Anda mengambil harga dev, QA, demo, lingkungan dan membaginya dengan 3.
Pertanyaannya adalah, apa yang harus dilakukan dengan sisa uang itu? Misalnya, pengembang harus membeli ReSharper jika mereka belum melakukannya. Atau mengadakan pesta koktail. Jika sebelumnya Anda memiliki satu lingkungan tempat dev dan QA bekerja, dan hanya itu, sekarang Anda dapat membuat 3 lingkungan berbeda yang akan diisolasi, dan orang-orang tidak akan saling mengganggu.
Mengenai slide dengan pengukuran kinerja berkelanjutan, bagaimana kita bisa membandingkan kinerja jika kita memiliki 1 catatan di database dalam proyek, dua bulan kemudian ada satu juta? Bagaimana memahami mengapa dan apa gunanya mengukur kinerja?
Ini adalah pertanyaan yang bagus, karena Anda harus selalu mengukur kinerja pada sumber daya yang sama. Artinya, Anda meluncurkan kode baru, Anda mengukur kinerja pada kode baru. Misalnya, Anda perlu menguji berbagai skenario kinerja, katakanlah Anda ingin menguji bagaimana kinerja aplikasi pada beban ringan, di mana terdapat 1 pengguna dan ukuran database adalah 000 gigabyte. Anda mengukurnya dan mendapatkan angkanya. Selanjutnya kita mengambil skenario lain. Misalnya 5 pengguna, ukuran database 5 terabyte. Kami menerima hasilnya dan mengingatnya.
Apa yang penting di sini? Yang penting di sini adalah bergantung pada skenario, volume data, jumlah pengguna secara bersamaan, dll., Anda mungkin mengalami batasan tertentu. Misalnya saja sampai batas kartu jaringan, atau sampai batas harddisk, atau sampai batas kemampuan prosesor. Inilah yang penting untuk Anda pahami. Dalam skenario yang berbeda, Anda mengalami batasan tertentu. Dan Anda perlu memahami angka-angka saat Anda menekannya.
Apakah kita berbicara tentang mengukur kinerja dalam lingkungan pengujian khusus? Artinya, ini bukan produksi?
Ya, ini bukan produksi, ini adalah lingkungan pengujian yang selalu sama sehingga dapat dibandingkan dengan pengukuran sebelumnya.
Dimengerti terima kasih!
Jika tidak ada pertanyaan, saya pikir kita bisa menyelesaikannya. Terima kasih!
Sumber: www.habr.com