Mengenal Pengembangan Software DevOps

Mengenal Pengembangan Software DevOps – DevOps adalah seperangkat praktik yang menggabungkan pengembangan perangkat lunak ( Dev ) dan operasi TI ( Ops ).

Mengenal Pengembangan Software DevOps

deshack – Ini bertujuan untuk mempersingkat siklus hidup pengembangan sistem dan memastikan pasokan berkelanjutan dari perangkat lunak berkualitas tinggi.

DevOps melengkapi pengembangan perangkat lunak yang gesit. Beberapa aspek DevOps berasal dari metodologi Agile.

Baca Juga : Tren Pengembangan Perangkat Lunak Teratas di 2022

Selain menjadi kombinasi lintas fungsi (dan portmanteau juga) dari istilah dan konsep untuk “pengembangan” dan “operasi,” akademisi dan praktisi belum mengembangkan definisi universal untuk istilah “DevOps”. Paling sering, DevOps dicirikan oleh prinsip-prinsip utama: kepemilikan bersama, otomatisasi alur kerja, dan umpan balik yang cepat.

Dari perspektif akademis, Len Bass , Ingo Weber , dan Liming Zhu tiga peneliti ilmu komputer dari CSIRO dan Institut Rekayasa Perangkat Lunak menyarankan untuk mendefinisikan DevOps sebagai “seperangkat praktik yang dimaksudkan untuk mengurangi waktu antara melakukan perubahan pada sistem dan perubahan ditempatkan ke dalam produksi normal, sambil memastikan kualitas tinggi”.

Namun, istilah ini digunakan dalam berbagai konteks. Yang paling sukses, DevOps adalah kombinasi dari praktik khusus, perubahan budaya, dan alat.

Pada tahun 1993, Konsorsium Arsitektur Jaringan Informasi Telekomunikasi ( TINA-C ) mendefinisikan Model Siklus Hidup Layanan yang menggabungkan pengembangan perangkat lunak dengan operasi layanan (telekomunikasi). Pada tahun 2009, konferensi pertama bernama devopsdays diadakan di Ghent , Belgia . Konferensi ini didirikan oleh konsultan Belgia, manajer proyek dan praktisi tangkas Patrick Debois. Konferensi tersebut kini telah menyebar ke negara-negara lain.

Pada tahun 2012, laporan State of DevOps disusun dan diluncurkan oleh Alanna Brown di Puppet.

Pada tahun 2014, laporan tahunan State of DevOps diterbitkan oleh Nicole Forsgren , Gene Kim, Jez Humble, dan lainnya. Mereka menyatakan bahwa adopsi DevOps semakin cepat. Juga pada tahun 2014, Lisa Crispin dan Janet Gregory menulis buku More Agile Testing, yang berisi bab tentang pengujian dan DevOps.

Pada tahun 2016, metrik DORA untuk throughput (frekuensi penerapan, waktu tunggu untuk perubahan), dan stabilitas (waktu rata-rata untuk pulih, mengubah tingkat kegagalan) yang dipublikasikan dalam laporan State of DevOps.

Banyak ide mendasar untuk praktik DevOps yang terinspirasi oleh, atau mencerminkan, praktik terkenal lainnya seperti siklus Plan-Do-Check-Act Lean dan Deming , hingga The Toyota Way dan pendekatan Agile untuk memecah komponen dan ukuran batch. Bertentangan dengan pendekatan proscriptive “top-down” dan kerangka kaku ITIL pada 1990-an, DevOps adalah “bottom-up” dan praktik yang fleksibel, dibuat oleh insinyur perangkat lunak, dengan mempertimbangkan kebutuhan insinyur perangkat lunak.

Motivasi untuk apa yang telah menjadi DevOps modern dan beberapa praktik DevOps standar seperti pembuatan dan pengujian otomatis, integrasi berkelanjutan , dan pengiriman berkelanjutan berasal dari dunia Agile, yang dimulai (secara informal) hingga 1990-an, dan secara formal hingga 2001. Tim pengembangan tangkas menggunakan metode seperti Pemrograman Ekstrim tidak dapat “memuaskan pelanggan melalui pengiriman awal dan berkelanjutan dari perangkat lunak yang berharga” kecuali jika mereka memasukkan tanggung jawab operasi / infrastruktur yang terkait dengan aplikasi mereka, banyak di antaranya mereka otomatisasi.

Karena Scrummuncul sebagai kerangka kerja Agile yang dominan di awal tahun 2000-an dan menghilangkan praktik rekayasa yang menjadi bagian dari banyak tim Agile, gerakan untuk mengotomatisasi operasi / fungsi infrastruktur yang terpisah dari Agile dan berkembang menjadi DevOps modern. Hari ini, DevOps berfokus pada penyebaran perangkat lunak yang dikembangkan, apakah itu dikembangkan melalui Agile atau metodologi lainnya.

ArchOps menghadirkan ekstensi untuk praktik DevOps, mulai dari artefak arsitektur perangkat lunak , alih-alih kode sumber, untuk penyebaran operasi. ArchOps menyatakan bahwa model arsitektur adalah entitas kelas satu dalam pengembangan perangkat lunak, penyebaran, dan operasi.

CI/CD terdiri dari continuous integration (CI) dan continuous delivery (CD), atau continuous deployment (CD). Digunakan bersama-sama, ketiga proses tersebut mengotomatiskan pembuatan, pengujian, dan penerapan sehingga tim DevOps dapat mengirimkan perubahan kode lebih cepat dan lebih andal.

Saat mengacu pada CI/CD, “CD” yang dirujuk biasanya adalah pengiriman berkelanjutan, bukan penyebaran berkelanjutan. Pengiriman berkelanjutan dan proses CI/CD lainnya difokuskan pada otomatisasi tugas pengiriman perangkat lunak , sementara DevOps juga berfokus pada perubahan organisasi untuk mendukung kolaborasi hebat antara banyak fungsi yang terlibat.

Keduanya memiliki latar belakang yang sama dalam metode tangkas dan pemikiran ramping, memprioritaskan perubahan kecil dan sering dengan nilai terfokus kepada pelanggan akhir. Ini memastikan dua hal: Perangkat lunak selalu dalam keadaan dapat dirilis sepanjang siklus hidupnya, yang membuatnya lebih murah dan tidak terlalu berisiko untuk mengirimkan perangkat lunak.

Penerapan pengiriman berkelanjutan dan DevOps ke analitik data disebut DataOps. DataOps berupaya mengintegrasikan rekayasa data, integrasi data, kualitas data, keamanan data, dan privasi data dengan operasi. Ini menerapkan prinsip-prinsip dari DevOps, Agile Development , dan kontrol proses statistik , yang digunakan dalam lean manufacturing , untuk meningkatkan waktu siklus dalam mengekstraksi nilai dari analitik data.

Pada tahun 2003, Google mengembangkan site reliability engineering (SRE), sebuah pendekatan untuk merilis fitur baru secara terus-menerus ke dalam sistem ketersediaan tinggi berskala besar sambil mempertahankan pengalaman pengguna akhir yang berkualitas tinggi. Sementara SRE mendahului pengembangan DevOps, mereka umumnya dipandang terkait satu sama lain.

DevSecOps adalah augmentasi dari DevOps untuk memungkinkan praktik keamanan diintegrasikan ke dalam pendekatan DevOps. Berlawanan dengan model tim keamanan terpusat tradisional, setiap tim pengiriman diberdayakan untuk mempertimbangkan kontrol keamanan yang benar ke dalam pengiriman perangkat lunak mereka. Praktik dan pengujian keamanan dilakukan lebih awal dalam siklus hidup pengembangan, oleh karena itu istilah “shift left” dapat digunakan. Keamanan diuji dalam tiga bidang utama: statis, komposisi perangkat lunak, dan dinamis.

Memeriksa kode secara statis melalui pengujian keamanan aplikasi statis (SAST) adalah pengujian kotak putih dengan fokus khusus pada keamanan. Tergantung pada bahasa pemrograman, alat yang berbeda diperlukan untuk melakukan analisis kode statis tersebut.

Komposisi perangkat lunak dianalisis, terutama perpustakaan dan versinya diperiksa terhadap daftar kerentanan yang diterbitkan oleh CERT dan kelompok ahli lainnya. Saat memberikan perangkat lunak kepada klien, lisensi dan kecocokannya dengan salah satu perangkat lunak yang didistribusikan menjadi fokus, terutama lisensi copyleft .

Pengujian dinamis juga disebut pengujian kotak hitam . Perangkat lunak diuji tanpa mengetahui fungsi dalamnya. Di DevSecOps itu di satu sisi disebut secara dinamis(DAST), atau pengujian penetrasi. Tujuannya adalah untuk menangkap, antara lain, kesalahan seperti skrip lintas situs , atau injeksi SQL lebih awal. Jenis ancaman misalnya diterbitkan oleh proyek keamanan aplikasi web terbuka , misalnya TOP10-nya.

Di sisi lain, terutama dengan pengujian aplikasi interaktif layanan mikro (IAST) sangat membantu untuk memeriksa kode mana yang dijalankan saat menjalankan tes fungsional otomatis, fokusnya adalah mendeteksi kerentanan dalam aplikasi. Berlawanan dengan SAST dan DAST, IAST bekerja di dalam aplikasi.

Sangat mirip dengan IAST, Runtime application self-protection (RASP) berjalan di dalam aplikasi. Instrumentasinya berfokus untuk mendeteksi serangan tidak dalam siklus pengujian, tetapi selama runtime produktif. Serangan dapat dilaporkan melalui pemantauan dan peringatan, atau diblokir secara aktif. Peringatan RASP membantu informasi keamanan dan manajemen acara (SIEM).