Gambar 1. Aplikasi di smartphone (sumber: www.pexels.com)

Bayangkan suasana kantor pukul 16.30 WIB di hari Jumat. Di satu sudut, tim engineering bersiap menyambut akhir pekan; di sudut lain, suasana tegang menyelimuti persiapan rilis besar. Sebuah anekdot klasik di industri ini selalu berulang: proses deploy sukses pada pukul 17.00, namun tepat pada Sabtu malam, sirene notifikasi berdering kencang. Terjadi kegagalan kritis di production, dan akhir pekan berubah menjadi sesi pemadaman kebakaran (firefighting). Dari ketakutan dan trauma kolektif inilah, aturan tidak tertulis “No Deploy Friday” dilahirkan.

Akar Mitos dan Data Realita

Aturan ini berakar dari era metodologi Waterfall dengan arsitektur monolitik, di mana rilis dilakukan manual dan proses pemulihan (rollback) bisa memakan waktu berhari-hari. Secara psikologis, kita terjebak dalam bias availability heuristic (lebih mudah mengingat satu insiden traumatis yang menghancurkan liburan dibanding ribuan deployment Jumat yang berjalan tanpa kendala).

Namun, narasi horor ini mulai dipatahkan oleh data. Riset DevOps Research and Assessment (DORA) dari Google Cloud menunjukkan bahwa tim dengan performa elit (Elite Performers) melakukan deploy kapan saja, termasuk Jumat sore, tanpa lonjakan insiden. Hal ini berkat Mean Time to Recovery (MTTR) mereka yang sangat rendah. Ironisnya, studi PagerDuty (2023) mengungkap bahwa 57% insiden kritis di hari Jumat justru dipicu oleh rilis terburu-buru pada hari Kamis sore, demi menghindari aturan “Dilarang Deploy Jumat”.

Validasi Trauma Masa Lalu

Meski statistik mendukung rilis fleksibel, rasa takut para engineer adalah sesuatu yang valid. Skenario malapetaka ini sangat nyata bagi organisasi dengan infrastruktur yang belum matang:

• Database Lock: Migrasi skema SQL berat yang dilakukan saat lalu lintas transaksi akhir pekan melonjak.
• Silent Bugs: Kesalahan yang tidak terdeteksi langsung karena tim monitoring sedang libur, dan baru meledak di hari Senin.
• Communication Silo: Eskalasi yang lambat karena personel kunci tidak berstatus siaga (off-duty).

Bagi organisasi yang belum matang, “No Friday Deploy” bukanlah sebuah kemunduran,

melainkan tameng rasional yang mencegah burnout massal.

Praktik Modern: Menjinakkan Hari Jumat

Tim modern menaklukkan ketakutan hari Jumat dengan memisahkan proses pengiriman kode teknis (deploy) dari pengaktifan fitur bisnis (release). Berikut adalah pilar utamanya:

• Feature Flags: Kode dapat dikirim ke production kapan saja dalam kondisi “mati” (menggunakan LaunchDarkly atau Split.io). Fitur baru dinyalakan dengan aman pada hari Senin pagi.
• Canary Delivery: Mengirimkan pembaruan hanya ke 5% pengguna terlebih dahulu. Sistem seperti Argo Rollouts akan memantau metrik dan otomatis melakukan rollback jika terjadi anomali.
• AI-Driven Rollback: Platform observabilitas modern mampu mendeteksi anomali log secara real-time dan memutuskan pembatalan rilis dalam waktu kurang dari 30 detik tanpa campur tangan manusia.
• Shift-Left & Chaos Engineering: Uji ketahanan dilakukan secara rutin. Perubahan basis data selalu dirancang dengan prinsip backward-compatible agar pemulihan kode tidak merusak data.
• On-Call Manusiawi: Rotasi yang adil, panduan eskalasi (runbook) yang jelas, dan transisi pemantauan antar zona waktu (follow-the-sun) agar beban tidak menumpuk di satu individu.

 

Checklist: Apakah Tim Anda Siap?

Lakukan evaluasi mandiri sebelum mencabut aturan larangan deploy hari Jumat:

Gambar 2.Contoh checklist kesiapan infrastruktur

Jika kotak-kotak di atas belum tercentang, tidak masalah untuk tetap menghormati hari Jumat. Kematangan rekayasa (engineering maturity) tidak dibangun dalam semalam.

 

Penutup: Kemampuan, Bukan Pemilihan Hari

Esensi perdebatan ini bukanlah mengenai “boleh atau tidak rilis di hari Jumat”, melainkan indikator kapabilitas. Apakah sistem kita cukup tangguh untuk melakukan rilis kapan saja? Prinsip dasar Continuous Delivery menyatakan: “If it hurts, do it more often.” Semakin sering kita melakukan deploy dengan skala kecil, semakin terpaksa sistem kita menjadi otomatis dan kebal terhadap kesalahan manusia.

Di dunia yang beroperasi 24/7, ketenangan akhir pekan seorang engineer sejati bukan lagi tentang menghindari hari Jumat, melainkan tentang kemampuan deploy kapan saja, lalu menutup laptop dengan keyakinan penuh bahwa sistem penjaga (automation & monitoring) akan melakukan tugasnya dengan baik.

 

 

REFERENSI:

1. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
2. Google Cloud. (2023). DevOps Research and Assessment (DORA) Report 2023.
3. Majors, C., Gilmore, L., & Fong-Jones, L. (2022). Observability Engineering. O’Reilly Media.
4. (2023). The State of Digital Operations and Incident Response Analysis.
5. Hodgson, P. (2017). Feature Toggles (aka Feature Flags). MartinFowler.com.
6. Majors, C. (2019). Deploy On Fridays Or Die Trying. charity.wtf blog.
7. Continuous Delivery & CI/CD Guide. Atlassian Agile Coach.
8. Orosz, G. The Pragmatic Engineer: Shipping Culture. Pragmatic Engineer Newsletter.