Rollback: Saat Kembali ke Versi Sebelumnya Tidak Sesederhana Kedengarannya

Anda baru saja men-deploy versi baru aplikasi. Lima menit kemudian, error mulai bermunculan di dashboard monitoring. Pengguna melaporkan masalah. Insting pertama Anda jelas: kembalikan versi lama. Itulah rollback dalam bentuk paling sederhana — kembali ke status stabil terakhir dan memberi Anda waktu untuk mencari tahu apa yang salah.

Bagi banyak tim, rollback adalah strategi pemulihan default. Ini masuk akal secara intuitif. Jika versi baru merusak sesuatu, versi lama berfungsi dengan baik. Cukup tukar kembali. Namun kenyataannya lebih rumit. Rollback bekerja secara berbeda tergantung pada apa yang Anda kembalikan: kode aplikasi, skema database, atau konfigurasi infrastruktur. Masing-masing memiliki mekanisme, risiko, dan keterbatasannya sendiri.

Rollback Aplikasi: Kasus yang Relatif Mudah

Rollback kode aplikasi adalah skenario yang paling sederhana. Anda memiliki instance aplikasi yang berjalan, dan Anda mengganti versi baru dengan versi lama. Cara melakukannya tergantung pada strategi deployment Anda.

Jika Anda menggunakan blue-green deployment, rollback berarti mengalihkan traffic kembali ke lingkungan yang masih menjalankan versi lama. Lingkungan green menjadi aktif kembali, dan lingkungan blue dikeluarkan dari rotasi. Peralihan ini bisa terjadi dalam hitungan detik karena kedua lingkungan sudah berjalan dan siap.

Jika Anda menggunakan canary release, rollback berarti menghentikan aliran traffic ke versi baru dan mengarahkan semuanya kembali ke versi sebelumnya. Canary dimatikan, dan versi stabil menangani semua permintaan lagi.

Jika Anda menggunakan rolling update biasa, rollback berarti men-deploy ulang artefak sebelumnya ke server atau container yang sama. Ini memakan waktu lebih lama karena setiap instance perlu diperbarui satu per satu, tetapi prosesnya masih dapat diprediksi.

Misalnya, jika Anda menggunakan Kubernetes, satu perintah dapat mengembalikan deployment ke revisi sebelumnya:

kubectl rollout undo deployment/my-app -n production

Perintah ini memberi tahu Kubernetes untuk menurunkan skala pod baru dan menaikkan skala pod lama, secara efektif membalikkan rolling update. Anda juga dapat menentukan revisi tertentu jika perlu kembali lebih dari satu langkah:

kubectl rollout undo deployment/my-app -n production --to-revision=3

Untuk melihat riwayat revisi sebelum rollback:

kubectl rollout history deployment/my-app -n production

Keuntungan utama rollback aplikasi adalah tidak mengubah data. Anda hanya mengubah kode mana yang menangani permintaan masuk. Database tetap tidak tersentuh, dan tidak ada data pengguna yang hilang atau berubah. Ini membuat rollback aplikasi relatif aman dan cepat.

Diagram alir berikut memetakan jalur keputusan untuk setiap jenis rollback yang dibahas di bagian ini.

flowchart TD A[Jenis rollback apa?] --> B[Aplikasi] A --> C[Database] A --> D[Infrastruktur] B --> B1[Blue-Green: alihkan traffic] B --> B2[Canary: hentikan traffic canary] B --> B3[Rolling: deploy ulang artefak lama] C --> C1[Skema berubah?] C1 -- Ya --> C2[Jalankan down migration] C1 -- Tidak --> C3[Tidak perlu aksi DB] C2 --> C4[Ada risiko kehilangan data?] C4 -- Ya --> C5[Restore dari backup] C4 -- Tidak --> C6[Skema dikembalikan] D --> D1[Kembalikan file konfigurasi] D1 --> D2[Periksa dependensi] D2 --> D3[Terapkan status sebelumnya]

Rollback Database: Di Mana Segalanya Menjadi Berantakan

Rollback database adalah hal yang sangat berbeda. Database menyimpan status yang terus berubah. Ketika versi aplikasi baru memodifikasi skema database — menambahkan kolom, mengganti nama tabel, mengubah tipe data — rollback kode aplikasi saja tidak cukup. Anda juga harus mengembalikan struktur database ke status sebelumnya.

Di sinilah kompleksitas berlipat ganda. Pertimbangkan skenario sederhana: versi baru Anda menambahkan kolom bernama phone_number ke tabel users. Aplikasi mulai menulis nomor telepon ke kolom tersebut. Setelah satu jam, Anda menemukan bug kritis dan memutuskan untuk rollback. Anda men-deploy kode aplikasi lama, tetapi kode lama tidak tahu tentang kolom phone_number. Lebih penting lagi, data yang sudah ditulis ke kolom tersebut perlu ditangani. Apakah Anda menghapusnya? Memindahkannya ke tempat lain? Membiarkannya dan berharap kode lama mengabaikannya?

Pendekatan teraman adalah membuat setiap migrasi database dapat dibalikkan sejak awal. Ini berarti setiap skrip migrasi menyertakan langkah up yang menerapkan perubahan dan langkah down yang membatalkannya. Saat Anda rollback, Anda menjalankan migrasi down untuk mengembalikan skema sebelumnya.

Namun tidak semua perubahan benar-benar dapat dibalikkan tanpa kehilangan data. Jika versi baru Anda menghapus kolom yang masih digunakan, rollback berarti membuat ulang kolom tersebut dan mengembalikan datanya dari backup. Jika versi baru Anda menggabungkan dua tabel menjadi satu, rollback berarti memisahkannya kembali dan mencari tahu baris mana yang termasuk ke tabel mana. Operasi ini berisiko, memakan waktu, dan seringkali memerlukan intervensi manual.

Banyak tim menerima kenyataan ini dan memilih untuk menghindari rollback database sama sekali. Sebagai gantinya, mereka berinvestasi besar dalam pengujian migrasi sebelum deployment, menjalankannya di lingkungan staging yang mencerminkan data produksi semirip mungkin. Ketika sesuatu benar-benar salah, mereka lebih suka menulis perbaikan maju (forward fix) daripada mencoba mengembalikan ke belakang.

Rollback Infrastruktur: Jaring Ketergantungan yang Tersembunyi

Rollback infrastruktur berarti mengembalikan perubahan pada server, aturan jaringan, load balancer, atau layanan pendukung. Jika Anda mengelola infrastruktur dengan alat seperti Terraform, Ansible, atau Pulumi, rollback biasanya melibatkan penerapan versi sebelumnya dari file konfigurasi Anda.

Tantangannya di sini adalah perubahan infrastruktur jarang hanya mempengaruhi satu hal. Perubahan pada aturan firewall dapat memutus konektivitas database. Perubahan pada konfigurasi load balancer dapat mempengaruhi routing traffic untuk beberapa layanan. Mengembalikan file state Terraform dapat menghapus resource yang dibuat oleh versi baru, yang dapat menimbulkan masalah lain secara berantai.

Rollback infrastruktur juga memakan waktu. Menerapkan konfigurasi sebelumnya memerlukan menjalankan proses provisioning yang sama yang menciptakan infrastruktur pada awalnya. Jika infrastruktur Anda besar atau kompleks, ini bisa memakan waktu menit atau bahkan jam — waktu di mana pengguna Anda mengalami error.

Keterbatasan Rollback sebagai Strategi

Rollback bukanlah jaring pengaman universal. Ini hanya berfungsi ketika tiga kondisi terpenuhi:

Pertama, versi lama harus tetap stabil dan kompatibel dengan status sistem saat ini. Jika versi baru Anda berjalan selama berjam-jam dan pengguna memasukkan data yang tidak dapat dibaca oleh versi lama, rollback akan menyebabkan kehilangan atau kerusakan data.

Kedua, masalah harus ada di kode atau konfigurasi, bukan di data. Jika masalahnya adalah pengguna menyalahgunakan fitur atau kualitas data menurun, rollback kode tidak akan memperbaiki apa pun.

Ketiga, rollback harus lebih cepat daripada waktu yang dibutuhkan untuk memperbaiki maju. Jika rollback memakan waktu tiga puluh menit tetapi menulis hotfix memakan waktu sepuluh menit, rollback adalah opsi yang lebih lambat.

Ada juga risiko perilaku. Tim yang terlalu mengandalkan rollback bisa menjadi ceroboh dalam pengujian pra-deployment. Pola pikirnya menjadi "jika rusak, kita akan rollback saja." Ini berbahaya karena rollback memiliki biaya nyata. Pengguna yang melihat error atau kehilangan data tidak peduli bahwa Anda pulih dalam lima menit. Kepercayaan mereka sudah rusak.

Daftar Periksa Praktis Sebelum Memutuskan Rollback

Sebelum Anda menjalankan rollback, ajukan pertanyaan-pertanyaan ini:

  • Apakah versi lama masih berjalan dan siap menerima traffic?
  • Apakah skema database berubah dengan cara yang membuat kode lama tidak kompatibel?
  • Berapa lama versi baru sudah live, dan berapa banyak data pengguna yang telah dimasukkan?
  • Dapatkah migrasi database dibalikkan tanpa kehilangan data?
  • Apakah rollback lebih cepat daripada menulis perbaikan maju?
  • Sudahkah Anda mengomunikasikan rencana rollback ke tim dan pemangku kepentingan?

Jika jawaban untuk salah satu pertanyaan ini menimbulkan tanda bahaya, pertimbangkan untuk melakukan roll-forward.

Kesimpulan

Rollback adalah strategi pemulihan yang sah, tetapi bukan tombol undo gratis. Rollback aplikasi relatif aman dan cepat. Rollback database berisiko dan seringkali tidak dapat dibalikkan. Rollback infrastruktur lambat dan dapat memiliki efek berantai. Sebelum Anda menjadikan rollback sebagai respons default, pahami apa yang Anda kembalikan dan berapa biaya sebenarnya. Terkadang langkah yang lebih baik adalah memperbaiki maju — dan itulah yang akan kita lihat selanjutnya.