Aplikasi web tidak selesai saat kodenya jadi. Momen yang paling sering menimbulkan masalah justru saat aplikasi naik ke server, dan saat setiap pembaruan berikutnya dirilis: halaman yang tadinya normal tiba-tiba rusak, data hilang, atau perubahan yang sudah diumumkan tidak muncul. Rilis yang aman bukan soal keberuntungan. Itu hasil dari beberapa kebiasaan sederhana yang dijalankan setiap kali.
Artikel ini membahas enam pemeriksaan sebelum dan sesudah rilis aplikasi web, lengkap dengan pertanyaan yang bisa kamu ajukan ke developer atau vendor dan cara mengeceknya sendiri. Kamu tidak perlu paham teknis untuk memakainya.
Ringkasan: enam pemeriksaan rilis
| Pemeriksaan | Pertanyaan yang harus terjawab | Cara cek cepat |
|---|---|---|
| Backup sebelum menimpa | Apakah ada salinan versi yang sedang berjalan, termasuk datanya? | Minta ditunjukkan salinan yang dibuat sebelum rilis |
| Uji di tempat terpisah | Apakah perubahan sudah dicoba sebelum menyentuh aplikasi yang dipakai pengguna? | Tanya di mana dan oleh siapa rilis dicoba |
| Cocokkan sebelum menimpa | Apakah yang akan ditimpa memang versi yang diperkirakan? | Minta bukti pemeriksaan versi sebelum penimpaan dilakukan |
| Verifikasi setelah rilis | Apakah perubahan benar-benar tampil dan berfungsi? | Buka fitur yang diubah dan jalankan alur utamanya sendiri |
| Rencana rollback | Bagaimana kembali ke versi sebelumnya, dan seberapa cepat? | Minta langkahnya tertulis, lengkap dengan siapa yang menjalankan |
| Pemantauan setelah rilis | Siapa yang melihat error di 24 jam pertama? | Tanya di mana catatan error disimpan dan siapa yang membacanya |
1. Backup sebelum menimpa apa pun
Backup yang berguna mencakup dua hal: berkas aplikasi (kode, tampilan, konfigurasi) dan data (isi database dan berkas unggahan pengguna). Backup yang hanya mencakup salah satunya sering tidak cukup untuk memulihkan aplikasi yang rusak.
Cara mengecek: minta ditunjukkan salinan yang dibuat sebelum rilis terakhir, bukan sekadar janji bahwa backup "otomatis ada". Tanyakan juga berapa lama data terbaru yang mungkin hilang kalau backup dipulihkan.
Di situs Codwa sendiri, setiap berkas yang akan diganti kami salin dulu dengan akhiran .bak, dan sebelum mengubah isi banyak artikel sekaligus kami menyimpan isi lamanya dalam berkas JSON. Aturan itu berlaku untuk perubahan sekecil apa pun, bukan hanya rilis besar. Untuk dasar pengamanan aplikasi secara umum, baca juga fondasi digital yang aman untuk website bisnis.
2. Uji di tempat terpisah dulu
Perubahan yang langsung dicoba di aplikasi yang sedang dipakai pengguna menjadikan pengguna sebagai penguji. Minimal, perubahan harus dicoba lebih dulu di salinan terpisah, entah di komputer developer atau di lingkungan percobaan khusus.
Cara mengecek: tanyakan di mana rilis dicoba, siapa yang mencobanya, dan apakah ada pengujian otomatis yang dijalankan. Pengujian otomatis tidak menggantikan pengecekan manual, tapi menangkap kerusakan yang mudah terlewat, terutama di bagian yang tidak sedang diubah.
Kami menjalankan rangkaian tes otomatis di komputer lokal sebelum rilis. Kalau ada yang gagal, rilis berhenti sampai penyebabnya jelas.
3. Cocokkan kondisi sebelum menimpa
Salah satu sumber kerusakan yang paling sering diremehkan: menimpa berkas atau folder tanpa memastikan isinya memang yang diperkirakan. Server bisa saja berbeda dari yang tercatat, karena ada perbaikan darurat yang dilakukan langsung di sana, atau karena salah folder.
Cara mengecek: minta penjelasan bagaimana vendor memastikan versi yang berjalan sama dengan yang diperkirakan sebelum menimpanya. Jawaban yang baik menyebut perbandingan konkret, misalnya membandingkan isi berkas atau sidik digitalnya, bukan "seharusnya sama".
Kami pernah dua kali mengunggah ke folder yang salah dan sekali menimpa berkas tanpa memeriksa isinya lebih dulu. Dari kejadian itu kami menulis prosedur rilis tertulis: periksa dulu di server apakah isinya sesuai harapan, simpan salinan, baru tulis, dan jangan lanjut kalau ada yang tidak cocok. Standar yang sama dibahas di bab Release Engineering di Google SRE Book: rilis sebaiknya dapat diulang, dan perubahan pada proses rilis harus disengaja, bukan kebetulan.
4. Verifikasi setelah rilis
Rilis belum selesai ketika berkas sudah terunggah. Rilis selesai ketika perubahan terbukti tampil dan berfungsi di aplikasi yang dipakai pengguna.
Cara mengecek: setelah dikabari rilis selesai, buka sendiri fitur yang diubah dan jalankan alur utamanya, misalnya login, mengisi formulir, atau melakukan satu transaksi uji. Kalau perubahan menyangkut tampilan, lihat juga di HP.
Setelah menulis berkas, kami membacanya kembali dari server dan membandingkannya dengan versi yang dimaksud, lalu membuka halaman yang berubah dan memeriksa kode statusnya serta bagian yang diubah. Satu jebakan yang pernah kami temui di produksi: aplikasi menyimpan konfigurasi dan rute dalam cache, jadi perubahan yang sudah tersimpan bisa tidak berlaku sampai cache dibangun ulang. Tanpa verifikasi, kondisi seperti ini terlihat seolah rilis berhasil.
5. Rencana rollback yang lengkap
Rollback adalah langkah mengembalikan aplikasi ke versi sebelumnya ketika rilis bermasalah. Rencana ini harus ada sebelum rilis, bukan dicari saat sudah ada masalah.
Yang sering luput: rollback harus mengembalikan semua komponen rilis secara bersamaan. Mengembalikan sebagian saja bisa lebih berbahaya daripada tidak mengembalikan sama sekali.
| Komponen rilis | Yang perlu ikut kembali |
|---|---|
| Kode dan template | Berkas aplikasi versi sebelumnya |
| Tampilan dan skrip | Stylesheet dan JavaScript yang cocok dengan template tersebut, termasuk daftar berkas yang menunjuk ke keduanya |
| Konfigurasi | Pengaturan lingkungan dan cache yang selaras dengan kode |
| Data dan skema database | Salinan data sebelum rilis; perubahan database tidak selalu bisa dibalik begitu saja |
Saat mengembalikan satu rilis di situs kami sendiri, hanya sebagian komponen yang ikut kembali: template dan skrip versi lain, sementara stylesheet-nya tidak, sehingga tampilan beberapa halaman tidak cocok lagi dengan isinya dan rusak sampai kami memperbaikinya satu per satu. Pelajarannya: daftar komponen rilis harus dicek utuh sebelum mengembalikan apa pun.
6. Pemantauan setelah rilis
Banyak masalah baru muncul beberapa jam setelah rilis: di halaman yang jarang dibuka, pada tugas terjadwal, atau di perangkat tertentu. Karena itu harus ada orang yang bertugas melihatnya.
Cara mengecek: tanyakan di mana catatan error disimpan, siapa yang membacanya, dan apakah ada pemeriksaan otomatis yang memberi tahu kalau halaman penting tidak bisa diakses. Aplikasi tanpa pemantauan baru ketahuan bermasalah ketika pengguna yang melapor.
Kami memeriksa catatan error setelah rilis dan menjalankan pemeriksaan kesehatan situs secara berkala. Untuk aplikasi yang menangani data atau transaksi, pantau lebih rapat di hari pertama.
Seberapa ketat? Sesuaikan dengan jenis perubahan
Tidak semua rilis perlu prosedur yang sama berat. Semakin besar dampaknya pada data dan pengguna, semakin lengkap yang perlu dilakukan:
| Jenis perubahan | Minimum yang wajar |
|---|---|
| Perubahan teks atau tampilan kecil | Backup berkas yang diganti, lalu cek halaman yang berubah setelah rilis |
| Fitur baru atau perubahan alur kerja | Ditambah uji di tempat terpisah, rencana rollback tertulis, dan pemantauan 24 jam pertama |
| Perubahan database, login, atau pembayaran | Ditambah backup data lengkap, uji pada salinan data, jadwal di jam sepi, dan kesiapan rollback yang sudah dicoba |
Dari mana mulai kalau aplikasimu belum punya ini?
Pendekatannya tergantung kondisi yang kamu hadapi. Biasanya ada tiga situasi:
| Kondisi sekarang | Langkah yang masuk akal |
|---|---|
| Aplikasi sudah jalan, tapi tidak ada backup yang bisa ditunjukkan | Buat backup berkas dan data sekarang, lalu uji apakah bisa dipulihkan |
| Developer atau vendor merilis tanpa proses yang jelas | Minta enam jawaban di tabel ringkasan, dan sepakati prosedur rilis tertulis |
| Aplikasi belum dibuat | Masukkan backup, uji, rollback, dan pemantauan ke ruang lingkup kerja sejak awal |
Kalau kamu masih menimbang apakah bisnismu perlu aplikasi web atau dashboard internal, baca kapan bisnis butuh custom web app atau dashboard internal. Biaya pemeliharaan dan pembaruan setelah tayang termasuk faktor yang dibahas di biaya membuat aplikasi web, dan untuk versi pertama yang lebih ringan, lihat cara membuat MVP untuk aplikasi web startup.
Pertanyaan yang sering muncul
Apakah aplikasi kecil perlu server percobaan terpisah?
Tidak selalu. Untuk aplikasi kecil, salinan di komputer developer yang dijalankan dengan pengujian otomatis sudah jauh lebih baik daripada langsung mengubah aplikasi yang dipakai pengguna. Semakin penting datanya, semakin perlu lingkungan percobaan yang menyerupai aslinya.
Seberapa sering backup perlu dibuat?
Tergantung seberapa sering data berubah. Tanyakan pada dirimu: berapa lama data terbaru yang rela hilang kalau terjadi kerusakan? Kalau jawabannya "hampir tidak ada", backup harus lebih sering dan datanya perlu dicek apakah bisa dipulihkan.
Langkah berikutnya
Pilih satu aplikasi yang kamu pakai dan ajukan tiga pertanyaan ke tim yang mengelolanya: di mana salinan backup terakhir, bagaimana cara kembali ke versi sebelumnya, dan siapa yang melihat error setelah rilis. Jawabannya biasanya sudah menunjukkan bagian mana yang paling perlu dibereskan.
Diskusikan pengembangan dan pemeliharaan aplikasi web bisnismu dengan Codwa Studio
Ditinjau oleh Hammam Adi Praksasa Putra. Dipublikasikan: 6 Oktober 2026.
