#3 Weekly Sharing : Why Continuous Delivery ?

If you take software engineering as your major, tentu saja sudah tak asing lagi dengan istilah software development.

Dalam software development metodologi yang telah Anda pelajari di kampus, atau dalam berbagai macam sharing pada umumnya, apapun software development metodologi yang digunakan, baik itu waterfall, agile, xtreme programming, scrum, dll, yang biasa dibahas adalah mengenai proses melengkapi requirement, serta development requirement harus dibuat selengkap mungkin. Semua dokumen perencanaan harus ada, mulai dari use case, activity diagram, class diagram, sampai dengan sequence diagram.

Hal tersebut bertujuan untuk mengurangi effort dan berbagai jenis kesalahan pada saat proses development. Which is juga akan sangat berguna, hanya saja setelah proses software development sampai ke user sangat jarang dibahas. Padahal setelah proses development sampai software bisa digunakan oleh user masih banyak critical steps dan membutuhkan waktu yang tidak sedikit.

So, dalam weekly sharing MailTarget minggu ini, saya akan membahas mengenai continuous delivery dalam software development. Kenapa proses-proses tersebut harus bisa dilakukan secara otomatis.

Anti-Pattern: Releasing Software Manually

Pada proses sebelumnya, ketika Anda melakukan release software ke public, tentu Anda paham dengan beberapa pattern delivery berikut ini:

  • Setelah membuat software, Anda akan membuat dokumentasi steps by steps deployment secara rinci, kemudian akan diikuti oleh orang yang melakukan deployment tersebut, bisa developer, deployment expert, sysadmin atau operations.
  • Bergantung pada manual testing apakah software sudah ter-deploy dan jalan sesuai dengan proses yang diinginkan.
  • Seluruh development team harus stand by pada hari ketika release, untuk memastikan dan mengatasi berbagai macam masalah yang sering terjadi ketika release.
  • Sering kali ada bug fixing, serta koreksi ketika proses release dan pada saat release.
  • Sering kali ada perbedaan environment / configuration di development machine dan production server.
  • Release process biasanya makan waktu yang cukup lama.
  • Release bisa saja gagal dan Anda harus dapat mengembalikannya ke versi sebelumnya tanpa ada masalah.
  • Duduk di depan monitor sampai jam 2 pagi adalah hal yang biasa ? terutama untuk menunggu waktu release yang tepat, dan terus memantau apakah release benar-benar berjalan dengan lancar.

Anti-Pattern: Deploying to Production-like Environment only after Development is complete

Cara lain yang dapat Anda ketahui untuk mengurangi masalah di production adalah dengan membuat server yang memiliki environment semirip mungkin dengan production server, atau yang biasa disebut dengan staging server.

Staging server biasanya digunakan untuk melakukan testing akhir sebelum melakukan release ke user. Testing tersebut tidak hanya melibatkan development team, melainkan juga tester, operations, bahkan non-technical teamStaging server hanya dapat dilakukan update sebelum release setelah proses development sudah selesai. Dikarenakan proses deployment ke staging ini pun sedikit ribet, developer harus menyediakan installer yang tepat, file-file konfigurasi yang tepat, migrasi database, dan dokumentasi untuk diberikan kepada orang yang melakukan proses deploy.

Melakukan release ke staging merupakan kali pertama bagi orang-orang selain development team untuk mencoba software. Sehingga jika ada masalah yang Anda alami pada staging server, maka release steps pun menjadi lebih panjang, karena harus kembali development proses, kemudian *testing *ulang pada staging server. Bahkan pada beberapa perusahaan, staging server dianggap terlalu mahal karena membangun environment yang mirip dengan production server, namun hanya digunakan untuk internal testing.

Anti-Pattern: Manual Configuration Management of Production Environment

Sudah merupakan hal yang wajar jika production server memiliki kontrol yang sangat dibatasi, meliputi siapa yang dapat mengakses, siapa yang dapat membuat perubahan disana, dan lain lain. Hal ini dilakukan agar kondisi production server dapat tetap stabil.

Semua konfigurasi untuk production server dapat dilakukan langsung pada system. Konfigurasi ini meliputi konfigurasi operating sistem, application server, web server, database, cluster, firewall, dan setting pada infrastruktur lainnya. Sehingga, biasanya operation team akan butuh waktu yang cukup lama untuk mempersiapkan environment production. Hal itu dikarenakan apabila ada masalah dengan konfigurasi-konfigurasi tersebut, akan susah untuk kembali ke konfigurasi sebelumnya.

Kadang dalam proses deployment yang telah berhasil pada server staging, namun ketika diimplementasikan pada server production gagal. Bahkan masih dalam satu cluster, namun cluster member dapat bertingkah lain-lain. Apalagi jika dalam satu cluster memiliki jenis sistem operasi yang berbeda, menggunakan 3rd party infrastruktur yang berbeda, library dan patch level yang berbeda pula.

Why Continuous Delivery ?

Dengan cara classic di atas, ada beberapa masalah yang biasa dihadapi :

  • Perlu step yang panjang dan lama untuk release sesuatu, sedangkan user tidak akan menunggu selama itu.
  • Ketika waktu dikonfersi ke biaya, maka cara tersebut sebenernya memakan biaya yang mahal.
  • Melakukan deployment secara manual adalah hal sama yang dilakukan berulang, sehingga merupakan hal yang membosankan.
  • Dengan manual deployment, tidak ada jaminan semua dokumentasi diikuti.
  • Manual deployment bergantung pada deployment expert. Tentu saja, jika dia sedang sakit / cuti / liburan, ini akan menjadi suatu masalah.

The Goals

Dengan alasan tersebut, Anda perlu untuk melakukan continuous delivery. Goals yang ingin dicapai dari continuous delivery ada dua, yaitu :

  • Automate Almost Everything
    Jika proses build, deploy, release test tidak secara otomatis, maka seharusnya hal ini tidak dilakukan berulang ulang. Jadi, salah satu goals yang ingin dicapai dari continuous delivery adalah segala sesuatunya harus bisa dilakukan secara otomatis.

  • Frequent
    Jika release dilakukan sesering mungkin, masalah-masalah bisa diselesaikan dengan cepat, sehingga bisa dirasakan dengan cepat pula oleh user.

The Keys

Agar dapat mencapai goals tersebut, konsep dari continuous delivery adalah sebagai berikut :

  • Put Every Change in Versioning Control
  • Every Change Should Trigger the Feedback Process
  • The Feedback Must Be Received as Soon as Possible
  • The Delivery Team Must Receive Feedback and Then Act on It

Tidak hanya source code, melainkan juga pada setiap konfigurasi harus dapat di-track, dan diotomasi. Oleh karena itu, Anda perlu meletakkan semua perubahan pada versioning control, baik itu configurasi apps, operating system, firewall, dll. Sehingga, jika konfigurasi yang baru mengalami masalah Anda dapat mengembalikan ke konfigurasi sebelumya menggunakan confirguration management tools seperti CFEngine, chef, puppet, atau ansible.

Ketika Anda melakukan perubahan ke version control, selama ini Anda tidak mendapatkan feedback apakah perubahan yang dilakukan adalah perubahan yang berarti atau tidak, apakah perubahan tersebut berjalan seperti yang diharapkan atau tidak.

Oleh karena itu, setiap commit harus trigger ke delivery pipeline. Dengan menggunakan CI tool seperti jenkins, teamcity, dll Anda dapat melakukan hal ini dengan mudah. CI tool akan melakukan *detect *pada setiap commit, kemudia melakukan automatic build, automatic test, baik itu unit test, stress test, sampai dengan user acceptance test secara otomatis, kemudian melakukan proses deploy baik itu ke staging server maupun ke production server secara otomatis. Setiap steps yang dilalui akan menghasilkan trigger ke Slack notification, apakah steps tersebut pass atau fail. Sehingga setiap orang yang melakukan perubahan akan mendapat feedback dari perubahan tersebut, kemudian memutuskan aksi selanjutnya.

Definition of Done

Kalau selama ini ketika task diberikan kepada development team, definisi apakah task tersebut telah selesai adalah dari commit ke version control. Ketika Anda sudah mengimplementasikan continuous delivery, maka setiap commit seharusnya membawa ke potensial release. Yang artinya, setiap perubahan adalah berarti dan setiap perubahan bisa di release ke user saat itu juga. Maka, dapat dikatakan bahwa definisi suatu task sudah selesai atau belum adalah ketika sudah release dan diterima oleh user atau belum.

Kami di MailTarget sedang mengimplementasi keseluruhan dari proses continuous delivery, jadi secara mendetail di setiap prosesnya dan tools yang terkait dapat dibahas pada sharing selanjutnya.

Ditulis oleh : Masas Dani (Leader of Technology and Co-founder of MailTarget)
Disunting oleh : MailTarget Team

*) Weekly sharing adalah sebuah kegiatan berdiskusi yang dilakukan oleh tim MailTarget. Para anggota tim MailTarget setiap minggunya secara bergiliran menjadi pemateri dari sesi berdiskusi tersebut.