Pelatihan Tertulis DevOps

Bagaimana Cara Merancang Pipeline Pengiriman dan Penerapan Berkelanjutan DevOps?

Di banyak organisasi, mungkin termasuk organisasi Anda, pengembang menulis kode sendiri-sendiri di cabang terpisah. Cara ini tampaknya meningkatkan produktivitas individu, tetapi justru mengurangi produktivitas tim.

Cabang terpisah menyulitkan penggabungan kode dari beberapa pengembang. Menyatukan bagian-bagian kode agar bekerja bersama dan memberi manfaat serta fitur kepada klien biasanya membutuhkan beberapa pengembang, banyak pengerjaan ulang, dan penyelesaian konflik yang seharusnya ditangani sejak lama.

Tantangan Bertambah Jika Anda Tidak Melakukan Integrasi Berkelanjutan

Ironisnya, karena penggabungan kode sulit dan melelahkan, kebanyakan tim menunggu sampai menjelang penyerahan aplikasi kepada penguji integrasi atau penerimaan pengguna. Ini membuat dampaknya lebih besar. Mereka menyerahkan seluruh tanggung jawab atas integrasi dan mutu kode gabungan kepada tim penjaminan mutu. Ini menjelaskan mengapa proyek terlambat, anggaran membengkak, semangat tim turun, sasaran dan janji tidak terpenuhi, serta perusahaan di seluruh dunia membuang sekitar 600 miliar USD setiap tahun untuk pekerjaan TI yang tidak dianggarkan atau dijadwalkan. Dengan kata lain, untuk pengerjaan ulang dan solusi sementara.

Bagaimana Pengembangan Berbasis Trunk (Cabang Utama) Membantu Anda?

Solusinya adalah menggabungkan pengembangan berbasis trunk (cabang utama kode) dengan integrasi berkelanjutan dan otomatisasi pengujian. Ini merupakan model percabangan kontrol versi di mana pengembang berkolaborasi dalam satu cabang bernama “trunk”. Mereka menahan dorongan untuk membuat cabang pengembangan lain yang berumur panjang.

Pengembangan berbasis trunk memungkinkan integrasi berkelanjutan dan, pada akhirnya, pengiriman berkelanjutan. Ketika pengembang melakukan commit ke trunk beberapa kali sehari, setiap anggota tim dapat dengan mudah memenuhi syarat utama integrasi berkelanjutan, yaitu melakukan commit ke trunk setidaknya sekali setiap 24 jam. Dengan demikian, basis kode selalu dapat dirilis sesuai kebutuhan dan pengiriman berkelanjutan bisa terwujud.

Integrasi Berkelanjutan Memungkinkan Pengiriman Kode dalam Bagian Lebih Kecil yang Siap Diterapkan

Commit yang sering memungkinkan pengembangan dan pengiriman dalam batch kecil, sehingga meningkatkan mutu dan memudahkan penyelesaian masalah serta konflik. Integrasi berkelanjutan dengan commit harian mendorong tim membuat kode yang bermakna dan siap diterapkan dalam potongan kecil tanpa mengganggu integritas integrasi dan pengiriman berkelanjutan. Pembaruan di repositori kode sumber bersama juga membantu tim menyelaraskan pekerjaan, mengambil keputusan, dan memberi umpan balik dengan cepat.

Setiap kali kode dimasukkan, sistem integrasi berkelanjutan menjalankan kasus uji otomatis untuk fungsi dan fitur yang bergantung pada modul yang berubah atau terdampak olehnya. Jika ada yang rusak, pemilik commit tersebut bertanggung jawab memperbaikinya dengan prioritas tertinggi. Saat itu, yang terpenting adalah memungkinkan anggota tim lain terus mengintegrasikan pekerjaannya ke trunk. Sampai perubahan yang salah diperbaiki atau dibatalkan, commit lain ke modul itu tidak diizinkan demi stabilitas dan keandalan trunk.

Jika Anda tidak setuju dengan prinsip dasar DevOps ini, tanyakan mengapa Anda akan menambahkan kode ke modul yang sudah bermasalah.

Anda mungkin punya alasan yang sah, tetapi hindari utang teknis dan jangan menumpuk solusi sementara di atas solusi sementara.

Commit yang Mensyaratkan Validasi sebagai Perlindungan Tambahan untuk Pengembangan Berbasis Trunk

Tim DevOps juga dapat mengandalkan commit yang mensyaratkan validasi untuk meningkatkan mutu dan menambah lapisan perlindungan bagi trunk.

Setiap kali pengembang mencoba memasukkan kode, pengujian otomatis dijalankan terlebih dahulu untuk memvalidasinya. Kode baru dimasukkan secara resmi ke trunk setelah lolos validasi.

Gunakan Lingkungan yang Menyerupai Produksi di Setiap Tahap Aliran Nilai Rekayasa Perangkat Lunak

Tantangan umum lainnya adalah ketidakkonsistenan antara lingkungan produksi dan praproduksi, yaitu pengembangan, integrasi, dan pengujian. Perbedaan bisa terjadi pada konfigurasi, versi dan tingkat patch sistem operasi, basis data, alat pihak ketiga, serta API. Versi kode sendiri juga dapat berbeda di berbagai lingkungan. Bahkan selisih kecil pada versi JVM antara praproduksi dan produksi dapat menentukan keberhasilan penerapan. Tanpa kendali penuh dan pemahaman tentang isi lingkungan, Anda tidak dapat mengetahui hasil yang akan diperoleh.

Jadikan Pengelolaan Lingkungan Bagian dari Pekerjaan Harian

Sistem praproduksi seharusnya merupakan replika sistem produksi. Beri tim kemampuan membuat lingkungan layanan mandiri secara otomatis sesuai kebutuhan agar mereka dapat melakukan rekayasa perangkat lunak sehari-hari dengan aman dalam kondisi yang menyerupai produksi.

Aliran nilai TI memberi manfaat melalui kode perangkat lunak dan lingkungan tempat kode berjalan. Spesialis pengembangan dan operasi perlu memahami bahwa ada dua unsur yang sama penting:

1. Kode untuk membangun perangkat lunak yang memberikan manfaat bagi klien internal dan/atau eksternal.
2. Kode untuk membangun lingkungan praproduksi dan produksi tempat perangkat lunak Anda dijalankan.

Gunakan Satu Sumber Data Tepercaya (Trunk) untuk Mengendalikan Perangkat Lunak dan Lingkungan
(yaitu, terapkan infrastruktur sebagai kode atau IaC)

Dengan DevOps, pekerjaan membangun lingkungan praproduksi dan produksi menjadi bagian dari trunk, bentuk paling murni dari infrastruktur sebagai kode (IaC). Spesialis pengembangan dan operasi membangunnya bersama. Pekerjaan ini tidak diserahkan kepada tim operasi yang terpisah dan hampir tidak memahami kekhususan perangkat lunak yang akan dijalankan.

Perlakukan kode perangkat lunak dan kode lingkungan sama pentingnya dengan menyimpan keduanya di satu sumber data tepercaya, yaitu trunk.

Untuk membangun seluruh sistem praproduksi, produksi, dan pipeline penerapan, termasuk kerangka integrasi dan pengiriman berkelanjutan, simpan kode perangkat lunak, konfigurasi, skrip, serta semua hal yang dibutuhkan untuk membangun rangkaian pengiriman secara menyeluruh dalam kontrol versi. Jika ingin mengubah pengaturan lingkungan secara permanen, lakukan pada skrip yang membangun lingkungan itu. Anggota tim berikutnya tidak perlu mengulangi pekerjaan dari awal.

Dokumentasi terperinci biasanya cepat usang. Lebih baik investasikan waktu untuk menjaga skrip pembuatan lingkungan tetap mutakhir. Tanpa lingkungan layanan mandiri yang dapat dibuat sesuai permintaan, infrastruktur awan hanya menjadi platform hosting yang kurang dimanfaatkan dan inisiatif DevOps menjadi upaya perbaikan proses yang juga kurang dimanfaatkan. Anda seharusnya bisa membuat seluruh lingkungan produksi dan praproduksi dari sistem kontrol versi. Dengan DevOps, membangun kembali lingkungan lebih mudah dan cepat daripada memperbaikinya. Perubahan manual tidak lagi diperbolehkan. Hanya kode dan konfigurasi yang boleh membangun ulang, mengonfigurasi, dan menjalankan lingkungan.

Tetapkan Definition of Done (DoD) yang Baru

Setelah kerangka pengiriman berkelanjutan dan pipeline penerapan berjalan, Anda memerlukan Definition of Done (DoD) yang baru.

Tugas dikategorikan “Selesai” jika fitur dan manfaat terkait bagi klien telah:

• dibuat dari trunk secara otomatis atau dengan satu klik,
• diuji di lingkungan yang menyerupai produksi dengan pengujian otomatis,
• didemonstrasikan di lingkungan yang menyerupai produksi,
• siap diterapkan atau, lebih baik lagi, sudah diterapkan di lingkungan produksi yang berjalan, juga secara otomatis atau dengan satu klik.

KESIMPULAN

Dengan DevOps, integrasi kode menjadi bagian dari pekerjaan harian. Pengembang, tim operasi, dan pakar keamanan informasi berkali-kali berlatih menerapkan hasil kerja selama siklus rekayasa. Ini memperbesar peluang penerapan ke produksi berlangsung lancar.

Integrasi berkelanjutan juga meningkatkan kapasitas bisnis, stabilitas perangkat lunak dan lingkungan, kepuasan kerja, serta mutu layanan untuk klien internal dan eksternal.