Jalan baru dalam pengembangan perangkat lunak mulai terbentuk pada awal 2000-an. Pada saat itu, banyak yang melihat kesempatan untuk menghilangkan kesenjangan antara tim Dev dan Ops. Oleh karena itu pemikiran berkembang untuk mencari solusi kerumitan dalam pengembangan, terutama pengembangan berkelanjutan.

Pengembangan Perangkat Lunak di Awal Tahun 2000-an

Di era tersebut, sebagian pengembang besar belum memikirkan tentang cara menggunakan produk atau bagaimana mempromosikannya di lingkungan target; pengembang seharusnya hanya memproduksi kode dan tidak perlu repot-repot tentang pengiriman. Biasanya, pengembang menggunakan versi OS desktop dan merasa tidak perlu mengetahui lebih banyak bagaimana server produksi dikonfigurasi.

Terlebih lagi, ketika pengembang baru bergabung dengan tim. Mereka cenderung menyia-nyiakan beberapa minggu mendirikan lingkungan pengembangan nya. Pada gilirannya, tim operasi tidak memiliki pengaruh pada tim Development dan tidak merasa khawatir tentang pengembangan produk. Kedua tim memiliki manajer dan metrik kesuksesan mereka sendiri.

Jadi, apa yang salah dengan gambaran tersebut, dan masalah apa yang bisa muncul ?

Di masa lalu ketika itu akan menyebarkan produk, secara rutin akan menghadapi situasi di mana kode yang disediakan tidak bekerja di lingkungan pementasan. Tim Operasional tidak dapat menyebarkan. Tim Development bersikukuh dengan alasan yang sama: “Tapi itu bekerja di PC / Notebook saya!”

Ops menyalahkan Dev, Dev menyalahkan Ops: itu adalah pertempuran tak berujung antara kedua tim yang mengakibatkan penyelesaian proyek tidak dapat terukur dengan semua konsekuensi negatif kedepannya.

Kemudian manajemen mencoba untuk memperkenalkan daftar periksa, mendistribusikan kontrol dan menjaga dokumentasi. Pada saat yang sama, sebagian besar tindakan operasional dilakukan secara manual. Waktu tambahan dibutuhkan untuk membuat dokumen, konflik tidak terselesaiakn dan prediksi tanggal pengiriman jauh dari akurat. Waktu berlalu sementara pelanggan menuntut tanggal pengiriman / penyelesaian, fitur baru dan bug diperbaiki secepat mungkin.

Bagaimana kita memperbaiki masalah ini?

Metodologi pengembangan Agile menjadi populer, virtualisasi dan cloud memasuki arena bisnis dan startups mulai “memainkan biola pertama”. Pasar global menjadi lebih agresif; jika Anda tidak bisa merilis fitur baru, Anda mungkin akan kehilangan sebagian besar pelanggan Anda. Dengan demikian, era transformasi digital ini menuntut bisnis untuk lebih berani dalam menanggapi perubahan kondisi eksternal.

Kotak Pandora

Dari sudut pandang metodologi pengembangan perangkat lunak modern dan teknologi, kita dapat meringkas masalah dengan model lama menjadi lima potensi masalah:

  1. Tidak ada orang yang bertanggung jawab sepenuhnya yang akan mengelola produk dari definisi kebutuhan bisnis untuk rilis produk.
  2. Tim Dev dan Ops memiliki metrik keberhasilan yang berbeda. Ini menyebabkan lingkungan di mana masing-masing tim hanya tertarik pada kesuksesan mereka sendiri.
  3. Kurangnya komunikasi antara tim Dev dan Ops. Pengembang perlu lebih banyak pengetahuan tentang lingkungan target, sementara tim Operasi tidak memiliki petunjuk apa yang dilakukan tim Development.
  4. Ada perbedaan antara konfigurasi pembangunan dan lingkungan target.
  5. Lambat dan panjangnya proses pengiriman dengan tanggal pengiriman yang tidak jelas.

DevOps: Sebagai “Jembatan” Solusi Kerumitan Dalam Pengembangan

Solusi untuk semua masalah ini adalah pola pemiliran DevOps yaitu, metodologi pengembangan perangkat lunak seperti Scrum dengan satu set peran, langkah-langkah dan praktik dengan tanggung jawab yang telah ditetapkan. DevOps adalah budaya mengembangkan produk yang dapat dengan mudah digunakan serta beroperasi secara efektif.

Hal ini tidak cukup untuk menyewa insinyur DevOps dan berharap bahwa semua masalah dapat diselesaikan. Anda perlu mengadopsi budaya DevOps dalam organisasi Anda.

Berikut adalah beberapa rekomendasi tentang bagaimana mengadopsi DevOps dalam organisasi Anda dan meningkatkan produktivitas pengembangan dan tim operasional:

  1. Harus ada satu, dan hanya satu manajer bertanggung jawab untuk produk atau fitur pengembangan dari A sampai Z: dari tahap pengumpulan persyaratan hingga tanggal rilis.
  2. Tim pengembangan dan operasional harus berbagi indikator keberhasilan umum difokuskan pada hasil pengiriman.
  3. Memperkenalkan peran utama DevOps – seseorang dengan dukungan manajemen serta pengetahuan teknis yang baik untuk menjadi jembatan antara manajemen, operasi dan tim pengembangan untuk mengatur DevOps sebagai praktik terbaik dan memastikan bahwa tim mengikuti mereka.
  4. Tim pengembangan harus menggunakan lingkungan pengembangan sedekat mungkin dengan lingkungan target.
  5. Untuk menerapkan pendekatan “infrastruktur sebagai kode”, tim pengembangan harus menggunakan teknologi virtualisasi dan menggambarkan perubahan lingkungan dengan bantuan alat manajemen konfigurasi yang berbeda: shell scripts, Puppet, Chef, Ansible, dll. Pada gilirannya, tim operasi dapat membantu mengkonfigurasi pengembangan skrip.
  6. Kedua tim harus bekerja sama dalam perencanaan infrastruktur.
  7. Tim operasi perlu untuk menentukan persyaratan untuk monitoring, manajemen dan log pemulihan bencana, serta membantu tim pengembangan merancang solusi yang sesuai dengan persyaratan ini.
  8. Melibatkan tim pengembangan dalam otomatisasi kegiatan operasional; khususnya, untuk membangun dan menyebarkan proses, melakukan otomatisasi runbook, dll

Ketika Anda memutuskan untuk mengadopsi budaya DevOps dalam tim Anda, perlu diingat bahwa DevOps bukan sebuah keajaiab: tapi merupakan perubahan organisasi yang membutuhkan pola pikir Dev dan Ops yang lebih kolaboratif.

Jika Anda membangun komunikasi yang baik antara manajer, pengembang dan operasi melalui praktek-praktek terbaik yang disebutkan, Anda akan menghindari konflik kepentingan dalam tim. Secara signifikan juga mempercepat proses pengiriman dan memastikan pelanggan Anda mendapatkan kualitas terbaik.