Pendahuluan

Pengenalan awal mengenai Release Strategy

Mengenai Canary Deployment bisa dilihat di Canary Deployment

Mengenai Blue Green Deployment bisa dilihat di Blue Green Deployment

Sekarang kita akan melihat Strategy Release yang lain, yaitu A/B Testing


A / B Testing


A / B Testing ini merupakan istilah yang muncul seiring dengan deployment release yang dilakukan.

Dimana versi release yang mau dilakukan mempunyai minimal 2 versi yang berbeda.

Kenapa berbeda dan minimal 2 versi ?

Bukannya harusnya cuma satu saja ?

Memang harus berbeda, dengan tujuan untuk mengetes dari 2 atau lebih versi tersebut, mana yang paling bagus memenuhi kriteria Metriks yang ingin diuji.

Kalau begitu, sebenarnya versi yang dites itu bukanlah untuk dites fungsinya secara teknikal, akan tetapi lebih dites fungsinya secara busines..


Hmmm…maksudnya ?


Iya, misalnya kalau kita mau mengetes fungsi teknikal sebuah fungsi :


  • apakah pakai Kafka atau pakai ActiveMq sebagai messaging sistemnya ? Maka hal ini sebenarnya bisa kita test di tahapan development ataupun tahapan testing. Tidak perlu sampai tahapan production.
  • mengetes fungsi aplikasi apakah lebih baik memakai infrastruktur AWS, Azure, atau GCP ?. Ini juga tentunya bisa ditest di tahapan development atau pun tahapan testing. Banyak artikel dan tools yang bisa digunakan untuk mengetes hal fungsionalitas secara teknikal tersebut.

A/B Testing tidak berfokus kepada hal diatas, akan tetapi kepada hal yang hanya bisa diketahui pada tahapan production.

Yang biasanya melibatkan aktifitas pengguna, load traffik, ataupun kebiasaan pengguna.

Sehingga pertanyaan yang akan muncul adalah :

  • Apakah dengan versi A, pengguna lebih banyak melakukan pembelian barang ?
  • Apakah dengan versi B, pengguna menjadi lebih enggan melanjutkan proses transaksi ?
  • Dari 2 versi yang direlease, versi manakah yang lebih banyak membuat penjualan atau registrasi user meningkat ?
  • dll.

Sehingga jelaslah, bahwa A/B Testing dipakai untuk Test the water juga, seperti halnya Canary Deployment.

Bedanya adalah :

  • Canary Deployment hanya mempunyai satu versi release yang mau dinaikkan ke production. Dan testingnya untuk menentukan apakah releasenya pantas untuk naik atau tidak. Kalau tidak pantas, berarti di rollbak, kalau pantas, berarti lanjut terus.
  • A/B Testing mempunyai 2 atau lebih versi release yang mau dinaikkan ke production. Dan testingnya adalah untuk menentukan versi mana yang mau dilanjutkan, dan versi mana yang mau di rollback. Jadi ada pilihan di kasus ini.

Jadi kesimpulannya, A/B Testing ini dilakukan dengan menaikkan 2 versi ke production secara bersama-sama, untuk dites dan dilihat versi mana yang akan diputuskan untuk dijadikan versi production yang sesuai dengan keinginan stakeholder.


Bagaimana caranya ?


Caranya mirip juga dengan Canary Deployment yang bertipe Side by Side Deployment

Dimana ada persentase berapa persen versi A akan ditampilkan ke pengguna, dan berapa persen versi B yang akan ditampilkan ke pengguna.

Misalkan ada 50% pengguna yang akan mendapatkan tampilan versi A.

Dan ada 50% pengguna yang mendapatkan tampilan versi B.

Bisa dengan menggunakan load balancer, atau A/B Testing tools juga yang tersedia di online.

Karena keterikatannya yang cukup dekat dengan interaksi pengguna dengan sistem, maka A/B Testing ini biasanya dikaitkan dengan tema lain terkait interaksi pengguna dan sistem, seperti :

  • Search Engine Optimization (SEO)
  • UI / UX (User Interface / User eXperience)
  • Conversion Rate atau Tingkat konversi dari sebuah versi ke sebuah metriks yang diingikan.
  • Bounce Rate
  • dll.

Hal diatas karena, interaksi pengguna dan sistem merupakan sebuah topic yang tidak selalu bisa kita kalkulasi sampai kita uji di sistem yang live di production.

Interaksi manusia dan sistem melibatkan koneksi rumit terkait psikologi, kebiasaan, dan juga motivasi pengguna dalam menggunakan sistem.