Langkah Membikin Perubahan pada Aplikasi dengan Kondusif

Daftar Isi:

Sebelum merilis aplikasi ke publik, kita Bisa bebas Membikin perubahan sebesar apapun. Karena hanya kita yang menggunakan aplikasi tersebut.

Tetapi, ketika aplikasi sudah rilis ke publik, kita Tak Bisa Kembali mengubah aplikasi dengan semena-mena, karena Kalau perubahannya bermasalah, maka pengguna akan kecewa dan Tak akan menggunakan aplikasi kita Kembali.

Oleh karena itu, sebaiknya kita lakukan langkah-langkah yang Bisa meminimalisir terjadinya kesalahan.

Persiapkan Hal Terburuk

Meskipun kita sudah berusaha sebaik mungkin, kita Tak Bisa menjamin bahwa perubahan yang kita buat Tak akan bermasalah. Oleh karena itu, kita perlu mempersiapkan apabila terjadi hal terburuk.

Lakukan Back Up Data

Sebelum melakukan perubahan, pastikan kita sudah melakukan back up data. Dengan melakukan back up data, kita Bisa mengembalikan data ke kondisi semula Kalau terjadi masalah.

Yang perlu di back up Bisa jadi antara lain:

• Database
• Aset aplikasi (gambar, video, dll)
• Konfigurasi aplikasi
• Kode aplikasi

Tapi Tak Seluruh wajib di back up, karena tergantung perubahan apa yang kita lakukan.

Berikan Langkah Rollback

Apa itu Rollback?

Rollback adalah proses mengembalikan aplikasi ke versi sebelumnya. Kalau terjadi masalah setelah perubahan, maka kita Bisa melakukan rollback Kepada mengembalikan aplikasi ke versi sebelumnya.

Langkah Agar Aplikasi Bisa Di-rollback

Supaya Bisa melakukan rollback, kita Bisa gunakan Langkah-Langkah berikut:

• Membikin backup dari aplikasi sebelum diubah, seperti yang sudah dijelaskan di atas.
• Membikin skrip Kepada mengembalikan database ke versi sebelumnya. Skrip ini Biasa disebut dengan skrip migrasi database.
• Menggunakan version control seperti Git. Dengan menggunakan Git, kita Bisa mengembalikan kode aplikasi ke versi sebelumnya dengan mudah.

Beri Waktu Kepada Memeriksa dan Mengawasi

Pastikan Demi melakukan perubahan, kita memberikan waktu yang cukup Kepada memeriksa dan mengawasi aplikasi. Sehingga, Kalau ditemukan adanya masalah, kita Bisa segera memperbaiki masalah tersebut.

Jadi, sebaiknya kita Tak melakukan perubahannya di penghujung waktu kerja, atau jadwalkan waktu lembur dari awal Kalau perlu.

Jadwalkan Perubahan pada Waktu yang Betul

Kalau perubahan yang dilakukan memerlukan downtime atau waktu aplikasi Tak Bisa diakses, maka jadwalkan perubahan pada waktu yang Betul. Misalnya, jadwalkan perubahan pada waktu-waktu yang sedikit pengguna, atau jadwalkan perubahan pada waktu yang Tak krusial.

Gunakan Observability Tools

Apa itu Observability Tools?

Observability tools adalah tools yang digunakan Kepada memantau aplikasi. Dengan observability tools, kita Bisa Menonton bagaimana aplikasi berjalan, dan Kalau terjadi masalah, tools tersebut Bisa memberitahu kita tentang detail masalah tersebut seperti:

• Error yang terjadi
• Waktu terjadinya error
• Letak terjadinya error
• User yang terkena error

Misalnya Observability Tools

Beberapa Misalnya observability tools yang Bisa kita gunakan adalah:

• Grafana
• Prometheus
• Sentry

Jangan Buat Perubahan yang Besar secara Dadakan

Seiring waktu, aplikasi yang aktif digunakan biasanya akan mengalami perubahan. Contohnya berupa perbaikan bug, penambahan fitur, atau perubahan lainnya.

Sebuah perubahan terkadang Bisa mengubah Langkah kerja aplikasi secara signifikan dan berisiko memunculkan masalah-masalah yang Tak dapat diprediksi.

Oleh karena itu, kita memerlukan strategi agar Dampak samping dari perubahan yang kita buat Bisa diminimalisir.

Pertahankan Backward Compatibility

Apa itu Backward Compatibility?

Backward compatibility adalah kemampuan aplikasi Kepada tetap berjalan dengan Berkualitas meskipun Terdapat perubahan pada aplikasi tersebut dengan mempertahankan dukungan terhadap versi-versi sebelumnya.

Misalnya Kasus Tanpa Backward Compatibility

Misalnya, kita Mempunyai data user seperti berikut:

Kemudian kita Ingin mengubah kolom first_name dan last_name menjadi full_name.

Kalau kita langsung mengubah first_name dan last_name menjadi full_name pada kode dan database, maka kita harus memastikan proses deploy berjalan dengan Berkualitas, seperti:

1. Mengkonversi data Pelan ke format baru pada database
2. Menimpa kode Pelan dengan kode baru
3. Memastikan aplikasi berjalan dengan Berkualitas

Selama menjalankan langkah-langkah di atas, aplikasi Tak Bisa diakses oleh pengguna, jadi kita hanya Bisa men-deploy-nya pada waktu-waktu tertentu. Kemudian, Kalau ditemukan Terdapat masalah muncul setelah deploy, maka kita perlu melakukan rollback, Yakni mengembalikan aplikasi ke versi sebelumnya.

Misalnya Penerapan Backward Compatibility

Pada Misalnya di atas, proses rollback Tak terlihat sulit. Tapi, pada perubahan yang lebih besar, proses rollback Bisa memakan waktu yang cukup Pelan.

Oleh karena itu, sebaiknya kita pertahankan backward compatibility. Sehingga, langkah yang kita lakukan adalah seperti ini:

1. Membikin kolom full_name pada database tanpa menghapus kolom first_name dan last_name.

2. Mengubah kode create dan update Kepada mengisi kolom full_name.

// Sebelum
const user = {
  "first_name": "Alice",
  "last_name": "Zuberg",
  "email": "[email protected]"
};

createUser(user);

// Sesudah
const user = {
  "full_name": "Alice Zuberg",
  "first_name": "Alice",
  "last_name": "Zuberg",
  "email": "[email protected]"
};

createUser(user);

3. Mengubah kode read data menggunakan kolom full_name, tetapi ketika full_name Tak Terdapat, maka gunakan first_name dan last_name

if (user.full_name !== '') {
  return user.full_name;
} else {
	return `${user.first_name} ${user.last_name}`;
}

Dengan begitu, kita jadi mendapat beberapa keuntungan:

• Deploy dapat dilakukan bertahap. Misalnya migrasi database terlebih dahulu, kemudian deploy kode aplikasi, atau sebaliknya.
• Tahapan deploy dapat dilakukan pada waktu yang berbeda. Misalnya hari ini migrasi database, kemudian besok deploy kode, atau sebaliknya.
• Pengecekan aplikasi lebih mudah
• Proses deploy dan rollback lebih Segera
• Risiko error lebih kecil
• Kalau Terdapat bagian yang lupa diubah, aplikasi tetap berjalan dengan Berkualitas

Setelah kita Tentu bahwa Seluruh bagian aplikasi sudah menggunakan full_name, maka kita Bisa menghapus kolom first_name dan last_name dari database.
Kemudian, Kalau Tak Terdapat masalah setelah penghapusan kolom dari database, kita Bisa menghapus kode yang Tak digunakan Kembali.

Buat Versioning

Dalam dunia aplikasi mobile dan desktop, terkadang pengguna Tak menggunakan versi terbaru dari aplikasi. Kalau aplikasi tersebut berinteraksi dengan API di server, maka kita wajib Kepada Membikin versioning.

Buat Feature Flag

Feature flag adalah teknik yang memungkinkan kita Kepada mengontrol fitur yang akan diaktifkan atau dinonaktifkan. Dengan feature flag, kita Bisa mengaktifkan fitur baru hanya Kepada sebagian pengguna, atau mengaktifkan fitur baru hanya Kepada pengguna yang kita pilih.

Baca lebih detail apa itu feature flag

Dengan feature flag, kita Bisa menguji fitur baru tanpa harus merilisnya ke publik. Kalau fitur baru tersebut bermasalah, kita Bisa menonaktifkannya dengan Segera.

Salah satu Langkah termudah Kepada Membikin feature flag adalah dengan menggunakan konfigurasi. Misalnya, kita Bisa Membikin konfigurasi seperti ini:

FEATURE_FLAG_NEW_FEATURE=true

Kemudian, kita Bisa menggunakan konfigurasi tersebut pada kode aplikasi:

if (process.env.FEATURE_FLAG_NEW_FEATURE) {
  // Tampilkan fitur baru
} else {
  // Tampilkan fitur Pelan
}

Lakukan Testing yang Efektif

Programmer yang Berkualitas Niscaya menguji perubahan aplikasi sebelum di rilis ke publik. Tapi, Tak Seluruh programmer melakukan testing yang efektif. Testing yang efektif berarti testing yang menguji Seluruh kemungkinan yang Bisa terjadi pada aplikasi. Agar Bisa melakukan testing yang efektif, kita perlu melakukan hal berikut:

Buat Test Case

Test case adalah daftar kasus yang akan diuji. Test case Bisa berupa daftar input dan output yang diharapkan, atau daftar langkah-langkah yang harus dilakukan Kepada menguji aplikasi.

Kita Bisa menulis test case di mana saja; di notepad, excel, maupun software lain yang Bisa digunakan Kepada menulis. Dari pengalaman saya, kebanyakan QA yang saya temui menggunakan Google Sheet Kepada menulis daftar test case.

Misalnya Test Case

Misalnya, kita Ingin menguji sebuah fitur manajemen pengguna, maka kita Bisa Membikin test case seperti ini:

No Langkah	Langkah Tes	Hasil yang Diharapkan	Hasil
1	Klik menu manajemen pengguna	Halaman manajemen pengguna terbuka	✅
2	Klik tombol tambah pengguna	Halaman tambah pengguna terbuka	✅
3	Isi form tambah pengguna	Form terisi	❌ Tak dapat memilih role karena Tak muncul
4	Klik tombol simpan pengguna	Muncul toast dan pindah ke halaman edit pengguna	❗ Belum dapat dilakukan

Dengan menuliskan test case, kita Bisa menguji Seluruh kemungkinan yang Bisa terjadi pada aplikasi dengan cermat dan tercatat.

Beda halnya Kalau kita Tak menuliskan test case, maka kita jadi menguji aplikasi secara asal-asalan, dan kemungkinan besar Bisa melewatkan beberapa kasus yang Bisa terjadi pada aplikasi.

Terapkan Automated Testing

Setelah Membikin test case, kita Bisa menguji aplikasi dengan test case tersebut. Tetapi, Kalau kita menguji aplikasi secara manual, maka kita akan membuang banyak waktu dan tenaga. Terlebih Kembali, Tak jarang suatu perubahan itu Bisa tanpa sengaja merusak fitur yang sudah berjalan dengan Berkualitas. Oleh karena itu, kita perlu menggunakan automated testing.

Automated testing adalah proses pengujian aplikasi dengan menggunakan software yang Bisa menguji aplikasi secara Mekanis. Dengan automated testing, kita Bisa menguji aplikasi dengan Segera dan efektif.

Terdapat banyak software automated testing yang Bisa kita gunakan, seperti Selenium, Cypress, dan lain-lain.

Ilustrasi