DevOps: apa itu sebenarnya?

Halo semuanya!

Kami telah mencetak buku "DevOps Philosophy", dan kami juga berencana membuat buku baru tentang hal ini.


Banyak salinan yang dipecah tentang apa yang DevOps adalah dan tidak, serta hubungan antara DevOps dan integrasi berkelanjutan. Oleh karena itu, kami meminta Anda untuk berbicara seobjektif mungkin, apakah Anda berbagi sudut pandang penulis hari ini Adam Mackay (Adam Mackay) mengenai esensi DevOps - atau, menurut Anda, gambar yang ia usulkan agak tidak lengkap atau bias?

Kami membaca dan berkomentar!

Saya telah bekerja di bidang teknologi sepanjang hidup saya, dan tepat di depan mata saya beberapa metodologi pengembangan perangkat lunak telah matang dan terbentuk. Sebagian besar ide yang mendasari mereka datang ke optimasi produktivitas biasa dalam semangat akal sehat dan dipinjam dari berbagai sektor ekonomi. Beberapa tahun yang lalu, semua orang ingin beralih dari model pengembangan air terjun ke Agile, pengembangan tangkas. Saya baru-baru ini pergi bekerja di perusahaan progresif, di mana mereka mencoba menerapkan DevOps. Perusahaan ini, Verifa, telah lama berpegang teguh pada Agile dan berusaha memperluas keunggulan model ini tidak hanya pada pengembangan perangkat lunak, tetapi juga pada bisnis secara keseluruhan.

DevOps adalah kata kunci baru dalam industri perangkat lunak. Konsep ini menggabungkan banyak ide-ide bagus tentang mengintegrasikan bisnis dan pengembangan, serta merumuskan narasi yang memungkinkan kita berbicara tentang pengembangan, pengiriman, dan pengoperasian perangkat lunak dalam satu konteks.



DevOps adalah pendekatan di mana insinyur pengembangan dan insinyur administrasi berpartisipasi bersama dalam seluruh siklus hidup produk perangkat lunak, mulai dari desain dan pengembangan hingga dukungan produk yang menyeluruh. Dengan demikian, DevOps dirancang untuk menghilangkan perpecahan tradisional, di mana satu tim menulis kode, yang lain mengujinya, menyebarkan ketiga, dan yang keempat bertanggung jawab untuk operasi.

Dengan DevOps, karyawan sysadmin mulai digunakan, dengan dukungan sistem yang dipercayakan kepada mereka, banyak teknik yang telah diperbaiki di gudang pengembang. Di DevOps, rekayasa sistem dibangun persis seperti aliran tugas selama pengembangan. Semua sumber daya dimasukkan ke dalam sistem akuntansi sumber dan dicakup oleh tes yang sesuai.

Kami memiliki beberapa topik utama DevOps di perusahaan kami: nilai, prinsip, metode, praktik, dan alat.



Nilai-nilai

Setiap insinyur dipenjara karena menemukan solusi, dan aspirasi semacam itu kadang-kadang diterjemahkan menjadi penolakan terhadap teknologi baru, keengganan untuk bereksperimen dengan hal-hal baru, yang diekspresikan dengan cara yang berbeda: dari sindrom "penolakan pengembangan orang lain" hingga upaya kontraproduktif untuk mempertahankan ceruk seseorang. Untuk benar-benar bertransisi ke DevOps, prasangka-prasangka ini pertama-tama harus diakui dan kemudian diatasi. Tidak ada teknologi, atau Docker, Kubernetes, atau Amazon Web Services yang akan menyelesaikan masalah Anda jika Anda tidak mengerti apa nilai proposisi itu.



"Pegang tangan teman-teman!" Snapshot Rawpixel dari Unsplash

Prinsip

Prinsip-prinsip perusahaan kami didasarkan pada model Three Ways. Ini dikembangkan oleh Gene Kim, penulis "Visible Ops" dan "The Phoenix Project," dan Mike Orzen, penulis "Lean IT." Kami merekomendasikan membangun lingkungan di mana pemikiran sistemik distimulasi, siklus umpan balik diperkuat, dan budaya eksperimentasi dan pembelajaran terus menerus ditanamkan.
Pikirkan terus-menerus tentang keseluruhan sistem. Tanyakan kepada diri sendiri: "Bagaimana Anda mendapatkan loop umpan balik lebih banyak?" Pemantauan, metrik, dan pencatatan adalah tiga dari siklus ini yang membantu administrator berpartisipasi dalam desain. Dalam lingkungan DevOps yang sehat, proses yang mendorong terciptanya siklus umpan balik yang pendek dan efektif dirangsang, contoh proses tersebut adalah manajemen insiden, analisis objektif post-mortem, transparansi ...



"Jabat tangan sebelum MacBook Pro", cuplikan rawpixel dari Unsplash

Metode

Manajemen yang fleksibel

Fleksibel = sederhana. Bagilah proyek Anda menjadi bidang-bidang pekerjaan kecil, bangun, batasi batas kemajuan, laksanakan loop umpan balik dan raih visualisasi. Ini adalah elemen favorit saya dari proyek apa pun; teknik manajemen yang fleksibel memberikan hasil yang lebih efektif, termasuk meningkatkan throughput dan stabilitas sistem; karyawan mengalami lebih sedikit stres di tempat kerja dan mendapatkan lebih banyak kepuasan kerja.

Orang pertama, lalu proses, lalu alat

Salah satu metodologi pertama yang diusulkan oleh para pelopor DevOps dirumuskan sebagai "orang pertama, lalu proses, lalu alat". Di perusahaan kami, Anda disarankan untuk terlebih dahulu menyetujui siapa yang bertanggung jawab atas tugas kerja tertentu. Kemudian kami menentukan proses apa yang dibutuhkan untuk menyelesaikan masalah ini. Setelah itu, alat yang diperlukan untuk pelaksanaan proses dipilih. Di atas kertas, semua ini tampaknya logis, namun, insinyur dan manajer sering menyerah pada "cepat untuk mendapatkannya!" dari pemasok dan dalam hal ini mereka mencoba melakukan yang sebaliknya: membeli alat, dan kemudian membentuk seluruh aliran tugas untuk itu.

Pengiriman terus menerus

Istilah ini begitu di bibir semua orang bahwa kadang-kadang bahkan disamakan dengan DevOps. Pada prinsipnya, ini adalah praktik pemrograman dinamis dan pengujian perangkat lunak, menyediakan rilis cepat dari fragmen yang sangat kecil, lengkap, dan sudah jadi. Secara umum, pengiriman berkelanjutan dapat meningkatkan kualitas dan kecepatan secara keseluruhan. Pengiriman berkelanjutan adalah komponen kunci dari proyek, yang harus ditetapkan sedini mungkin, faktor pendorong untuk keberhasilan implementasi DevOps.

Ubah manajemen



Dalam pengalaman saya, ada korelasi langsung antara seberapa baik sistem dioperasikan dan bagaimana manajemen perubahan diatur. Ini tidak berarti bahwa Anda perlu menerapkan kontrol tradisional, yang memperlambat pembangunan dan lebih cenderung berbahaya daripada membantu. Dalam hal ini, Anda memerlukan platform yang dapat diskalakan dan andal untuk pengiriman berkelanjutan. Berfokus pada penghilangan artefak yang rapuh, kemampuan reproduksi proses pembangunan, pengelolaan dependensi, dan menciptakan lingkungan yang kondusif untuk perbaikan berkelanjutan.

Infrastruktur dalam kode (Konfigurasi dalam kode ... Semuanya dalam kode)

Salah satu wahyu bahwa perusahaan saat ini telah memperkaya saya dengan adalah bahwa sistem apa pun dapat dan harus ditafsirkan sebagai kode. Spesifikasi sistem dimasukkan ke dalam sistem kontrol versi dan ditinjau oleh rekan sejawat. Menggunakan mekanisme penyebaran modern, khususnya, Docker dan Kubernetes, Anda dapat secara otomatis membangun, menguji, dan membuat sistem nyata berdasarkan spesifikasi dan mengelolanya secara terprogram. Pendekatan ini memungkinkan Anda untuk mengkompilasi dan menjalankan sistem, dan tidak membuat kruk jangka panjang yang melelahkan, yang seiring waktu menjadi sangat sulit untuk dikembangkan.

Berlatih

Di semua organisasi TI sebelumnya di mana saya bekerja, pendekatan untuk proyek adalah: "mari kita menulis sesuatu ... dan kemudian kita akan menginstruksikan seseorang untuk menguji dan menyebarkannya." Metode ini tidak sesuai dengan rencana. Waktu berubah, dan ketika tim pengembangan pindah ke proyek berikutnya, biaya operasi menjadi tak tertahankan.



"Roller coaster di bawah langit biru dan awan putih", cuplikan dari Priscilla Du Preez dari Unsplash

Dalam organisasi saat ini, kami berusaha untuk menjaga pengembang mengikuti layanan yang mereka buat dan sebagian bertanggung jawab atas operasinya. Hasilnya adalah siklus umpan balik yang lebih efisien yang membantu tim merespons lebih cepat tidak hanya terhadap bug, tetapi juga pada fitur-fitur baru dan memastikan bahwa produk berkembang ke arah yang benar.

Alat-alatnya

Kami menyukai alat kami! Mereka membantu program insinyur, merakit, menguji, mengemas, melepaskan, mengkonfigurasi dan melacak kedua sistem dan aplikasi. Kami mahir memiliki alat kami dan mengetahui seluruh jajaran solusi yang menarik bagi kami - baik open source maupun komersial. Sebelum paradigma DevOps mulai berkembang, inovasi dan alat mengalami stagnasi. Untuk waktu yang lama saya menggunakan alat yang sama seperti pada awal karir saya (saya telah pemrograman sejak tahun 2000). Banyak alat yang digunakan di DevOps sangat serbaguna dan membantu untuk mengatur siklus hidup layanan dengan cara yang benar-benar baru.



"Semua jenis alat pertukangan di bengkel" dari koleksi Barn Images dari Unsplash

Anda perlu memutuskan alat yang dapat diandalkan untuk DevOps. Tidak ada alat tunggal untuk semua kesempatan, Anda memerlukan seluruh lini, inventaris yang dapat digabungkan dengan mempertimbangkan kebutuhan yang ada. Dan karena kami ingin semua ini bekerja bersama ... alat apa pun hanya berguna karena membantu seluruh sistem kami.

Anda harus memilih alat yang berfungsi dengan baik dengan sisa inventaris Anda. Alat harus membantu mengotomatiskan pekerjaan apa pun. Mereka harus mudah dipanggil dari API atau dari baris perintah. Pada prinsipnya, alat yang sangat tergantung pada UI tidak cocok dengan sangat baik bahkan dalam alat yang terintegrasi dengan baik.

Apa selanjutnya ...

Unduh gambar buruh pelabuhan dan mulai bereksperimen. Garap kode orang lain dan mulailah membangunnya. Menyebarkan server atau server cluster dengan Kubernetes. Jadi, Anda melakukan DevOps. Mulai di komputer Anda sendiri, dan kemudian pergi ke cloud.



"Seorang Anak Laki-Laki Berdiri di Tangga dan Menjangkau Awan," bidikan oleh Samuel Zeller dari Unsplash

Ketika Anda pertama kali mendengar tentang paradigma "infrastruktur dalam kode" atau "pengiriman berkelanjutan", Anda segera ingin mengatakan "tidak, itu bekerja secara berbeda dengan kami". Namun, untuk berhasil dengan DevOps, Anda perlu secara bertahap menguasai teknik-teknik ini, mereka tidak begitu rumit. Selama bertahun-tahun, industri telah menggunakan metode yang persis kebalikan dari DevOps, tetapi DevOps benar-benar berfungsi.