Cara Memeriksa Apakah Versi Baru Anda Benar-Benar Berfungsi

Anda baru saja menyelesaikan deployment. Pipeline hijau. Versi baru sudah live. Seseorang di tim membuka browser, memuat halaman utama, dan berkata "Sepertinya baik-baik saja." Semua orang lega dan melanjutkan pekerjaan.

Perasaan itu memang akrab, tapi juga berbahaya. Satu orang memeriksa satu halaman bukanlah proses yang dapat diulang. Itu tidak memberi tahu Anda apakah fitur lain berfungsi. Itu tidak memberi tahu Anda apakah API merespons dengan benar. Dan tentu saja tidak memberi tahu Anda apakah pengguna akan mendapatkan pengalaman yang baik.

Jika verifikasi deployment Anda bergantung pada perasaan seseorang, pada dasarnya Anda menggunakan pengguna sebagai sistem deteksi pertama Anda. Saat mereka melaporkan masalah, kerusakan sudah menyebar.

Masalah dengan Pemeriksaan Manual

Pemeriksaan manual setelah deployment memiliki tiga kelemahan mendasar.

Pertama, tidak konsisten. Orang yang memeriksa hari ini mungkin melihat hal yang berbeda dari orang yang memeriksa besok. Satu orang mungkin memeriksa halaman login. Orang lain mungkin memeriksa fitur pencarian. Anda tidak bisa membandingkan hasil antar deployment karena pemeriksaannya sendiri terus berubah.

Kedua, pemeriksaan manual itu dangkal. Manusia hanya bisa memeriksa beberapa halaman atau endpoint dalam waktu yang wajar. Alur kerja kompleks yang melibatkan banyak langkah jarang diuji secara manual setelah setiap deployment. Hal yang paling sering rusak justru alur multi-langkah yang tidak pernah diperiksa siapa pun.

Ketiga, pemeriksaan manual itu lambat. Saat seseorang selesai memeriksa beberapa halaman, deployment mungkin sudah melayani ribuan pengguna. Jika ada yang rusak, pengguna tersebut sudah terkena dampaknya.

Di sinilah verifikasi sebagai proses terstruktur berperan. Verifikasi adalah tindakan memeriksa apakah versi yang baru di-deploy benar-benar berjalan dengan benar, bukan hanya dari sisi server tetapi dari perspektif pengguna. Ini menjawab satu pertanyaan: "Dapatkah orang menggunakan versi ini tanpa menemui masalah yang jelas?"

Mulai dengan Smoke Test

Bentuk verifikasi paling sederhana adalah smoke test. Istilah ini berasal dari elektronik: saat Anda menyalakan papan sirkuit baru untuk pertama kali, Anda memeriksa apakah ada asap yang keluar. Tidak ada asap berarti tidak ada komponen yang terbakar, dan Anda bisa melanjutkan ke pengujian yang lebih dalam.

Dalam istilah deployment, smoke test menjalankan pemeriksaan dasar untuk memastikan versi baru tidak langsung rusak. Pemeriksaan ini sederhana dan cepat. Mereka tidak memverifikasi logika bisnis. Mereka hanya menangkap kegagalan yang paling jelas.

Smoke test tipikal mungkin mencakup:

Berikut adalah contoh konkret skrip smoke test yang bisa Anda jalankan setelah setiap deployment:

#!/bin/bash
# smoke-test.sh - Run basic smoke checks after deployment

BASE_URL="http://localhost:8080"
FAILED=0

check_endpoint() {
  local url="$1"
  local description="$2"
  local status=$(curl -s -o /dev/null -w "%{http_code}" "$url")
  if [ "$status" -eq 200 ]; then
    echo "PASS: $description"
  else
    echo "FAIL: $description (HTTP $status)"
    FAILED=1
  fi
}

check_endpoint "$BASE_URL/" "Homepage returns 200"
check_endpoint "$BASE_URL/login" "Login page renders"
check_endpoint "$BASE_URL/api/health" "Health endpoint responds"
check_endpoint "$BASE_URL/static/css/main.css" "CSS asset loads"

if [ "$FAILED" -eq 1 ]; then
  echo "Smoke tests failed. Rollback recommended."
  exit 1
else
  echo "All smoke tests passed."
fi

• Memuat halaman utama dan memastikan mengembalikan HTTP 200
• Memeriksa bahwa halaman login dirender tanpa error
• Memverifikasi bahwa endpoint API kritis merespons dalam waktu yang wajar
• Memastikan aset statis seperti file CSS dan JavaScript dimuat dengan benar

Persyaratan utamanya adalah konsistensi. Anda perlu menjalankan pemeriksaan yang sama setiap kali melakukan deployment. Jika pemeriksaan berubah tergantung siapa yang menjalankannya, Anda kehilangan kemampuan untuk membandingkan hasil antar deployment. Smoke test yang lulus hari ini tetapi gagal minggu lalu memberi tahu Anda sesuatu yang berguna. Smoke test yang berubah setiap saat tidak memberi tahu apa pun.

Smoke test harus selesai dalam waktu kurang dari satu menit. Jika lebih lama, itu bukan lagi smoke test. Itu adalah sesuatu yang lain. Jaga agar tetap cepat dan dangkal.

Lebih Dalam dengan Synthetic Transaction

Setelah smoke test lulus, Anda bisa beralih ke pemeriksaan yang lebih menyeluruh: synthetic transaction. Ini adalah simulasi otomatis tentang apa yang dilakukan pengguna nyata di dalam aplikasi Anda.

Synthetic transaction tidak hanya memeriksa apakah halaman dimuat. Ia berjalan melalui alur pengguna yang sebenarnya. Contohnya:

1. Buka halaman utama
2. Klik tombol login
3. Masukkan nama pengguna dan kata sandi uji
4. Kirim formulir login
5. Navigasi ke fitur tertentu
6. Isi formulir dengan data uji
7. Kirim formulir
8. Verifikasi bahwa hasil yang diharapkan muncul di halaman berikutnya

Synthetic transaction berbeda dari smoke test dalam dua hal penting.

Pertama, mereka lebih panjang dan lebih realistis. Smoke test memeriksa apakah pintu terbuka. Synthetic transaction memeriksa apakah Anda bisa masuk, duduk, memesan makanan, membayar, dan pergi dengan struk.

Kedua, synthetic transaction memverifikasi kebenaran data, bukan hanya ketersediaan halaman. Smoke test memastikan halaman login dimuat. Synthetic transaction memastikan bahwa setelah login, pengguna melihat dashboard mereka dengan data yang benar. Itu adalah sinyal yang jauh lebih kuat.

Synthetic transaction harus berjalan segera setelah deployment selesai. Mereka tidak dimaksudkan untuk menggantikan pemantauan jangka panjang. Mereka dimaksudkan untuk memberi Anda jawaban cepat: "Apakah versi ini cukup sehat untuk terus melayani pengguna, atau haruskah kita rollback?"

Jalankan Keduanya Segera Setelah Deployment

Smoke test dan synthetic transaction bekerja paling baik sebagai pipeline verifikasi dua langkah.

Langkah satu: jalankan smoke test. Jika gagal, berhenti. Sesuatu secara fundamental rusak. Rollback atau perbaiki segera. Jangan lanjutkan ke pemeriksaan yang lebih dalam sampai dasar-dasarnya berfungsi.

Diagram di bawah menunjukkan alur keputusan otomatis:

Langkah dua: jalankan synthetic transaction. Jika gagal, Anda memiliki masalah yang lebih bernuansa. Aplikasi berjalan, tetapi alur pengguna tertentu rusak. Anda perlu memutuskan apakah akan rollback atau hotfix, tergantung pada tingkat keparahannya.

Kedua pemeriksaan harus selesai dalam beberapa menit setelah deployment. Tujuannya adalah untuk mengetahui apakah versi baru aman sebelum sebagian besar pengguna menemukannya.

Daftar Periksa Verifikasi Praktis

Berikut adalah daftar periksa sederhana yang dapat Anda adaptasi untuk deployment Anda sendiri:

• Smoke test: halaman utama mengembalikan 200
• Smoke test: halaman login dirender tanpa error
• Smoke test: endpoint API kritis merespons dalam waktu kurang dari 2 detik
• Smoke test: aset statis dimuat dengan benar
• Synthetic transaction: pengguna dapat login dengan kredensial uji
• Synthetic transaction: pengguna dapat menyelesaikan alur kerja utama (misalnya, membuat pesanan, mengirim formulir, melihat laporan)
• Synthetic transaction: data yang dibuat selama pengujian terlihat di lokasi yang diharapkan

Daftar periksa ini tidak lengkap. Anda perlu menyesuaikannya berdasarkan alur spesifik aplikasi Anda. Namun strukturnya universal: mulai cepat dan dangkal, lalu lebih dalam.

Seperti Apa Ini dalam Praktik

Bayangkan Anda melakukan deployment versi baru aplikasi e-commerce. Smoke test berjalan dan memastikan halaman utama dimuat, API pencarian merespons, dan gambar produk muncul. Bagus.

Kemudian synthetic transaction berjalan. Ia mensimulasikan pengguna mencari produk, menambahkannya ke keranjang, melanjutkan ke checkout, dan menyelesaikan pembayaran. Transaksi gagal pada langkah pembayaran. Pengujian mengungkapkan bahwa versi baru merusak integrasi pembayaran.

Tanpa synthetic transaction, Anda mungkin tidak akan menemukan ini sampai pengguna mulai mengeluh. Dengan itu, Anda tahu dalam waktu dua menit setelah deployment. Anda bisa rollback sebelum lebih dari segelintir pengguna mengalami alur yang rusak.

Itulah perbedaan antara verifikasi terstruktur dan berharap yang terbaik.

Tidak Semua Hal Dapat Diverifikasi dengan Cara yang Sama

Smoke test dan synthetic transaction bekerja dengan baik untuk aplikasi. Namun mereka tidak bekerja dengan cara yang sama untuk database atau infrastruktur. Migrasi database tidak dapat diverifikasi dengan memuat halaman. Perubahan infrastruktur tidak dapat diverifikasi dengan mensimulasikan login pengguna.

Jenis deployment yang berbeda membutuhkan sinyal verifikasi yang berbeda. Prinsipnya tetap sama: periksa sejak dini, periksa secara konsisten, dan periksa dari perspektif pengguna. Namun pemeriksaan spesifik akan terlihat berbeda tergantung pada apa yang Anda deploy.

Kesimpulan Konkret

Berhenti mengandalkan satu orang yang membuka browser setelah deployment. Bangun pipeline verifikasi dua langkah: smoke test untuk kewarasan dasar, lalu synthetic transaction untuk alur pengguna yang realistis. Jalankan keduanya segera setelah setiap deployment. Jika salah satu langkah gagal, Anda tahu sebelum pengguna Anda tahu.

Pengguna Anda tidak boleh menjadi orang pertama yang menemukan bahwa deployment Anda merusak sesuatu. Verifikasi terstruktur adalah cara Anda menjaga hal itu tetap terjadi.