Apa yang Terjadi Setelah Deploy? Mengapa Pipeline Anda Belum Selesai

Anda baru saja melihat pipeline berubah menjadi hijau. Artifact berhasil di-deploy ke production tanpa satu pun pesan error. Tim Anda bernapas lega dan beralih ke tugas berikutnya. Tapi inilah pertanyaan yang tidak nyaman: apakah aplikasi benar-benar berfungsi untuk pengguna?

Saya pernah melihat tim merayakan keberhasilan deployment, hanya untuk menemukan satu jam kemudian bahwa fitur baru secara diam-diam merusak login pengguna. Log deployment tidak menunjukkan error apa pun. Server berjalan normal. Tapi tidak ada yang bisa masuk. Pipeline menganggap pekerjaan selesai, sementara masalah sebenarnya tidak terdeteksi sampai pengguna mulai mengeluh.

Kesenjangan antara "deployment berhasil" dan "deployment berfungsi" inilah alasan mengapa verifikasi pasca-deploy ada. Ini adalah langkah yang memisahkan deployment yang sukses secara teknis dari deployment yang benar-benar memberikan nilai.

Tiga Lapisan Verifikasi Pasca-Deploy

Verifikasi pasca-deploy adalah tahap di mana pipeline Anda memeriksa versi yang baru di-deploy secara langsung di lingkungan target. Pemeriksaan ini harus otomatis dan terprogram, bukan sesuatu yang dijalankan secara manual dari laptop seseorang. Ada tiga jenis umum, masing-masing dengan tujuan berbeda.

Diagram alir berikut menunjukkan bagaimana ketiga lapisan ini bekerja bersama secara berurutan, dengan rollback otomatis atau alert ketika pemeriksaan gagal.

flowchart TD A[Deploy ke Production] --> B[Health Check] B -->|Lolos| C[Smoke Test] B -->|Gagal| D[Rollback / Alert] C -->|Lolos| E[Synthetic Monitoring] C -->|Gagal| D E -->|Lolos| F[Tandai Deployment Berhasil] E -->|Gagal| G[Alert / Investigasi]

Health Check: Apakah Aplikasi Hidup?

Health check adalah verifikasi paling dasar. Ia menjawab satu pertanyaan: apakah service berjalan dan merespons permintaan? Biasanya ini adalah endpoint khusus seperti /health atau /status yang mengembalikan kode HTTP 200 ketika aplikasi hidup.

Tapi inilah jebakannya: health check hanya memberi tahu Anda bahwa aplikasi tidak mati total. Ia tidak memberi tahu apakah aplikasi berfungsi dengan benar. Sebuah service bisa mengembalikan 200 sambil menyajikan data yang rusak, merespons lambat, atau secara diam-diam gagal pada operasi kritis. Health check itu perlu, tapi ini adalah batas minimum, bukan garis akhir.

Smoke Test: Apakah Fungsionalitas Inti Berfungsi?

Smoke test melangkah lebih dalam. Mereka menjalankan skenario sederhana yang mencakup fungsi paling kritis dari aplikasi Anda. Untuk situs e-commerce, smoke test mungkin membuka halaman utama, mencari produk, dan menambahkan item ke keranjang. Untuk database, ia memeriksa bahwa tabel utama dapat diakses dan query dasar berjalan. Untuk infrastruktur, ia memverifikasi bahwa load balancer merespons dan sertifikat SSL masih valid.

Kata kuncinya di sini adalah "sederhana." Smoke test bukanlah rangkaian regresi lengkap. Mereka menguji jalur bahagia (happy path) dari fitur inti Anda. Jika smoke test lolos, Anda memiliki keyakinan yang wajar bahwa aplikasi tidak rusak secara fundamental. Jika gagal, Anda tahu ada yang salah sebelum pengguna mengetahuinya.

Berikut adalah contoh smoke test bash minimal yang memeriksa endpoint API kritis dan keluar dengan kode non-zero jika respons bukan 200:

#!/bin/bash
set -euo pipefail

# Smoke test: verifikasi endpoint login mengembalikan 200
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" https://myapp.com/api/login)

if [ "$RESPONSE" -ne 200 ]; then
  echo "Smoke test gagal: endpoint login mengembalikan $RESPONSE"
  exit 1
fi

echo "Smoke test berhasil: endpoint login mengembalikan 200"

Synthetic Monitoring: Apakah Memenuhi Standar Performa?

Synthetic monitoring mensimulasikan perilaku pengguna nyata secara terjadwal. Tidak seperti health check dan smoke test yang berjalan sekali setelah deployment, synthetic monitoring berjalan terus-menerus. Tapi setelah deployment, pipeline Anda dapat memicu pemeriksaan sintetis untuk memverifikasi bahwa versi baru masih memenuhi standar performa Anda.

Misalnya, Anda mungkin memiliki pemeriksaan sintetis yang mengukur waktu respons untuk endpoint API kritis. Jika waktu respons melonjak di atas 500ms setelah deployment, pipeline harus menandainya meskipun endpoint mengembalikan data yang benar. Synthetic monitoring menangkap jenis degradasi yang luput dari health check dan smoke test.

Apa yang Terjadi Ketika Verifikasi Gagal

Ketika verifikasi pasca-deploy gagal, pipeline Anda perlu bertindak segera. Respons yang paling umum adalah rollback: mengembalikan lingkungan ke versi baik yang diketahui sebelumnya. Tapi rollback bukan satu-satunya opsi, dan tidak selalu yang terbaik.

Jika Anda menggunakan canary deployment, pipeline dapat menghentikan pengalihan traffic ke versi baru dan mengarahkan semua pengguna kembali ke versi lama. Jika Anda menggunakan blue-green deployment, pipeline dapat mengalihkan traffic kembali ke lingkungan yang masih menjalankan versi lama. Tindakan spesifik tergantung pada strategi deployment Anda, tapi prinsipnya sama: hentikan kerusakan dan pulihkan layanan.

Apa pun tindakan yang Anda ambil, kegagalan harus dicatat sebagai bukti. Pipeline Anda harus menyimpan log dari health check, smoke test, dan synthetic monitoring, lengkap dengan timestamp dan versi artifact yang diuji. Bukti ini menjadi kritis ketika Anda menyelidiki apa yang salah di kemudian hari. Tanpanya, Anda hanya menebak-nebak.

Mengapa Tim Melewatkan Langkah Ini

Verifikasi pasca-deploy sering dianggap opsional atau dilewati sama sekali. Alasannya beragam. Beberapa tim terlalu percaya pada pengujian pra-deploy mereka. Yang lain menganggap health check sudah cukup. Banyak yang merasa tertekan untuk bergerak cepat dan menganggap verifikasi sebagai penghambat.

Tapi melewatkan verifikasi menciptakan titik buta. Pengujian pra-deploy Anda berjalan di lingkungan staging yang tidak pernah sempurna meniru production. Perbedaan konfigurasi, perbedaan volume data, dan perbedaan infrastruktur berarti bahwa pengujian yang lolos di staging tidak menjamin pengujian lolos di production. Verifikasi pasca-deploy adalah jaring pengaman Anda untuk celah-celah itu.

Daftar Periksa Praktis untuk Verifikasi Pasca-Deploy

Jika Anda baru pertama kali menyiapkan verifikasi pasca-deploy, berikut adalah titik awal minimal:

  • Tambahkan endpoint /health yang memeriksa konektivitas database, konektivitas cache, dan dependensi eksternal kritis
  • Tulis tiga hingga lima smoke test yang mencakup perjalanan pengguna paling kritis Anda
  • Siapkan setidaknya satu pemeriksaan sintetis yang mengukur waktu respons untuk API atau halaman kunci
  • Konfigurasikan pipeline Anda untuk memicu rollback secara otomatis jika ada langkah verifikasi yang gagal
  • Simpan semua hasil verifikasi dengan timestamp dan nomor versi

Mulailah dengan set minimal ini dan perluas seiring Anda belajar apa yang rusak dalam konteks spesifik Anda.

Ukuran Sebenarnya dari Deployment yang Sukses

Sebuah deployment tidak selesai ketika artifact sudah berada di server. Ia selesai ketika Anda memiliki bukti bahwa versi baru berjalan dengan benar dan memenuhi standar Anda. Verifikasi pasca-deploy adalah yang memberi Anda bukti itu.

Tanpanya, Anda melakukan deployment secara buta. Dengannya, Anda tahu persis kapan deployment Anda benar-benar berhasil dan kapan ia gagal secara diam-diam. Pengetahuan itu adalah perbedaan antara bereaksi terhadap keluhan pengguna dan menangkap masalah sebelum ada yang menyadarinya.