Apa yang Terjadi Setelah Anda Menekan Tombol Deploy: Memastikan Versi Baru Benar-Benar Berfungsi

Tombol deploy sudah ditekan. Pipeline menunjukkan warna hijau. Tim Anda menghela napas lega. Tapi jika Anda berpikir pekerjaan selesai, Anda sedang menjebak diri sendiri.

Saya telah melihat pola ini terjadi di banyak tim. Versi baru rilis, semua orang bersorak, lalu tiga puluh menit kemudian tiket support pertama masuk. Fiturnya berfungsi di staging, tapi di production malah memakan memori. API merespon dengan baik terhadap panggilan tes Anda, tapi lalu lintas pengguna nyata mengekspos race condition yang tidak tertangkap siapa pun.

Rilis bukanlah garis finis. Ini adalah momen ketika pengujian sesungguhnya dimulai.

Mengapa Staging Tidak Cukup

Tim Anda mungkin sudah menjalankan tes sebelum rilis. Unit test lulus. Integration test hijau. Lingkungan staging terlihat sehat. Semua itu bagus, tapi tidak cukup.

Staging tidak memiliki pengguna nyata. Tidak memiliki volume data nyata. Tidak memiliki pola lalu lintas tak terduga yang ditangani production setiap hari. Sebuah query database yang berjalan 50 milidetik di staging bisa memakan waktu lima detik di production karena tabel production memiliki jutaan baris. Sebuah fitur yang berfungsi baik dengan akun tes bisa rusak ketika dihadapkan dengan token autentikasi dari belasan penyedia identitas berbeda.

Kesenjangan antara staging dan production inilah mengapa pengecekan pasca-rilis itu ada. Anda perlu memastikan bahwa versi yang berjalan di production benar-benar berfungsi seperti yang diharapkan, dalam kondisi nyata.

Mulai dengan Smoke Test

Hal pertama yang harus dilakukan setelah rilis adalah smoke test. Nama ini berasal dari elektronik: saat Anda menyalakan papan sirkuit untuk pertama kalinya, Anda memeriksa apakah ada asap yang keluar. Tidak ada asap berarti papan tidak terbakar, dan Anda bisa melanjutkan ke pengujian yang lebih dalam.

Dalam perangkat lunak, smoke test adalah pemeriksaan cepat untuk melihat apakah versi baru masih hidup. Anda mengakses halaman utama dan memastikannya termuat. Anda memanggil endpoint API kritis dan memeriksa bahwa ia mengembalikan respons. Anda memverifikasi bahwa koneksi database terbentuk. Anda memastikan alur login tidak langsung crash.

Smoke test sengaja dibuat dangkal. Anda tidak menguji setiap fitur atau kasus tepi. Anda menjawab satu pertanyaan: apakah deployment benar-benar berhasil, atau aplikasi sudah rusak sejak awal?

Berikut adalah perintah bash sederhana yang bisa Anda jalankan tepat setelah deployment untuk melakukan smoke test:

curl -f https://prod.example.com/health && echo "Smoke test passed" || echo "Smoke test failed"
flowchart TD A[Rilis] --> B[Smoke Test] B -->|Lulus| C[Verifikasi] B -->|Gagal| D[Rollback] C -->|Lulus| E[Monitoring Kesehatan] C -->|Gagal| D E -->|Anomali Terdeteksi| F{Tingkat Keparahan?} F -->|Ringan| G[Hotfix] F -->|Berat| D E -->|Normal| H[Lanjutkan Monitoring] G --> E

Smoke test yang baik memakan waktu kurang dari dua menit. Jika sudah diotomatisasi, ia berjalan dalam hitungan detik. Jika Anda melakukannya secara manual, buatlah daftar periksa tetap pendek. Maksimal lima hingga sepuluh pemeriksaan. Lebih dari itu Anda sudah masuk ke wilayah verifikasi.

Lanjut ke Verifikasi

Setelah smoke test lulus, Anda perlu memverifikasi bahwa versi baru berperilaku benar. Verifikasi lebih sistematis. Anda membandingkan perilaku aktual sistem dengan apa yang diharapkan.

Di sinilah rangkaian tes yang sudah ada menjadi berguna kembali. Jalankan tes otomatis kritis terhadap production. Bukan rangkaian regresi penuh, tapi subset yang mencakup fitur yang baru saja Anda ubah. Jika Anda menambahkan alur checkout baru, verifikasi bahwa pesanan dapat dilakukan. Jika Anda mengubah algoritma pencarian, verifikasi bahwa hasil pencarian masuk akal.

Verifikasi juga mencakup pemeriksaan manual untuk hal-hal yang sulit diotomatisasi. Periksa log untuk error tak terduga. Lihat data yang diproses setelah rilis. Pastikan fitur baru dapat dijangkau melalui antarmuka pengguna normal.

Perbedaan utama dari smoke test adalah kedalaman. Smoke test bertanya "apakah ia hidup?" Verifikasi bertanya "apakah ia bekerja dengan benar?"

Pantau Sinyal Kesehatan

Smoke test dan verifikasi adalah pemeriksaan aktif. Anda mengirim permintaan dan mengamati respons. Tapi ada lapisan pemeriksaan lain yang terjadi secara pasif: memantau sinyal kesehatan.

Sinyal kesehatan adalah metrik yang memberi tahu Anda apakah sistem dalam kondisi baik. Penggunaan CPU, konsumsi memori, tingkat permintaan, tingkat error, waktu respons, utilisasi koneksi database, kedalaman antrian. Angka-angka ini berubah terus menerus saat pengguna berinteraksi dengan sistem.

Setelah rilis, Anda ingin mengamati sinyal-sinyal ini untuk anomali. Lonjakan tiba-tiba pada tingkat error adalah tanda bahaya. Peningkatan penggunaan memori secara bertahap bisa mengindikasikan kebocoran. Waktu respons yang terus meningkat bisa berarti kode baru lebih lambat di bawah beban.

Perbedaan antara sinyal kesehatan dan pengujian aktif itu penting. Pengujian aktif memberi tahu Anda apa yang terjadi saat Anda secara spesifik bertanya. Sinyal kesehatan memberi tahu Anda apa yang terjadi secara alami saat pengguna menggunakan sistem. Keduanya diperlukan.

Siapkan dashboard yang menampilkan metrik ini berdampingan dengan baseline versi sebelumnya. Lebih baik lagi, konfigurasikan alert yang terpicu saat metrik melampaui ambang batas. Anda tidak ingin menemukan masalah dengan menatap grafik selama satu jam. Anda ingin sistem memberi tahu saat ada yang salah.

Berapa Lama Anda Harus Memeriksa?

Durasi pengecekan pasca-rilis tergantung pada perubahannya.

Untuk perbaikan bug kecil atau penambahan fitur minor, beberapa menit smoke test dan observasi sinyal kesehatan sudah cukup. Jika tidak ada yang rusak dalam sepuluh menit pertama, perubahannya mungkin aman.

Untuk fitur besar, migrasi database, atau perubahan infrastruktur, Anda perlu waktu lebih lama. Rencanakan untuk memantau selama beberapa jam. Beberapa tim mengawasi ketat selama satu hari kerja penuh setelah rilis besar. Alasannya adalah masalah tertentu butuh waktu untuk muncul. Kebocoran memori mungkin tidak terlihat sampai sistem memproses ribuan permintaan. Query lambat mungkin hanya terlihat ketika pengguna konkuren mencapai ambang tertentu.

Yang penting adalah menentukan periode pengecekan sebelum rilis. Sepakati apa yang akan diperiksa, berapa lama, dan ambang batas apa yang memicu rollback. Jangan buat keputusan ini di tengah insiden.

Saat Terjadi Masalah

Jika pengecekan pasca-rilis Anda menemukan masalah, Anda perlu memutuskan apa yang harus dilakukan. Keputusannya biasanya bermuara pada dua opsi: hotfix atau rollback.

Hotfix tepat digunakan ketika masalahnya kecil, terisolasi, dan bisa diperbaiki dengan cepat. Salah ketik pada nilai konfigurasi. Izin yang hilang pada endpoint baru. Gangguan CSS yang hanya memengaruhi satu browser. Anda bisa menambalnya dan deploy lagi tanpa mengganggu pengguna.

Rollback tepat digunakan ketika masalahnya serius. Korupsi data. Kerentanan keamanan. Fitur yang merusak seluruh alur pengguna. Regresi performa yang membuat sistem tidak bisa digunakan. Dalam kasus ini, cara tercepat untuk memulihkan layanan adalah kembali ke versi sebelumnya.

Keputusan harus dibuat sebelum rilis, bukan saat krisis. Tentukan apa yang dianggap masalah yang layak di-hotfix dan apa yang layak di-rollback. Dokumentasikan. Pastikan semua orang di tim tahu kriterianya.

Daftar Periksa Pasca-Rilis Praktis

Berikut adalah daftar periksa pendek yang bisa Anda adaptasi untuk tim. Sesuaikan item berdasarkan aplikasi dan toleransi risiko Anda.

  • Smoke test: halaman utama termuat, API kritis merespon, database terhubung
  • Verifikasi otomatis: jalankan subset tes yang mencakup fitur yang diubah
  • Verifikasi manual: periksa log, pastikan fitur baru dapat diakses
  • Sinyal kesehatan: tinjau tingkat error, waktu respons, penggunaan sumber daya
  • Konfigurasi alert: pastikan alert monitoring aktif dan ambang batas sudah diatur
  • Kriteria rollback: pastikan tim tahu apa yang memicu rollback dan siapa yang memutuskan

Inti Sebenarnya

Pengecekan pasca-rilis bukanlah opsional. Ini adalah langkah yang memisahkan tim yang melakukan deploy dengan percaya diri dari tim yang melakukan deploy dan berdoa. Tujuannya bukan untuk menghilangkan semua masalah production, itu tidak mungkin. Tujuannya adalah menangkap masalah dengan cepat, sebelum memengaruhi banyak pengguna, dan memiliki rencana yang jelas untuk merespons saat Anda menemukannya.

Deployment Anda belum selesai saat pipeline berubah hijau. Ia selesai saat Anda telah memastikan bahwa versi baru berjalan dengan benar di production, di bawah lalu lintas nyata, dan sinyal kesehatan Anda terlihat normal. Itulah momen ketika Anda benar-benar bisa mengatakan rilis berhasil.