Mengapa Pemeriksaan Manual Setelah Deployment Akan Gagal (Dan Apa yang Harus Dilakukan)

Anda baru saja melakukan deploy versi baru. Anda membuka browser, mengeklik beberapa halaman, memeriksa apakah database merespons, dan semuanya tampak baik-baik saja. Anda menutup tab dan melanjutkan pekerjaan.

Cara itu berhasil ketika Anda deploy seminggu sekali. Tapi ketika deployment terjadi setiap hari, atau beberapa kali sehari, pemeriksaan manual itu tidak lagi bisa diandalkan. Orang yang sama tidak bisa mengulangi pemeriksaan yang persis sama setiap saat tanpa melewatkan sesuatu. Beberapa pemeriksaan terlewat karena Anda sedang terburu-buru. Beberapa dilakukan terburu-buru karena rapat berikutnya akan segera dimulai. Beberapa dianggap baik-baik saja karena "kemarin berhasil."

Masalahnya bukan karena orangnya ceroboh. Masalahnya adalah pengulangan manual tidak berskala. Dan ketika deployment yang buruk lolos karena seseorang lupa memeriksa satu endpoint, seluruh tim yang menanggung akibatnya.

Biaya Nyata dari Pemeriksaan Manual Pasca-Deploy

Pemeriksaan manual setelah deployment menciptakan risiko tersembunyi yang sering diremehkan oleh tim.

Pertama, mereka bergantung pada ingatan. Orang yang melakukan pemeriksaan harus mengingat setiap langkah: endpoint mana yang harus diakses, respons apa yang diharapkan, query database mana yang harus diverifikasi, job latar mana yang harus dikonfirmasi. Ingatan tidak bisa diandalkan, terutama di bawah tekanan.

Kedua, mereka bervariasi antar individu. Seorang engineer mungkin memeriksa alur login dan fitur pencarian. Engineer lain mungkin memeriksa proses checkout dan panel admin. Tidak ada yang memeriksa semuanya, dan keduanya menganggap orang lain sudah mencakup sisanya.

Ketiga, mereka tidak meninggalkan bukti. Ketika pemeriksaan manual lolos, tidak ada catatan tentang apa yang diperiksa, bagaimana responsnya, atau apakah pemeriksaan itu menyeluruh. Jika sesuatu rusak satu jam kemudian, Anda tidak bisa melihat kembali hasil pemeriksaan untuk memahami apa yang berubah.

Keempat, mereka menciptakan hambatan. Orang yang tahu cara melakukan pemeriksaan menjadi penjaga gerbang. Deployment menunggu mereka. Rilis menjadi tertunda. Dan jika orang itu tidak tersedia, tim akan deploy tanpa pemeriksaan atau tidak deploy sama sekali.

Mengotomatiskan Pemeriksaan Pasca-Deploy: Ide Inti

Solusinya sederhana: setelah pipeline Anda selesai melakukan deploy versi baru, pipeline harus segera menjalankan serangkaian pemeriksaan yang telah ditentukan. Pemeriksaan ini dijalankan dengan cara yang sama setiap saat, tanpa perlu ada yang mengingat apa yang harus diperiksa.

Diagram alir berikut membandingkan pendekatan manual dengan pendekatan otomatis yang dijelaskan di sini:

Ini bukan tentang menguji setiap fitur. Ini tentang memverifikasi bahwa fungsi paling kritis masih berfungsi setelah deployment. Pemeriksaan memastikan bahwa aplikasi hidup, dapat dijangkau, dan berperilaku benar pada level yang paling penting bagi pengguna.

Pipeline menjalankan pemeriksaan ini secara otomatis. Jika semuanya lolos, tim memiliki bukti bahwa versi baru sehat. Jika ada pemeriksaan yang gagal, pipeline segera memberi tahu tim, dan mereka tahu persis bagian mana yang perlu diperhatikan.

Berikut adalah contoh minimal dari skrip pemeriksaan otomatis seperti itu:

#!/bin/bash
# post-deploy-check.sh
# Dijalankan setelah deployment untuk memverifikasi aplikasi sehat.

BASE_URL="https://your-app.example.com"
PASS=0
FAIL=1

# Smoke test: periksa endpoint utama
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$BASE_URL")
if [ "$HTTP_CODE" -ne 200 ]; then
  echo "FAIL: Endpoint utama mengembalikan $HTTP_CODE"
  exit $FAIL
fi
echo "PASS: Endpoint utama dapat dijangkau"

# Transaksi sintetis: simulasikan alur login pengguna
LOGIN_RESPONSE=$(curl -s -X POST "$BASE_URL/api/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"test_user","password":"test_pass"}')

if echo "$LOGIN_RESPONSE" | grep -q '"token"'; then
  echo "PASS: Alur login berfungsi"
else
  echo "FAIL: Alur login gagal"
  exit $FAIL
fi

echo "Semua pemeriksaan lolos. Deployment sehat."
exit $PASS

Dua Jenis Pemeriksaan Otomatis yang Bisa Anda Mulai

Smoke Test

Smoke test adalah bentuk paling sederhana dari pemeriksaan otomatis pasca-deploy. Mereka memverifikasi bahwa aplikasi berjalan dan merespons permintaan dasar.

Smoke test mungkin memeriksa:

• Apakah aplikasi dapat menerima koneksi jaringan?
• Apakah endpoint utama mengembalikan kode status 200?
• Apakah versi baru dapat mencapai database?
• Apakah rute API kritis merespons?

Pemeriksaan ini mudah ditulis. Mereka hanyalah skrip yang dipanggil pipeline Anda setelah langkah deploy. Jika ada pemeriksaan yang gagal, pipeline berhenti dan memberi tahu tim.

Smoke test tidak perlu komprehensif. Mereka hanya perlu menangkap kegagalan yang jelas: layanan yang tidak berjalan, koneksi database yang putus, konfigurasi yang hilang.

Transaksi Sintetis

Transaksi sintetis melangkah lebih jauh. Mereka mensimulasikan apa yang dilakukan pengguna nyata, langkah demi langkah.

Untuk aplikasi e-commerce, transaksi sintetis mungkin:

1. Membuka halaman daftar produk
2. Mengklik produk tertentu
3. Menambahkannya ke keranjang
4. Melanjutkan ke checkout
5. Mengisi detail pengiriman
6. Mengonfirmasi pesanan

Setiap langkah memeriksa bahwa responsnya benar. Jika halaman keranjang mengembalikan error, atau checkout gagal dimuat, transaksi sintetis gagal dan pipeline tahu ada yang salah.

Transaksi sintetis membutuhkan lebih banyak pengaturan daripada smoke test. Anda perlu menulis skrip yang meniru perilaku pengguna. Tapi mereka menangkap masalah yang terlewat oleh smoke test, seperti alur kerja yang rusak atau data yang hilang dalam proses multi-langkah.

Apa yang Harus Diotomatiskan Pertama

Jangan mencoba mengotomatiskan semuanya sekaligus. Mulailah dengan fungsi yang akan menyebabkan paling banyak masalah jika rusak.

Tanyakan pada tim Anda: "Jika kita deploy dan fitur ini berhenti berfungsi, seberapa cepat pengguna akan menyadarinya? Seberapa besar kerusakan yang ditimbulkan?"

Jawabannya memberi tahu Anda apa yang harus diotomatiskan pertama. Untuk sebagian besar aplikasi, itu berarti:

• Autentikasi dan login
• Fungsionalitas pencarian
• Alur transaksi inti (checkout, pembayaran, pemesanan)
• Formulir pengiriman data
• Endpoint API yang digunakan oleh layanan lain

Mulailah dengan satu atau dua skenario. Jalankan secara konsisten setelah setiap deployment. Tambahkan lebih banyak seiring waktu saat Anda melihat apa yang rusak dan apa yang penting.

Serangkaian pemeriksaan kecil yang berjalan setiap saat jauh lebih berharga daripada rangkaian besar yang terus gagal karena tes yang tidak stabil atau skenario yang tidak relevan.

Membuat Hasilnya Terlihat

Pemeriksaan otomatis hanya berguna jika hasilnya terlihat dan dapat ditindaklanjuti.

Pipeline Anda harus mencatat hasil setiap pemeriksaan. Simpan hasilnya bersama log deployment. Tampilkan di dashboard yang bisa dilihat tim.

Ketika semua pemeriksaan lolos, tim memiliki bukti jelas bahwa deployment sehat. Ketika pemeriksaan gagal, tim segera tahu bagian sistem mana yang perlu diselidiki.

Visibilitas ini mengubah cara tim beroperasi. Alih-alih bertanya-tanya apakah deployment berjalan dengan baik, mereka memiliki data. Alih-alih mengandalkan ingatan seseorang, mereka memiliki catatan. Alih-alih menemukan masalah melalui keluhan pengguna, mereka menangkapnya beberapa menit setelah deployment.

Langkah Selanjutnya: Dari Verifikasi ke Keputusan

Setelah pemeriksaan otomatis pasca-deploy menjadi rutin, langkah logis berikutnya adalah menggunakannya sebagai gerbang. Jika pemeriksaan gagal, pipeline dapat secara otomatis menghentikan rilis agar tidak mencapai pengguna. Jika lolos, rilis berlanjut.

Ini bukan tentang menghilangkan penilaian manusia. Ini tentang menghilangkan kebutuhan manusia untuk mengulangi verifikasi manual yang sama setiap saat. Tim memutuskan apa yang akan diperiksa. Pipeline menjalankan pemeriksaan itu secara konsisten. Dan tim fokus pada pengecualian, bukan rutinitas.

Daftar Periksa Praktis untuk Memulai

Sebelum Anda membangun sistem otomatisasi penuh, mulailah dari yang kecil:

• Identifikasi tiga fungsi paling kritis yang berhadapan dengan pengguna di aplikasi Anda
• Tulis skrip smoke test yang memeriksa apakah endpoint utama Anda merespons dengan benar
• Tulis satu skrip transaksi sintetis yang mensimulasikan alur pengguna inti
• Tambahkan pemeriksaan ini ke pipeline deployment Anda, tepat setelah langkah deploy
• Konfigurasikan pipeline untuk memberi tahu tim jika ada pemeriksaan yang gagal
• Jalankan pemeriksaan selama satu minggu dan catat setiap positif palsu atau celah
• Sesuaikan pemeriksaan berdasarkan apa yang Anda pelajari
• Tambahkan satu skenario lagi minggu berikutnya

Intisari Konkret

Pemeriksaan manual pasca-deploy berfungsi sampai tidak berfungsi lagi. Saat tim Anda deploy lebih dari sekali sehari, atau saat deployment buruk lolos karena seseorang lupa memeriksa satu hal, Anda membutuhkan otomatisasi.

Mulailah dengan smoke test untuk ketersediaan dasar. Tambahkan transaksi sintetis untuk alur pengguna kritis. Buat hasilnya terlihat. Dan biarkan pipeline menangani pengulangan sehingga tim Anda dapat fokus pada apa yang benar-benar membutuhkan perhatian manusia.

Tujuannya bukan untuk menghilangkan pengawasan manusia. Tujuannya adalah untuk menghilangkan jenis pengawasan yang terjadi karena seseorang harus ingat untuk memeriksa hal yang sama untuk keseratus kalinya.