Kapan Sebuah Deployment Benar-Benar Selesai?

Anda baru saja menjalankan perintah deployment. Terminal menampilkan output hijau yang bersih. Tidak ada error. Tidak ada peringatan. Container baru sudah berjalan. File-file sudah terpasang. Tim Anda mulai membereskan barang untuk pulang.

Tapi, apakah deployment benar-benar selesai?

Kebanyakan tim menganggap momen ketika perintah deploy selesai sebagai garis akhir. Itu adalah asumsi yang berbahaya. Yang Anda ketahui pada titik itu hanyalah bahwa proses memindahkan file atau me-restart layanan berhasil. Anda belum tahu apakah aplikasi benar-benar berfungsi.

Perbedaan Antara Melakukan Deployment dan Menjadi Sehat

Sebuah deployment memiliki dua fase yang berbeda. Fase pertama adalah tindakan teknis menempatkan versi baru. Fase kedua adalah memverifikasi bahwa versi baru tersebut berperilaku dengan benar. Banyak tim berhenti setelah fase pertama dan menganggap selesai.

Diagram alir berikut mengilustrasikan proses dua fase yang dijelaskan di atas:

flowchart TD A[Fase Deploy] --> B[Memindahkan file / me-restart service] B --> C[Deploy Berhasil] C --> D[Fase Verifikasi] D --> E[Smoke Tests] E --> F[Transaksi Sintetis] F --> G[Pantau Sinyal] G --> H[Tingkat error, latensi, resource] H --> I[Bukti Terkumpul] I --> J[Deployment Selesai] C -.->|Belum selesai| K[Deployment BELUM Selesai] style J fill:#a3d9a5 style K fill:#f4a3a3

Pikirkan tentang apa yang bisa salah setelah deploy berhasil:

  • Kode baru memiliki kesalahan konfigurasi yang hanya muncul di bawah lalu lintas nyata
  • Migrasi database berhasil tetapi kode aplikasi mengharapkan nama kolom yang berbeda
  • Sebuah dependensi diperbarui dan merusak integrasi yang tidak tertangkap oleh unit test
  • Versi baru menggunakan lebih banyak memori dan memicu OOM killer setelah beberapa menit

Tidak satu pun dari ini akan muncul di log deployment Anda. Terminal akan tetap mengatakan "deploy berhasil." Tapi aplikasi akan rusak.

Apa yang Dianggap Sebagai Bukti

Sebuah deployment hanya selesai ketika Anda memiliki bukti bahwa versi baru sehat dan siap melayani pengguna. Bukti itu harus terukur dan dapat diverifikasi. Firasat dan "kelihatannya baik-baik saja" tidak dihitung.

Bukti datang dari berbagai sumber. Smoke test adalah lapisan paling dasar. Mereka memeriksa apakah aplikasi menyala, halaman utama dimuat, dan fitur inti merespons. Smoke test yang gagal berarti ada sesuatu yang fundamental yang salah.

Berikut adalah skrip minimal yang mengotomatiskan lapisan pertama pengumpulan bukti setelah deployment:

#!/bin/bash
# post-deploy-verify.sh - Dijalankan setelah perintah deploy

set -euo pipefail

URL="https://your-app.example.com"
DB_CONN_STRING="postgresql://user:pass@db-host:5432/app"

# 1. Health check
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$URL/health")
if [ "$HTTP_CODE" -ne 200 ]; then
  echo "FAIL: Health check mengembalikan $HTTP_CODE"
  exit 1
fi
echo "PASS: Health check mengembalikan 200"

# 2. Smoke test - halaman utama dimuat
if ! curl -s "$URL" | grep -q "<title>App</title>"; then
  echo "FAIL: Halaman utama tidak memiliki judul yang diharapkan"
  exit 1
fi
echo "PASS: Halaman utama dimuat dengan benar"

# 3. Tes konektivitas database
if ! psql "$DB_CONN_STRING" -c "SELECT 1" > /dev/null 2>&1; then
  echo "FAIL: Koneksi database gagal"
  exit 1
fi
echo "PASS: Koneksi database berhasil"

echo "Semua pemeriksaan lulus - bukti deployment terkumpul"

Transaksi sintetis melangkah lebih dalam. Mereka mensimulasikan alur pengguna nyata: login, mencari data, mengirimkan formulir, melakukan checkout pesanan. Jika transaksi sintetis berhasil, Anda tahu bahwa perjalanan pengguna yang lengkap berfungsi dari ujung ke ujung.

Kemudian ada sinyal sistem yang telah kita bahas sebelumnya di seri ini. Setelah deployment, Anda perlu memeriksa apakah ketersediaan tetap stabil, tingkat error tidak melonjak, dan latensi tidak menurun. Jika semua sinyal ini terlihat normal, Anda memiliki bukti kuat bahwa versi baru tidak menyebabkan masalah.

Jebakan Verifikasi Kasual

Bahaya sebenarnya bukanlah bahwa tim melewatkan verifikasi sama sekali. Bahayanya adalah mereka melakukannya secara kasual. Seorang pengembang melirik dashboard, melihat bar hijau, dan berasumsi semuanya baik-baik saja. Tapi lirikan itu mungkin melewatkan peningkatan halus dalam error 500. Mungkin melewatkan bahwa alur checkout mengalami timeout untuk sebagian pengguna.

Verifikasi kasual gagal karena bergantung pada perhatian dan ingatan manusia. Pengembang yang melakukan deploy mungkin lelah setelah seharian bekerja. Mereka mungkin terburu-buru untuk bergabung dengan rapat lain. Mereka mungkin tidak tahu persis sinyal mana yang harus diperiksa untuk perubahan khusus ini.

Solusinya adalah menentukan kriteria bukti Anda sebelum Anda melakukan deploy. Putuskan terlebih dahulu sinyal apa yang akan membuktikan bahwa deployment selesai. Tuliskan. Buatlah eksplisit.

Serangkaian kriteria yang masuk akal mungkin terlihat seperti ini:

  • Smoke test untuk halaman utama dan alur login berhasil
  • Transaksi sintetis untuk tiga perjalanan pengguna paling kritis berhasil
  • Tingkat error tetap di bawah 0,1 persen
  • Latensi P95 tidak meningkat lebih dari 5 persen dari baseline sebelum deployment
  • Utilisasi kumpulan koneksi database tetap di bawah 70 persen

Ketika semua kondisi ini terpenuhi, deployment selesai. Jika ada kondisi yang gagal, deployment belum selesai, meskipun perintah deploy berhasil.

Siapa yang Memutuskan Deployment Selesai

Di tim kecil, pengembang yang melakukan deploy sering kali yang memutuskan. Mereka memeriksa kriteria, memverifikasi sinyal, dan memutuskan apakah akan menyebutnya selesai. Ini berfungsi ketika tim kecil dan semua orang mengenal sistem dengan baik.

Seiring pertumbuhan tim, keputusan harus beralih ke otomatisasi. Pipeline itu sendiri tidak boleh menandai deployment sebagai selesai sampai semua pemeriksaan otomatis lulus. Ini menghilangkan penilaian manusia dari loop dan memastikan konsistensi. Setiap deployment mendapatkan verifikasi yang sama, setiap saat.

Untuk perubahan berisiko tinggi, Anda mungkin masih menginginkan manusia dalam loop. Seorang engineer senior atau orang yang on-call dapat meninjau bukti dan membuat keputusan akhir. Tapi meskipun begitu, kriterianya harus jelas. Manusia tidak menebak-nebak apakah semuanya terlihat baik. Mereka memeriksa daftar kondisi yang telah ditentukan sebelumnya.

Tidak ada aturan universal tentang berapa banyak bukti yang cukup. Perbaikan bug kecil pada alat internal membutuhkan lebih sedikit verifikasi daripada perubahan fitur besar pada sistem pembayaran yang berhadapan dengan pelanggan. Yang penting adalah tim Anda menyetujui kriteria untuk setiap jenis perubahan.

Daftar Periksa Praktis untuk Penyelesaian Deployment

Berikut adalah daftar periksa sederhana yang dapat Anda adaptasi untuk tim Anda:

  • Perintah deployment selesai tanpa error
  • Smoke test berhasil (halaman utama, login, fitur inti)
  • Transaksi sintetis berhasil (perjalanan pengguna kritis)
  • Tingkat error dalam rentang yang dapat diterima
  • Latensi dalam rentang yang dapat diterima
  • Penggunaan resource (CPU, memori, koneksi) stabil
  • Tidak ada alert yang terpicu dari sistem monitoring
  • Migrasi database telah diterapkan dan diverifikasi

Jika ada item yang gagal, deployment belum selesai. Selidiki sebelum menyatakan sukses.

Apa yang Berubah Ketika Anda Melakukan Ini dengan Benar

Ketika tim Anda setuju bahwa deployment belum selesai sampai ada bukti kesehatan, seluruh proses deployment berubah. Deployment berhenti menjadi tugas teknis yang berakhir di terminal. Ia menjadi transisi yang berakhir ketika pengguna dapat menggunakan versi baru dengan aman.

Pergeseran ini mengubah perilaku. Tim mulai menulis smoke test yang lebih baik karena mereka tahu tes itu menentukan apakah mereka bisa pulang. Mereka mulai menentukan kriteria yang jelas sebelum melakukan deploy, bukan setelahnya. Mereka berhenti terburu-buru menutup deployment dan mulai memperhatikan apa yang terjadi setelah versi baru live.

Lain kali tim Anda melakukan deployment, perhatikan apa yang terjadi setelah perintah selesai. Apakah semua orang santai dan melanjutkan aktivitas? Atau apakah mereka memeriksa bukti terlebih dahulu? Momen itu memberi tahu Anda apakah tim Anda benar-benar memahami kapan sebuah deployment selesai.