Setelah Deployment: Hal yang Harus Dicek Sebelum Menyatakan Selesai

Pipeline berubah hijau. Artifact build berhasil diunggah. Skrip deployment selesai tanpa error. Banyak tim berhenti di sini, menganggap versi baru sudah live dan berfungsi. Asumsi itu berbahaya.

Pipeline hijau hanya berarti proses pengiriman berjalan tanpa kesalahan teknis. Itu tidak berarti versi baru benar-benar bekerja di produksi. Di antara pipeline yang sukses dan deployment yang berfungsi, ada celah yang perlu diperiksa secara aktif.

Mengapa Keberhasilan Pipeline Tidak Cukup

Lingkungan produksi berbeda dari staging atau test. Di produksi, versi baru Anda menghadapi data nyata, pola lalu lintas nyata, dan kondisi jaringan nyata. Banyak hal terjadi yang tidak bisa dideteksi pipeline:

  • Koneksi database yang melambat karena dataset produksi sepuluh kali lebih besar dari staging
  • Konfigurasi cache yang berfungsi baik dengan kueri uji tetapi meleset pada pola akses pengguna sebenarnya
  • Server yang salah konfigurasi yang tidak terdeteksi skrip deployment
  • API pihak ketiga yang merespons berbeda di bawah beban nyata

Pipeline menjalankan skrip dan memeriksa kode. Pipeline tidak tahu bagaimana sistem berperilaku saat bertemu kenyataan. Itulah mengapa Anda memerlukan langkah terpisah setelah deployment: verifikasi.

Perbedaan Antara Deployment dan Verifikasi

Deployment adalah tindakan menempatkan versi baru ke dalam suatu lingkungan. Verifikasi adalah tindakan memastikan bahwa versi baru bekerja seperti yang diharapkan di lingkungan tersebut.

Keduanya adalah aktivitas yang berbeda. Deployment berkaitan dengan mesin dan skrip. Verifikasi berkaitan dengan perilaku dan sinyal. Banyak tim memperlakukan keduanya sebagai satu hal, atau bahkan melewatkan verifikasi sama sekali karena pipeline mengatakan semuanya baik-baik saja.

Diagram alir berikut mengilustrasikan bagaimana deployment dan verifikasi adalah jalur terpisah yang keduanya harus berhasil sebelum suatu deployment dianggap selesai:

flowchart TD A[Pipeline Hijau] --> B[Skrip Deployment Berjalan] B --> C[Artifact Diunggah] C --> D[Jalur Deployment Selesai] D --> E{Jalur Verifikasi} E --> F[Smoke Test] F --> G{Berhasil?} G -- Tidak --> H[Rollback] G -- Ya --> I[Periksa Error Rate] I --> J{Dalam Ambang?} J -- Tidak --> H J -- Ya --> K[Periksa Latensi] K --> L{Dalam Batas?} L -- Tidak --> H L -- Ya --> M[Periksa Throughput] M --> N{Volume Sesuai?} N -- Tidak --> H N -- Ya --> O[Deployment Selesai]

Saat Anda menganggap deployment selesai begitu skrip selesai, Anda berjudi bahwa tidak ada hal tak terduga yang terjadi di produksi. Taruhan itu mungkin berhasil untuk perubahan sederhana. Untuk hal-hal yang melibatkan migrasi database, perubahan konfigurasi, atau pembaruan infrastruktur, kemungkinannya tidak menguntungkan Anda.

Mulai dengan Smoke Test

Langkah verifikasi paling dasar adalah smoke test. Istilah ini berasal dari teknik perangkat keras: saat Anda menyalakan perangkat baru untuk pertama kali, Anda memeriksa apakah ada asap yang keluar. Tidak ada asap berarti perangkat setidaknya tidak terbakar.

Dalam deployment perangkat lunak, smoke test adalah pemeriksaan cepat untuk melihat apakah versi baru hidup dan merespons. Ini menjawab satu pertanyaan: dapatkah versi ini menerima permintaan dan mengembalikan respons yang wajar?

Smoke test praktis dapat mencakup:

Berikut adalah skrip bash minimal yang menjalankan smoke test terhadap endpoint yang di-deploy dan keluar dengan kode non-nol jika gagal:

#!/bin/bash
# smoke-test.sh - Pemeriksaan cepat apakah versi yang di-deploy masih hidup

URL="https://your-app.example.com/health"
EXPECTED_STATUS=200

HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$URL")

if [ "$HTTP_STATUS" -ne "$EXPECTED_STATUS" ]; then
    echo "Smoke test gagal: status yang diharapkan $EXPECTED_STATUS, tetapi mendapat $HTTP_STATUS"
    exit 1
fi

echo "Smoke test berhasil: $URL mengembalikan $HTTP_STATUS"
exit 0
  • Mengakses halaman utama dan memeriksa respons 200
  • Memanggil endpoint API sederhana dan memverifikasi struktur respons
  • Memastikan koneksi database masih hidup
  • Memeriksa bahwa aset statis dimuat dengan benar

Smoke test tidak perlu mendalam. Ini adalah pemeriksaan cepat dan dangkal yang menangkap kegagalan yang jelas. Jika smoke test gagal, Anda tahu ada sesuatu yang serius salah dan perlu menghentikan lalu lintas lebih lanjut atau melakukan rollback. Jika berhasil, Anda dapat beralih ke pemeriksaan yang lebih detail.

Periksa Sinyal Dasar

Setelah smoke test berhasil, lihat sinyal operasional sistem. Ini adalah metrik yang memberi tahu Anda apakah versi baru berjalan normal atau menyebabkan masalah.

Sinyal yang Anda perlukan tergantung pada apa yang Anda deploy, tetapi beberapa bersifat universal:

  • Error rate: Apakah persentase permintaan yang gagal lebih tinggi dari sebelum deployment?
  • Latensi: Apakah waktu respons dalam batas yang dapat diterima? Lonjakan mendadak sering kali menandakan masalah.
  • Penggunaan sumber daya: Apakah penggunaan CPU, memori, atau disk berubah secara signifikan setelah deployment?
  • Volume lalu lintas: Apakah sistem menerima jumlah permintaan yang diharapkan? Penurunan mendadak mungkin berarti pengguna tidak dapat menjangkau versi baru.

Anda tidak perlu analisis rumit untuk ini. Bandingkan nilai saat ini dengan jendela waktu yang sama sebelum deployment. Jika Anda memiliki dasbor pemantauan, perbandingan ini hanya memakan waktu beberapa menit.

Kuncinya adalah menjadikan pemeriksaan ini sebagai bagian standar dari proses deployment Anda, bukan sesuatu yang Anda lakukan saat ingat atau saat seseorang melaporkan masalah.

Verifikasi Adalah Bagian dari Deployment

Inilah perubahan pola pikirnya: verifikasi bukanlah aktivitas terpisah yang terjadi setelah deployment. Verifikasi adalah bagian dari deployment itu sendiri. Deployment belum selesai sampai Anda memiliki cukup keyakinan bahwa versi baru berjalan normal.

Ini memiliki konsekuensi praktis untuk pipeline Anda. Pipeline tidak boleh menandai deployment sebagai berhasil saat skrip selesai. Pipeline harus menunggu hingga verifikasi berhasil. Jika verifikasi gagal, pipeline harus melaporkan deployment sebagai gagal, meskipun skrip berjalan tanpa error.

Beberapa tim menerapkan ini dengan membuat pipeline berhenti sejenak setelah deployment dan menunggu konfirmasi manual. Yang lain mengotomatiskan smoke test dan pemeriksaan sinyal dasar, dan hanya menandai keberhasilan saat pemeriksaan tersebut lulus. Either approach is better than assuming everything is fine.

Jenis Perubahan yang Berbeda Membutuhkan Pemeriksaan yang Berbeda

Tidak semua deployment sama. Pembaruan aplikasi, migrasi database, dan perubahan infrastruktur masing-masing memiliki risiko berbeda dan sinyal berbeda yang perlu diperiksa.

Untuk pembaruan aplikasi, risiko utamanya adalah seputar penanganan permintaan, kebenaran respons, dan integrasi dengan layanan yang ada. Smoke test dan pemeriksaan error rate biasanya sudah cukup.

Untuk migrasi database, risikonya berbeda. Anda perlu memeriksa bahwa migrasi berjalan dengan benar, integritas data terjaga, dan performa kueri tidak menurun. Pemeriksaan sinyal harus mencakup penggunaan connection pool database, latensi kueri, dan replication lag jika berlaku.

Untuk perubahan infrastruktur, risikonya adalah seputar konektivitas, ketersediaan sumber daya, dan kebenaran konfigurasi. Pemeriksaan sinyal harus mencakup latensi jaringan, validitas sertifikat, dan status service discovery.

Prinsipnya sama: identifikasi apa yang bisa salah untuk jenis perubahan spesifik ini, dan periksa hal-hal tersebut sebelum menyatakan deployment selesai.

Daftar Periksa Praktis Pasca-Deployment

Jika Anda menginginkan sesuatu yang konkret untuk memulai, berikut adalah daftar periksa minimal yang berfungsi untuk sebagian besar aplikasi web:

  • Smoke test berhasil: halaman utama, endpoint API kritis, koneksi database
  • Error rate tidak lebih tinggi dari sebelum deployment
  • Latensi dalam kisaran normal
  • Penggunaan CPU dan memori stabil
  • Tidak ada log atau pesan error yang tidak biasa di log aplikasi
  • Jika migrasi database terlibat: status migrasi berhasil, performa kueri normal

Daftar periksa ini tidak lengkap, tetapi mencakup dasar-dasarnya. Anda dapat memperluasnya seiring Anda mempelajari sinyal apa yang paling penting untuk sistem spesifik Anda.

Intisari

Pipeline hijau tidak berarti deployment berhasil. Pipeline menangani mekanisme pengiriman. Verifikasi menangani kenyataan apakah versi baru benar-benar berfungsi. Jangan anggap deployment selesai sampai Anda memeriksa bahwa versi baru berjalan normal di produksi. Kebiasaan sederhana ini akan menangkap masalah sebelum pengguna Anda yang melakukannya.