Jika Anda memiliki sebuah bisnis dan pengembang Anda terus berdebat tentang "lingkungan", inilah argumen yang diterjemahkan ke dalam istilah yang jelas. Pentingnya lingkungan pementasan yang mereka dorong bermuara pada satu gagasan: Anda menginginkan salinan latihan sistem Anda di mana perubahan diuji sebelum pelanggan nyata menyentuhnya. Lewati saja, dan setiap pembaruan akan dibuka pada malam tanpa latihan, langsung, di depan penonton yang membayar.

Saya telah membereskan cukup banyak bencana pada Jumat malam sehingga saya yakin akan hal ini. Lingkungan pementasan (staging environment) adalah salah satu bentuk asuransi termurah yang dapat dibeli oleh bisnis perangkat lunak, dan merupakan salah satu bentuk asuransi yang paling sering dilewati, biasanya untuk "menghemat waktu". Waktu yang dihemat hanyalah ilusi. Waktu yang diperlukan ketika terjadi kesalahan di depan pelanggan sangatlah nyata.

Izinkan saya menjelaskan kasus ini dalam bahasa yang tidak mengharuskan Anda menjadi seorang insinyur.

Metafora latihan teater

Bayangkan situs web atau aplikasi langsung Anda sebagai malam pembuka sebuah pertunjukan. Penonton sungguhan, tiket terjual, tidak ada pengulangan. Sekarang bayangkan sutradara berkata: "Kami hanya akan mengubah naskah, memindahkan lokasi syuting, dan menukar dua aktor, dan melihat bagaimana kelanjutannya selama pertunjukan sebenarnya." Anda akan memecat direktur itu.

Itulah sebenarnya yang dimaksud dengan “pengujian dalam produksi”. Produksi adalah sistem langsung Anda, yang digunakan pelanggan. Menguji dalam produksi berarti membuat perubahan secara langsung dan mencari tahu apakah perubahan tersebut berfungsi dengan melihat pelanggan sebenarnya menemukan bug.

Lingkungan pementasan adalah gladi bersih. Ini adalah salinan terpisah dari sistem Anda, diatur semirip mungkin dengan sistem asli, tempat tim menjalankan kinerja penuh terlebih dahulu. Jika himpunan baru tersebut runtuh, ia akan runtuh pada tahap yang kosong. Tidak ada yang membeli tiket untuk itu.

Tiga lingkungan yang paling banyak digunakan tim di peta untuk hal ini:

  • Pengembangan adalah ruang penulis, tempat setiap orang menyusun perubahan di mesinnya sendiri.
  • Pementasan adalah gladi bersih, salinan bersama yang mencerminkan produksi, di mana semuanya diuji bersama sebelum dirilis.
  • Produksi dibuka pada malam hari, sistem langsung yang digunakan pelanggan Anda.

Kisah horor nyata karena melewatkannya

Ini dianonimkan, tetapi bentuknya sangat umum.

Sebuah jaringan ritel di Tangerang melakukan perubahan "kecil" pada pembayaran toko online mereka pada hari Jumat sore, langsung ke tahap produksi, tanpa pementasan. Perubahan tersebut secara diam-diam menghentikan langkah pembayaran untuk satu jenis kartu populer. Karena saat itu hari Jumat malam, tidak ada yang memperhatikan dengan cermat. Pada hari Senin mereka kehilangan penjualan di akhir pekan dan, lebih buruk lagi, sejumlah pelanggan yang mencoba sekali, gagal, dan tidak pernah kembali lagi. Perbaikan kode memakan waktu sepuluh menit. Kepercayaan itu tidak kembali dalam sepuluh menit.

Sebuah perusahaan distribusi memperbarui sistem pemesanan internal mereka langsung di server langsung menjadi "hanya memperbaiki satu bidang". Perbaikan ini memiliki efek samping yang merusak cara penyimpanan pesanan baru. Tidak ada yang menyadarinya selama dua hari karena aplikasinya masih terlihat baik-baik saja. Mengurai data yang buruk membutuhkan biaya yang jauh lebih besar daripada nilai fitur tersebut.

Polanya selalu sama. Perubahannya tampak kecil. Perubahan kecil adalah perubahan yang dilakukan tanpa latihan, dan perubahan kecil memiliki efek samping yang tidak diperkirakan sebelumnya. Lingkungan pementasan (staging environment) adalah tempat di mana efek samping tersebut muncul dengan biaya murah.

Berapa biayanya versus satu penerapan yang buruk

Pemilik menolak pementasan karena rasanya seperti biaya tambahan dan waktu tambahan. Mari kita berikan angka yang jujur.

Biaya penyiapan pementasan minimal:- Server atau hosting instan kedua yang lebih kecil. Bagi sebagian besar UKM di Indonesia, jumlah ini berkisar antara beberapa ratus ribu hingga jutaan rupiah per bulan, seringkali lebih murah jika bisa dianggap sederhana.

  • Upaya satu kali untuk membuat skrip penerapan sehingga mendorong ke pementasan, lalu produksi, dapat diulangi, bukan manual.
  • Sedikit disiplin: perubahan masuk ke staging dulu, dicek, baru dipromosikan.

Biaya satu penerapan produksi yang buruk:

  • Kehilangan penjualan setiap jam checkout, atau fungsi inti, rusak.
  • Waktu staf dihabiskan untuk memadamkan kebakaran alih-alih melakukan pekerjaan mereka.
  • Pembersihan data, yang mungkin jauh lebih mahal dibandingkan bug aslinya.
  • Kepercayaan pelanggan, item baris yang paling sulit ditentukan harganya dan paling lambat pulih.

Satu penerapan yang gagal pada hari Jumat dapat memakan biaya lebih dari satu tahun untuk menjalankan lingkungan pementasan sederhana. Ini adalah logika yang sama di balik [kasus teknologi yang membosankan] (/blog/the-case-for-boring-technology): praktik yang tidak menarik dan dapat diprediksi secara diam-diam mencegah drama yang mahal. Pementasan sengaja dibuat membosankan. Itulah fiturnya.

Pengaturan minimal yang benar-benar cukup

Anda tidak memerlukan jaringan perusahaan besar untuk mendapatkan perlindungan maksimal. Pengaturan starter pragmatis:

  1. Satu salinan pementasan yang mencerminkan produksi dengan cermat. Versi perangkat lunak yang sama, salinan data yang realistis dengan segala hal sensitif yang dihapus. Semakin mirip dengan produksi, semakin banyak bug yang ditangkap.
  2. Peraturan yang diikuti semua orang: tidak ada yang mencapai produksi tanpa melalui tahapan terlebih dahulu. Tidak ada pengecualian untuk perubahan "kecil", karena perubahan kecil adalah tempat tersembunyinya kerusakan.
  3. Daftar periksa singkat untuk dijalankan pada staging sebelum melakukan promosi. Apakah alur inti masih berfungsi? Bisakah pelanggan menyelesaikan pembelian atau tugas utama? Apakah ada sesuatu yang jelas-jelas rusak?
  4. Langkah penerapan yang sederhana dan dapat diulang. Jadi, melakukan promosi dari tahap ke tahap produksi adalah tindakan yang dapat diandalkan, bukan proses manual yang rumit.
  5. Hindari penerapan pada hari Jumat dan penghujung hari jika Anda bisa. Jika ada masalah yang terjadi, Anda ingin orang-orang tetap sadar dan siap untuk memperbaikinya.

Jumlah ini cukup untuk mengatasi sebagian besar pemadaman listrik yang dilakukan sendiri. Anda selalu bisa mematangkannya nanti.

Kesimpulan praktisnya

Pentingnya lingkungan pementasan yang terus ditingkatkan oleh pengembang Anda bukanlah kesombongan teknis, melainkan manajemen risiko dasar yang dinyatakan dalam istilah kode. Salinan latihan sistem Anda memungkinkan perubahan yang melanggar gagal pada tahap kosong, bukan di depan pelanggan yang membayar. Penyiapannya murah dan membosankan; bencana yang dicegahnya mahal dan berkesan. Bersikeras bahwa setiap perubahan, terutama yang kecil, harus melalui tahapan sebelum mencapai produksi, dan jauhkan penerapan yang berisiko pada hari Jumat. Ini adalah salah satu keputusan dengan keuntungan tertinggi dan terendah yang dapat Anda buat tentang perangkat lunak Anda.