Apa yang Dimaksud dengan Deployment yang Sehat untuk Aplikasi, Database, dan Infrastruktur

Ketika sebuah deployment selesai, bagaimana Anda tahu bahwa itu benar-benar berhasil? Bukan status pipeline. Bukan centang hijau. Bukan pesan "deploy successful" di Slack. Pertanyaan sebenarnya adalah: apakah yang Anda deploy benar-benar melakukan apa yang seharusnya dilakukan?

Jawabannya tergantung pada apa yang Anda deploy. Aplikasi, perubahan database, dan pembaruan infrastruktur masing-masing memerlukan jenis verifikasi yang berbeda. Menggunakan health check yang sama untuk ketiganya sama seperti menggunakan tes yang sama untuk memeriksa apakah mesin mobil menyala, apakah oli bersih, dan apakah ban memiliki cukup udara. Semuanya penting, tetapi cara memeriksanya berbeda.

Memverifikasi Deployment Aplikasi

Mulailah dengan pertanyaan paling dasar: apakah proses aplikasi berjalan dan menerima koneksi? Ini setara dengan memeriksa apakah server menyala. Anda bisa mengakses endpoint health sederhana dan mencari respons 200. Jika Anda mendapatkannya, aplikasi hidup.

Diagram alur berikut menunjukkan jalur verifikasi yang berbeda untuk setiap jenis deployment, yang berakhir dengan keputusan sehat atau rollback.

flowchart TD subgraph App[Aplikasi] A1[Health check] --> A2[Smoke tests] A2 --> A3[Transaksi sintetis] A3 --> A4{Semua lolos?} A4 -->|Ya| A5[Sehat] A4 -->|Tidak| A6[Rollback] end subgraph DB[Database] D1[Pemeriksaan migrasi] --> D2[Pemeriksaan integritas data] D2 --> D3[Pemeriksaan performa query] D3 --> D4{Semua lolos?} D4 -->|Ya| D5[Sehat] D4 -->|Tidak| D6[Rollback] end subgraph Infra[Infrastruktur] I1[Validasi konfigurasi] --> I2[Tes konektivitas] I2 --> I3[Pemeriksaan batas resource] I3 --> I4{Semua lolos?} I4 -->|Ya| I5[Sehat] I4 -->|Tidak| I6[Rollback] end

Tetapi hidup tidak berarti bekerja. Aplikasi yang menerima koneksi mungkin gagal begitu mencoba memproses permintaan. Mungkin tidak bisa membaca file konfigurasinya. Mungkin gagal terhubung ke database. Mungkin memiliki koneksi cache yang rusak. Masalah-masalah ini tidak akan muncul dalam health check sederhana.

Itulah mengapa verifikasi aplikasi perlu lebih dalam. Jalankan smoke test yang memanggil beberapa endpoint secara berurutan. Simulasikan transaksi sintetis yang mencerminkan apa yang akan dilakukan pengguna nyata: login, mencari sesuatu, mengirimkan formulir, logout. Jika alur sintetis itu berhasil, Anda memiliki bukti yang lebih kuat bahwa aplikasi benar-benar fungsional, bukan sekadar berjalan.

Kuncinya di sini adalah menguji bagian yang paling penting bagi pengguna Anda. Jika fitur inti aplikasi Anda adalah pencarian berdasarkan tanggal, verifikasi Anda harus menyertakan query pencarian yang menggunakan rentang tanggal. Jika pengguna mengunggah file, verifikasi Anda harus menyertakan alur unggahan. Jangan menguji semuanya pada setiap deployment, tetapi uji jalur kritisnya.

Berikut adalah contoh praktis dari health check dan skrip transaksi sintetis yang bisa Anda jalankan setelah deployment:

# Health check: verifikasi aplikasi hidup
if curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/health | grep -q "200"; then
  echo "Health check passed"
else
  echo "Health check failed"
  exit 1
fi

# Smoke test: simulasikan alur pengguna inti (login, cari, kirim)
#!/bin/bash
set -euo pipefail

BASE_URL="http://localhost:8080"

# Langkah 1: Login
LOGIN_RESPONSE=$(curl -s -X POST "$BASE_URL/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"testuser","password":"testpass"}')
TOKEN=$(echo "$LOGIN_RESPONSE" | jq -r '.token')

# Langkah 2: Cari
SEARCH_RESPONSE=$(curl -s "$BASE_URL/search?q=test&date_from=2024-01-01" \
  -H "Authorization: Bearer $TOKEN")
if ! echo "$SEARCH_RESPONSE" | jq -e '.results | length > 0' > /dev/null; then
  echo "Search returned no results"
  exit 1
fi

# Langkah 3: Kirim formulir
SUBMIT_RESPONSE=$(curl -s -X POST "$BASE_URL/submit" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"test","content":"test content"}')
if ! echo "$SUBMIT_RESPONSE" | jq -e '.id' > /dev/null; then
  echo "Form submission failed"
  exit 1
fi

echo "Smoke test passed"

Memverifikasi Perubahan Database

Database tidak berbicara HTTP. Anda tidak bisa melakukan ping ke endpoint database dan mendapatkan respons 200. Verifikasi database berkaitan dengan perubahan skema, modifikasi indeks, stored procedure, dan pembaruan data referensi. Pertanyaannya adalah: apakah migrasi berjalan tanpa error, dan apakah itu merusak sesuatu yang sebelumnya berfungsi?

Mulailah dengan menjalankan skrip migrasi di lingkungan staging terlebih dahulu. Periksa output untuk error. Jika migrasi berhasil, jalankan query uji yang mewakili pola akses normal aplikasi. Jika Anda mengubah indeks, periksa apakah query yang bergantung pada indeks tersebut masih berjalan dengan kecepatan yang dapat diterima. Jika Anda memodifikasi stored procedure, eksekusi dengan data uji dan verifikasi hasilnya.

Verifikasi database juga perlu memastikan bahwa rollback dimungkinkan. Skrip migrasi yang tidak bisa dibalikkan adalah sebuah kewajiban. Uji rollback di lingkungan staging Anda. Pastikan itu mengembalikan keadaan sebelumnya dengan bersih, tanpa kehilangan data atau korupsi. Jika Anda tidak bisa melakukan rollback dengan percaya diri, Anda belum sepenuhnya memverifikasi perubahan.

Satu kesalahan umum adalah memperlakukan verifikasi database sebagai pemeriksaan satu kali. Perubahan database dapat memiliki efek halus yang hanya muncul di bawah beban produksi. Indeks baru mungkin mempercepat satu query tetapi memperlambat query lain. Perubahan skema mungkin berfungsi baik dengan data uji tetapi menyebabkan masalah penguncian dengan volume data nyata. Itulah mengapa verifikasi database harus mencakup pemeriksaan fungsional dan pemeriksaan performa, meskipun pemeriksaan performa hanya perbandingan baseline sederhana.

Memverifikasi Perubahan Infrastruktur

Infrastruktur mencakup server, load balancer, firewall, catatan DNS, sertifikat TLS, dan routing jaringan. Ketika Anda mengubah infrastruktur, Anda mengubah lingkungan yang menjadi sandaran segala sesuatu lainnya. Firewall yang salah konfigurasi dapat secara diam-diam memutus koneksi database. Aturan load balancer yang salah dapat mengirim lalu lintas ke server yang salah. Sertifikat TLS yang kedaluwarsa dapat membuat aplikasi Anda tidak dapat dijangkau melalui HTTPS.

Verifikasi infrastruktur berkaitan dengan konektivitas dan konfigurasi. Setelah mengubah aturan firewall, verifikasi bahwa aplikasi masih dapat mencapai database. Setelah memperbarui load balancer, verifikasi bahwa lalu lintas mencapai server backend yang benar. Setelah memperbarui sertifikat TLS, verifikasi bahwa koneksi HTTPS berfungsi tanpa peringatan keamanan.

Pemeriksaan ini sering kali perlu dijalankan dari luar infrastruktur itu sendiri. Anda tidak bisa menguji konektivitas eksternal dari dalam jaringan. Gunakan skrip atau alat yang mensimulasikan koneksi dari luar. Ping endpoint. Periksa tanggal kedaluwarsa sertifikat. Verifikasi bahwa resolusi DNS mengembalikan alamat IP yang benar.

Perubahan infrastruktur juga cenderung memiliki efek berantai. Mengubah satu catatan DNS dapat mempengaruhi beberapa layanan. Memperbarui satu aturan firewall dapat memblokir lalu lintas yang sebelumnya diizinkan. Itulah mengapa verifikasi infrastruktur harus mencakup peta konektivitas: daftar semua koneksi yang perlu berfungsi, dan tes untuk masing-masing.

Prinsip Umum

Meskipun metode verifikasi berbeda, prinsipnya sama: setiap deployment harus meninggalkan bukti bahwa objek yang di-deploy berfungsi dengan benar. Bukti bisa berupa entri log yang menunjukkan migrasi berhasil, respons HTTP yang menunjukkan aplikasi dapat melayani permintaan, atau hasil ping yang menunjukkan server dapat dijangkau. Tanpa bukti, Anda tidak tahu apakah deployment berhasil. Anda hanya tahu bahwa pipeline selesai.

Daftar Periksa Verifikasi Praktis

Gunakan ini sebagai titik awal, bukan daftar akhir. Sesuaikan dengan sistem spesifik Anda.

  • Aplikasi: endpoint health mengembalikan 200, transaksi sintetis untuk alur pengguna inti berhasil, dependensi eksternal kritis (database, cache, API) dapat dijangkau.
  • Database: skrip migrasi berjalan tanpa error, query uji mengembalikan hasil yang benar, performa query dalam rentang yang dapat diterima, skrip rollback berfungsi di staging.
  • Infrastruktur: konektivitas antara semua komponen yang bergantung diverifikasi, sertifikat TLS valid dan tidak akan kedaluwarsa dalam waktu dekat, resolusi DNS mengembalikan catatan yang benar, aturan firewall mengizinkan lalu lintas yang diperlukan.

Kapan Sebuah Deployment Benar-Benar Selesai?

Sebuah deployment selesai ketika Anda telah memverifikasi bahwa perubahan berfungsi dengan benar di lingkungannya. Bukan ketika pipeline berubah hijau. Bukan ketika tiket ditutup. Bukan ketika pimpinan tim mengatakan "tampaknya bagus." Deployment selesai ketika Anda memiliki bukti bahwa aplikasi, database, atau infrastruktur melakukan apa yang seharusnya dilakukan.

Bukti itulah yang membedakan antara deployment yang terjadi dan deployment yang berhasil.