Lingkungan Uji: Menguji Perangkat Lunak Sebelum Dipakai Pelanggan

Lingkungan Uji adalah tempat menguji perangkat lunak sebelum perubahan dipasang pada sistem yang dipakai pelanggan. Ibarat gladi resik, bentuknya perlu menyerupai sistem utama meski ukurannya lebih kecil. Pakai basis data dan cara pemasangan yang sesuai, tetapi pisahkan akun pembayaran serta pengiriman pesan. Untuk perubahan basis data besar, uji juga durasi dan gangguan terhadap pekerjaan lain.

Lingkungan uji ini membantu menemukan kesalahan struktur data, konfigurasi, dan integrasi sebelum perubahan dipakai pelanggan. Bentuknya menyerupai sistem utama, tetapi kapasitasnya dapat diperkecil agar biaya pengujian tetap sesuai kebutuhan.

Apa yang harus sama dengan sistem pelanggan?

Tim UKM perlu menjaga kesesuaian lingkungan uji dengan sistem produksi, terutama jenis komponen dan cara pemasangannya. Prinsip dev/prod parity dari Twelve-Factor App tegas soal ini: jangan pakai backing service berbeda di tiap lingkungan, misalnya SQLite di lokal dan PostgreSQL di produksi, karena ketidakcocokan itu memicu kesalahan yang baru muncul setelah diterapkan. Perubahan struktur data yang jalan mulus di SQLite bisa gagal total di Postgres.

Jadi lingkungan uji butuh mesin basis data dan versi yang sama dengan produksi, struktur data yang sama yang diterapkan lewat alat perubahan struktur data yang sama seperti yang dipakai di produksi, dan mekanisme penerapan yang sama: kontainer yang sama, pola variabel lingkungan yang sama.

Basis data berbeda atau struktur yang diubah manual dapat membuat pengujian lulus meski penerapan di produksi gagal. Gunakan perubahan otomatis yang sama di kedua lingkungan.

Apa yang bisa diperkecil untuk menghemat biaya?

Inilah yang menjaga biaya tetap rendah. Panduan lingkungan uji dari Increment menjelaskannya dengan jelas: lingkungan uji sebaiknya menjalankan kode yang sama dengan produksi, dan memakai variabel lingkungan untuk mengarah ke endpoint dan basis data berbeda. Basis data itu sendiri punya konfigurasi serta struktur data yang sama seperti produksi, hanya saja skalanya lebih kecil dengan data dummy. Pertahankan jenis komponen dan konfigurasi, lalu kurangi kapasitas sesuai kebutuhan uji.

Untuk kebanyakan pengujian fungsi — apakah pembayaran jalan, apakah kolom baru tersimpan benar, apakah kueri laporan mengembalikan baris yang tepat — beberapa ribu baris data yang representatif sudah cukup. Jawabannya sudah kelihatan dari situ. Sepuluh juta baris tidak dibutuhkan untuk memverifikasi fitur berfungsi. Volume besar diperlukan saat mengukur kinerja pada skala produksi. Pisahkan kebutuhan tersebut dari pengujian fungsi harian.

Bagaimana menguji tanpa mengirim uang dan pesan sungguhan?

Hampir semua payment processor dan messaging API yang dipakai SME menyediakan sandbox. Stripe Sandboxes adalah lingkungan test terisolasi yang tidak pernah memproses pembayaran lewat jaringan kartu sungguhan. Sandbox Midtrans menjalankan simulator berbasis web yang meniru respons bank, dan secara eksplisit memperingatkan agar tidak mencoba membayar transaksi Sandbox dengan rekening bank sungguhan.

Endpoint test-mode Xendit dibuat khusus untuk mensimulasikan penyelesaian pembayaran. WhatsApp Cloud API otomatis menyediakan nomor bisnis test begitu setup selesai.

Pisahkan kredensial pengujian dari produksi dan pilih melalui variabel lingkungan. Dengan begitu, kode integrasi yang sama tetap dapat diuji, termasuk pengiriman ulang dan pemberitahuan otomatis melalui webhook, tanpa pembayaran atau pesan produksi.

Bagaimana menguji perubahan basis data dari pencadangan?

Untuk perubahan basis data, ukur juga durasi dan dampak penguncian selain hasil akhirnya. Perubahan struktur data yang menambah satu kolom jalan seketika di tabel dev berisi sepuluh baris. Jalankan perintah yang sama di tabel produksi berisi sepuluh juta baris dengan trafik tulis aktif, ceritanya berubah.

Di PostgreSQL, banyak operasi ALTER TABLE membutuhkan penguncian ACCESS EXCLUSIVE, yang memblokir pembacaan dan penulisan ke tabel itu selama operasi berlangsung. Di tabel besar dengan kontensi tinggi, itu bisa berarti tabel order atau tabel booking terkunci selama beberapa menit sementara pelanggan menunggu. Panduan zero-downtime perubahan struktur data menegaskan hal yang sama: durasi penguncian berskala dengan ukuran tabel dan trafik konkuren. Tidak ada cara mengetahui perilaku sebuah perubahan struktur data sampai ia dijalankan di data yang berbentuk seperti produksi.

Pulihkan pencadangan ke lingkungan uji dengan akses terbatas. Samarkan data pribadi jika memungkinkan, lalu jalankan perubahan basis data di sana terlebih dahulu. Saya pernah menulis kenapa pencadangan yang belum pernah direstore bukan pencadangan. Proses pemulihan yang sama yang membuktikan pencadangan itu berfungsi juga menyiapkan panggung untuk latihan perubahan struktur data. Satu pengujian ini memeriksa kemampuan pemulihan sekaligus menilai dampak perubahan.

Jika perubahan struktur data mengunci tabel selama empat detik di lingkungan uji, hasil itu membantu menilai risikonya, tetapi bukan perkiraan langsung untuk produksi. Jumlah data, beban serentak, dan kapasitas mesin dapat mengubah durasi. Penguncian empat menit dapat ditemukan lebih awal di lingkungan uji, ketika masih ada waktu untuk memperbaiki perubahan sebelum pelanggan terdampak.

Seperti apa lingkungan uji untuk tim kecil?

Untuk kebanyakan SME, lingkungan uji cukup satu VM yang menjalankan docker compose, dengan variabel lingkungan yang mengarah ke kredensial sandbox, bukan yang live. Kebutuhan tersebut tidak selalu memerlukan klaster Kubernetes atau lokasi pemulihan bencana tersendiri. Tujuannya paritas bentuk — kontainer yang sama, struktur data yang sama, alat penerapan yang sama — pada skala yang muat di satu mesin sederhana.

Apa yang bisa dipelajari dari gangguan GitLab?

Pada Januari 2017, seorang tenaga teknik di GitLab menjalankan perintah manual saat mencoba memperbaiki replikasi yang rusak, dan tanpa sengaja menghapus direktori PostgreSQL primer, melenyapkan sekitar 300GB data produksi. GitLab punya lima mekanisme pencadangan dan replikasi terpisah. Saat tim mencari salinan untuk pemulihan, sebagian besar mekanisme tidak berfungsi.

Pencadangan pg_dump yang diunggah ke S3 sudah rusak diam-diam selama berbulan-bulan akibat ketidakcocokan versi PostgreSQL, menghasilkan berkas kosong. Disk salinan sesaat diaktifkan di server NFS tapi tidak pernah di server basis data. Replication ke basis data sekunder tidak berguna karena data di host itu juga ikut terhapus dalam insiden yang sama.

Yang akhirnya menyelamatkan mereka adalah salinan sesaat LVM yang diambil sekitar enam jam sebelumnya, salinan sesaat yang sudah tersalin ke lingkungan uji sebagai bagian dari proses refresh lingkungan uji rutin GitLab, bukan latihan pemulihan bencana. Tim berhasil pulih dengan kehilangan data sekitar enam jam, bukan hampir sehari penuh.

Postmortem resmi mereka menyatakan pelajarannya secara langsung: tidak ada kepemilikan atas prosedur pencadangan, akibatnya tidak ada yang bertanggung jawab mengujinya. Semua mekanisme terlihat baik-baik saja di atas kertas. Pemulihan dari salinan tersebut belum pernah diuji secara memadai.

Apa yang perlu dicek sebelum perubahan dirilis?

1. Paritas schema — mesin basis data, versi, dan alat perubahan struktur data yang sama seperti produksi, diterapkan sungguhan, bukan diperkirakan.
2. Integrasi di lingkungan pengujian terisolasi — setiap payment gateway dan messaging API mengarah ke mode uji, ditukar lewat variabel lingkungan.
3. Backup yang teruji restore — bukan sekadar berkas yang ada, tapi berkas yang benar-benar sudah direstore ke lingkungan uji dan diverifikasi.
4. Langkah latihan perubahan struktur data yang berulang — setiap perubahan struktur data dijalankan dulu di atas pemulihan berbentuk produksi sebelum dijalankan di produksi sesungguhnya.

Untuk tim kecil, mulai dengan satu mesin virtual, satu konfigurasi Compose, dan jadwal pengujian pemulihan. Sesuaikan kapasitas jika perubahan yang diuji memerlukan data atau beban lebih besar.