Pada waktu yang lalu kita sudah membedah CALMS Framework secara tuntas. Kini kita akan menyambangi materi lain mengenai bagaimana sebenarnya DevOps dipraktikkan supaya Anda mendapat gambaran dengan lebih jelas.
Anda harus paham terlebih dahulu bahwa poin-poin yang tadi kita bahas di modul CALMS Framework akan mengarah pada praktik DevOps yang merampingkan dan meningkatkan siklus pengembangan aplikasi agar bisa menyajikan update (pembaruan) lebih sering secara andal seraya menjaga stabilitas infrastruktur (seperti server).
Ini pada akhirnya berujung pada dua hal praktis nan penting, yakni DevOps Pipeline dan DevOps Tools. Kita akan bahas ini lebih mendalam di submodul berikutnya ya,
DevOps Pipeline
Sebagaimana yang kita ketahui bersama, DevOps adalah gerakan yang merevolusi struktur organisasi dengan menyatukan tim Developer dan IT Operations. Hasilnya adalah perubahan kultur di mana kedua tim tersebut saling bekerja sama, menerapkan automasi, meningkatkan kecepatan proses deployment, dan membuat perusahaan menjadi lebih fleksibel.
Selain itu, manfaat utama dari implementasi DevOps adalah memperbaiki dan merampingkan alur deployment, sekaligus mengurangi frekuensi dan dampak insiden. Oleh karenanya, kita perlu suatu cara yang dapat memudahkan tim dalam mengurusi proses deployment. Nah, salah satu praktiknya adalah memanfaatkan DevOps Pipeline.
DevOps Pipeline (atau biasa disebut juga sebagai CI/CD Pipeline) merupakan serangkaian proses dan tools terotomatisasi yang memungkinkan Developer dan IT Operations untuk bekerja secara kohesif untuk men-deploy kode ke lingkungan production.
Kendati DevOps Pipeline bisa saja berbeda-beda untuk setiap perusahaan, tetapi umumnya mencakup komponen fundamental, seperti continuous integration, continuous delivery/deployment, automation testing, validation, dan reporting. DevOps Pipeline pun dapat mencakup satu atau lebih tahapan manual yang memerlukan campur tangan manusia sebelum kode diizinkan untuk diproses ke fase selanjutnya.
Berikut adalah gambar yang menunjukkan tahapan-tahapan dalam DevOps Pipeline.
Semoga Anda tidak bingung ya melihat gambar di atas. Apabila Anda masih merasa kesulitan dalam memahami DevOps Pipeline, mari kita bedah setiap tahapan satu per satu.
Code
Pada tahap ini, tim Developer menulis dan mengembangkan kode aplikasi dalam bahasa pemrograman tertentu, entah itu Java, JavaScript, Python, C#, dsb. Mereka menulis kode di lingkungan development agar segala perubahan atau penambahan fitur tak berimbas ke aplikasi yang dipakai pengguna, seperti misalnya di komputer pribadi menggunakan IDE alias Integrated Development Environment.
Nah, selepas kode siap, Developer kemudian mengirimkan/mengunggah (push) kode yang telah ditulis ke sebuah lokasi terpusat, umumnya adalah Git repository.
Build
Selepas kode di-push ke repository dan dipastikan aman untuk lanjut ke fase berikutnya, kode tadi lantas dieksekusi melalui proses build. Dalam konteks pengembangan aplikasi, “build” mengacu pada proses yang mengubah file dan aset lainnya menjadi produk perangkat lunak dalam bentuk final atau siap di-deploy.
Langkah-langkahnya sebagai berikut:
- Meng-compile kode.
- Memeriksa gaya dan standar dari kode.
- Menganalisis tingkat kompleksitas dan pemeliharaan kode.
- Memvalidasi dependencies pada kode.
- Membuat sebuah artifact, seperti container image, compressed file (jar, zip, dll), installer, package, dan sebagainya.
- Menjalankan unit test.
- Usai semua proses ini sukses, barulah kita bisa masuk ke fase berikutnya.
Test
Tahapan berikutnya adalah test alias pengujian. Di sini, artifact yang sedianya sudah dibuat akan diuji apakah memenuhi persyaratan fungsional, kinerja, desain, dan implementasi yang ditentukan atau tidak.
Berikut beberapa contoh praktik pengujian yang dilakukan.
- Functional testing : Memvalidasi sistem aplikasi dengan kebutuhan fungsional.
- Integration testing : Setiap unit atau komponen aplikasi digabungkan dan diuji sebagai sebuah grup/kelompok.
- Regression testing : Menjalankan kembali functional dan non-functional test untuk memastikan bahwa aplikasi yang telah dikembangkan dan diuji sebelumnya masih berfungsi setelah terjadi perubahan kode.
- Acceptance testing : Pengujian dilakukan oleh klien, pengguna, atau entitas resmi lainnya guna menentukan apakah kebutuhan aplikasi dan proses bisnis sudah terpenuhi atau belum.
- Load testing : Pengujian kinerja aplikasi yang menyimulasikan beban kerja atau traffic pada dunia nyata.
- Security testing : Mengidentifikasi kerentanan, kelemahan, ancaman, dan risiko keamanan pada aplikasi guna mencegah serangan berbahaya dari penyusup.
Pengujian yang dilakukan tentunya disesuaikan dengan kebutuhan pada masing-masing perusahaan. Bisa jadi, suatu perusahaan hanya menerapkan beberapa praktik pengujian saja. Namun, dalam kasus lain, mungkin saja ada perusahaan yang menerapkan semua praktik pengujian. Oke, setelah semua pengujian berhasil lolos, tahapan selanjutnya pun dimulai.
Release
Tahapan selanjutnya selepas test adalah release. Di fase ini, artifact yang telah lolos pengujian kemudian dikemas/dibungkus dengan nomor versi (version number) tertentu sebelum nanti akhirnya di-deploy.
Pemberian nomor versi tidak hanya untuk menunjukkan bahwa suatu produk telah diubah atau diperbarui, melainkan juga dapat digunakan untuk mengomunikasikan informasi penting lainnya, seperti urutan rilis, tingkat perubahan, dan tanggal rilis.
Deploy
Usai diberi nomor versi, artifact akan di-deploy ke target environment/lingkungan (kumpulan sumber daya–seperti server, dll–untuk meng-hosting aplikasi) yang sesuai, entah itu ke lingkungan test, staging, alpha, beta, atau production sekalipun.
Monitor
Fase terakhir pada siklus DevOps pipeline adalah monitor. Dalam tahap ini, umumnya aplikasi sudah di-deploy ke lingkungan production dengan sempurna sehingga bisa dinikmati oleh pengguna. Oleh karenanya, kita perlu memonitor aplikasi agar bisa mendeteksi error ataupun kejanggalan dengan cepat dan secara tanggap langsung memperbaikinya.
Nah, sekarang sudah paham nih fase-fase atau tahapan pada siklus DevOps pipeline. Lantas, pertanyaan yang selanjutnya muncul adalah, “Bagaimana jika terjadi kegagalan di salah satu tahapan ?” Jawabannya jelas, proses yang tengah dilakukan akan dihentikan sehingga tak bisa lanjut ke fase berikutnya.
Misalnya, Developer push kode ke Version Control System. Dengan ini, DevOps pipeline pun akan bekerja secara otomatis melakukan build, lalu test. Apabila ada salah satu dari sekian test yang gagal, Developer harus memperbaiki kodenya terlebih dahulu dan melakukan push kembali. Terus begitu sampai setiap tahapan tereksekusi dengan sempurna.
Selain itu, saat kita belajar DevOps pipeline atau CI/CD pipeline, akan erat kaitannya dengan istilah-istilah seperti Continuous Integration, Continuous Delivery, dan Continuous Deployment.
Tahukah Anda bahwa istilah CI/CD pada dasarnya diambil dari ketiga istilah tersebut. Sebenarnya, CI/CD merupakan akronim dari Continuous Integration dan Continuous Delivery/Deployment. Apa sih perbedaan mendasar di antara ketiganya?
Mungkin sebagian dari Anda sudah ada yang tahu. Nah, bagi yang belum familier dan mulai penasaran, Mari kita bedah ketiganya satu per satu.
Continuous Integration
Continuous integration (CI) merupakan praktik pada proses pengembangan aplikasi di mana Developer dengan rutin dan teratur memasukkan (commit) atau menggabungkan (merge) setiap perubahan kode (code changes) mereka ke sebuah repositori terpusat (central repository), setelah itu proses build dan unit test secara otomatis pun dijalankan.
Tujuan utama dari continuous integration adalah untuk menemukan dan mengatasi bug atau error lebih cepat, meningkatkan kualitas aplikasi, dan mengurangi waktu yang diperlukan untuk memvalidasi dan merilis pembaruan perangkat lunak (software update).
Kemudian, mengapa praktik CI ini diperlukan ? Di masa lampau, Developer bekerja secara terpisah dan terisolasi dari tim lain dalam waktu yang lama. Ditambah, mereka melakukan penggabungan (merge) perubahan kode ke central repository hanya jika tugas mereka komplet. Nah, hal ini membuat proses penggabungan perubahan kode menjadi sulit dan memakan waktu, bahkan kerap pula mengakibatkan bug yang terakumulasi untuk waktu yang lama tanpa koreksi sama sekali. Inilah faktor-faktor yang mempersulit penyampaian update ke pengguna dengan cepat.
Nah, dengan hadirnya CI, Developer kini bisa rutin memasukkan (commit) kode ke central repository menggunakan version control system seperti Git. Pada praktiknya, proses CI secara otomatis akan melakukan build dan menjalankan unit test pada setiap perubahan kode yang baru agar dapat mengidentifikasi bug atau error dengan segera.
Continuous Delivery
Continuous delivery (CD) adalah praktik pada proses pengembangan aplikasi di mana perubahan kode (code changes) secara otomatis dipersiapkan sebelum nantinya dikirim ke lingkungan production.
Continuous delivery merupakan teknik lanjutan dari continuous integration. Jika di CI hanya sampai proses build dan unit test, di CD ini prosesnya hingga deploy semua perubahan kode ke lingkungan testing, staging (pre-production), dan/atau production. Namun, untuk bisa men-deploy ke production, perlu melalui persetujuan manual (manual approval) terlebih dahulu, entah itu oleh Developer yang lebih senior, manajer, atau siapa pun yang berhak.
Selain itu, continuous delivery pun memungkinkan Developer untuk melakukan pengujian otomatis di luar unit test saja sehingga mereka dapat menguji dan memverifikasi kualitas software update yang akan di-deploy ke production (yang pada akhirnya sampai ke pengguna). Pengujian ini dapat mencakup UI testing, load testing, integration testing, dll. Dengan begitu akan membantu pengembang memvalidasi pembaruan secara lebih menyeluruh dan menemukan masalah secara pre-emptive.
Bila praktik CD diimplementasikan dengan tepat, niscaya Developer senantiasa memiliki artifact yang sudah siap deploy karena telah melewati berbagai standar pengujian.
Salah satu kesalahpahaman tentang continuous delivery adalah jika kita mengatakan bahwa proses ini men-deploy langsung setiap perubahan kode ke lingkungan production. Padahal, poin dari continuous delivery bukanlah itu, melainkan sekadar memastikan bahwa setiap perubahan kode siap untuk di-deploy ke production melalui beberapa cara, umumnya adalah dengan men-deploy kode yang sudah di-build sebelumnya ke lingkungan testing untuk dilakukan pengujian otomatis. Jika mendapatkan persetujuan dari pihak terkait, barulah aplikasi di-deploy ke production.
Nah, justru praktik deploy aplikasi langsung ke lingkungan production adanya di continuous deployment.
Continuous Deployment
Continuous delivery dan continuous deployment pada hakikatnya adalah proses yang “serupa tapi tak sama”. Perbedaannya, continuous delivery memiliki proses persetujuan manual (manual approval) sebelum aplikasi di-deploy ke production, sementara continuous deployment tidak memiliki hal tersebut.
Jadi, dengan continuous deployment, proses deploy aplikasi ke lingkungan production berlangsung secara otomatis tanpa ada persetujuan eksplisit dan intervensi manusia. Dengan begitu, continuous deployment memungkinkan pemberian feedback yang berkelanjutan oleh pengguna setiap kali suatu fitur atau update sampai ke perangkat mereka.
Kesimpulannya, DevOps pipeline atau CI/CD pipeline merupakan contoh yang tepat bagaimana tim Developer dan IT Operations bekerja sama dalam menggunakan tools untuk merampingkan alur kerja dan menstandardisasi praktik pada proses pengembangan aplikasi.
Selain itu, DevOps pipeline pun dapat memastikan bahwa kualitas kode akan terjaga, keamanan akan terjamin, dan proses deployment akan berlangsung cepat dan konsisten.