Mengembalikan (Rollback) dalam pengembangan: apa itu, cara dan bagaimana kerjanya

Apa itu pengembalian dan rollback dalam pengembangan

Pengembalian (rollback) — operasi mengembalikan sistem ke keadaan stabil sebelumnya. Dalam konteks pengembangan, ini bisa berarti membatalkan commit di Git, mengembalikan transaksi di database, atau memulihkan versi sebelumnya dari aplikasi di server. Istilah ini berasal dari bahasa Inggris “rollback” dan telah tertanam kuat dalam kosakata pengembang di semua platform.

Kebutuhan untuk mengembalikan muncul ketika perubahan baru merusak fungsionalitas, menyebabkan kesalahan, atau tidak lolos pemeriksaan kualitas. Dalam proses pengembangan yang terorganisir dengan baik, pengembalian bukanlah tanda kegagalan, melainkan prosedur standar yang tertanam dalam alur kerja. Semakin cepat tim dapat mengembalikan perubahan yang bermasalah, semakin kecil dampak bug pada pengguna.

Alat yang berbeda menawarkan mekanisme pengembalian yang berbeda: Git memberikan pilihan antara revert yang aman dan reset yang destruktif, basis data mendukung rollback transaksional, dan sistem CI/CD dapat mengalihkan lalu lintas antar versi. Pilihan pendekatan tergantung pada konteks dan persyaratan untuk menjaga riwayat perubahan.

Git revert vs git reset: apa perbedaannya

Git revert — cara aman untuk mengembalikan yang membuat commit baru yang membatalkan perubahan sebelumnya. Riwayat tetap linier, semua commit lama disimpan. Ini adalah satu-satunya pilihan yang tepat untuk pengembalian di cabang bersama tempat beberapa pengembang bekerja. Perintah git revert tidak menghapus riwayat — ia menambahkan fakta pengembalian sebagai perubahan baru.

Git reset memindahkan penunjuk cabang saat ini ke commit yang ditentukan, membuang semua perubahan selanjutnya. Tergantung pada flag — soft, mixed, atau hard — reset memperlakukan direktori kerja dan indeks secara berbeda. Mode hard sepenuhnya menghapus perubahan dari riwayat, yang membuatnya berbahaya untuk cabang bersama dan hanya cocok untuk pekerjaan lokal.

Kapan menggunakan revert

Revert diterapkan di cabang bersama: main, develop, release. Ia mempertahankan riwayat dan memungkinkan pengembang lain memahami bahwa suatu perubahan telah dibatalkan. Setelah revert, git pull dapat dilakukan dengan aman — sistem tidak akan menghasilkan konflik terkait riwayat yang ditulis ulang. Dalam kerja tim, revert adalah standar default.

# Batalkan commit terakhir dengan membuat commit baru
git revert HEAD

# Batalkan commit tertentu berdasarkan hash
git revert a1b2c3d

Kapan menggunakan reset

Reset cocok di cabang lokal di mana Anda belum mempublikasikan perubahan. Jika Anda telah bereksperimen dan ingin membersihkan riwayat sepenuhnya — reset hard akan melakukannya. Di cabang lokal, Anda dapat menggunakan reset mixed untuk membatalkan commit tetapi menyimpan perubahan di direktori kerja untuk commit ulang.

# Batalkan commit terakhir, simpan perubahan di direktori kerja
git reset HEAD~1

# Pembatalan penuh — perubahan dihapus secara permanen
git reset --hard HEAD~2

Rollback di basis data: transaksi dan ACID

Rollback transaksi — operasi yang membatalkan semua perubahan yang dilakukan dalam transaksi saat ini dan mengembalikan basis data ke keadaan pada saat dimulainya. Ini menjamin atomicity — salah satu dari empat prinsip ACID (Atomicity, Consistency, Isolation, Durability). Jika pada tahap mana pun dari transaksi terjadi kesalahan, rollback dijalankan dan data kembali ke posisi semula.

Mekanisme rollback diimplementasikan melalui jurnal tulis depan (Write-Ahead Log, WAL). Sebelum mengubah halaman data, DBMS mencatat nilai lama dan baru ke dalam jurnal. Saat rollback, sistem membaca jurnal dan memulihkan nilai asli untuk semua halaman yang diubah. Ini menjamin bahwa bahkan dalam kasus pemadaman listrik, transaksi dapat dibatalkan dengan benar.

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint: pengembalian sebagian

Dalam transaksi panjang, nyaman menggunakan savepoint — titik penyimpanan perantara yang dapat dikembalikan tanpa mengakhiri seluruh transaksi. Ini memungkinkan penanganan kesalahan di dalam operasi kompleks tanpa kehilangan kemajuan di bagian lainnya. Savepoint didukung oleh sebagian besar DBMS relasional: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

Pengembalian saat penyebaran: strategi dan alat

Pengembalian penyebaran — mengembalikan aplikasi yang berjalan ke versi sebelumnya setelah penyebaran yang gagal. Ini adalah kemampuan kritis untuk lingkungan produksi: waktu pemulihan (MTTR) secara langsung mempengaruhi SLA dan pengalaman pengguna. Platform modern menawarkan beberapa strategi pengembalian tergantung pada arsitektur dan persyaratan ketersediaan.

Blue-green deployment

Blue-green — strategi di mana dua lingkungan identik beroperasi secara bersamaan: blue (versi saat ini) dan green (versi baru). Lalu lintas dialihkan ke green setelah penyebaran berhasil. Jika versi baru bekerja tidak benar, sakelar lalu lintas kembali ke blue. Pengembalian dilakukan seketika, tanpa penyebaran ulang — cukup mengubah perutean.

Canary release dengan pengembalian otomatis

Canary deployment mengarahkan sebagian kecil lalu lintas ke versi baru dan memantau metrik: jumlah kesalahan, waktu respons, persentase permintaan berhasil. Jika metrik memburuk, sistem secara otomatis mengembalikan canary dan mengarahkan semua lalu lintas ke versi stabil. Kubernetes dan service mesh (Istio, Linkerd) mendukung strategi ini secara bawaan.

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Contoh praktis pengembalian dalam pengembangan

Mari kita lihat tiga skenario tipikal di mana pengembang perlu mengembalikan perubahan. Setiap skenario memerlukan pendekatannya sendiri — dari perintah sederhana di terminal hingga prosedur multi-langkah dengan partisipasi CI/CD.

Skenario 1: commit tidak sengaja di main

Anda secara tidak sengaja mendorong commit dengan bug ke main. Tugas Anda adalah mengembalikan perubahan tanpa kehilangan riwayat untuk tim. Gunakan git revert untuk membuat commit pembatalan dan kemudian git push. Semua anggota tim akan melihat fakta pengembalian dan dapat melanjutkan pekerjaan tanpa konflik. Ini adalah metode yang paling aman dan transparan.

git checkout main
git pull origin main
git revert HEAD
git push origin main

Skenario 2: migrasi basis data gagal

Migrasi basis data berakhir dengan kesalahan dan sebagian data rusak. Gunakan rollback transaksional dalam skrip migrasi dan pemulihan dari cadangan untuk perubahan yang sudah diterapkan. Dalam sistem yang dirancang dengan baik, setiap migrasi dibungkus dalam transaksi — saat terjadi kesalahan, DBMS secara otomatis melakukan rollback.

Skenario 3: penyebaran dengan bug kritis

Setelah penyebaran versi baru, Anda menemukan bahwa otentikasi tidak berfungsi. Jika Anda menggunakan blue-green, pengembalian berarti mengalihkan router kembali. Jika rolling update — perintah kubectl rollout undo akan mengembalikan versi sebelumnya. Idealnya, proses pengembalian harus otomatis dan tidak memakan waktu lebih dari satu menit.