Ketika Setiap Deployment Adalah Cerita yang Berbeda: Jerat Pengiriman Ad Hoc

Kamu punya tim kecil. Mungkin lima atau enam orang. Aplikasi berjalan. Pengguna puas. Deployment terjadi, tapi tidak ada yang benar-benar membahas bagaimana caranya. Seorang pengembang menyalin file ke server menggunakan FTP. Yang lain menjalankan skrip dari laptop pribadinya. Yang ketiga langsung login ke production dan melakukan perubahan secara langsung.

Tidak ada yang mengeluh, karena semuanya berjalan. Sampai suatu saat tidak.

Orang yang "tahu cara deploy" pergi cuti. Ada bug kritis yang harus segera dirilis, dan tidak ada orang lain yang bisa memahami langkah-langkahnya. Deployment memakan waktu tiga jam, bukan dua puluh menit. Seseorang menjalankan perintah SQL yang salah terhadap database production. Tidak ada cara untuk mengembalikannya.

Ini adalah Level 1 dari maturity delivery: Ad Hoc. Semuanya manual. Semuanya berbeda setiap kali. Dan seluruh proses bergantung pada siapa yang tersedia, bukan pada apa yang terdokumentasi atau terotomatisasi.

Masalah Ketergantungan Individu

Tanda paling jelas dari proses delivery Ad Hoc adalah bahwa pengetahuan tersimpan di dalam kepala orang, bukan di sistem bersama. Ketika satu orang memegang pengetahuan deployment, orang itu menjadi bottleneck. Jika dia cuti, deployment berhenti. Jika dia keluar dari perusahaan, pengetahuan ikut pergi.

Bahkan ketika dokumentasi ada, biasanya sudah usang. Seseorang menulis README enam bulan lalu. Sejak itu, langkah deployment berubah lima kali. Tidak ada yang memperbarui dokumen. Anggota tim baru belajar dengan trial and error, bertanya kepada siapa pun yang tampaknya tahu apa yang mereka lakukan.

Diagram alir berikut mengilustrasikan bagaimana deployment ad hoc dapat bercabang ke jalur yang tidak terduga, masing-masing dengan risikonya sendiri:

flowchart TD A[Developer starts deployment] --> B{Which method?} B --> C[FTP files to server] B --> D[Run personal script] B --> E[Direct edit on production] C --> F[Files may be incomplete] D --> G[Script only works on one machine] E --> H[Risk of wrong SQL command] F --> I[Deployment fails silently] G --> J[Another dev cannot run it] H --> K[No rollback possible] I --> L[Person on leave - no fix] J --> L K --> L L --> M[Deployment takes hours]

Ini bukan tentang ketidakmampuan. Tim kecil sering bertahan dengan cara ini karena risikonya rendah. Tapi seiring tim bertambah besar, retakan mulai terlihat. Setiap deployment menjadi petualangan baru. Tidak ada yang bisa memprediksi apakah akan memakan waktu sepuluh menit atau dua jam.

Deployment Manual: Tidak Ada yang Sama

Di lingkungan Ad Hoc, tidak ada prosedur deployment standar. Setiap pengembang punya metode sendiri. Satu orang mungkin SSH ke server, menarik kode terbaru, dan me-restart service. Yang lain mungkin mengunggah file zip melalui antarmuka web. Yang ketiga mungkin menjalankan skrip lokal yang hanya berfungsi di mesinnya.

Karena tidak ada sumber kebenaran tunggal, tidak ada yang bisa memverifikasi apakah deployment dilakukan dengan benar. Ketika sesuatu gagal, orang yang melakukan deployment mulai menebak. Mereka mencoba perintah yang berbeda, me-restart service, memeriksa log, dan berharap sesuatu berhasil. Jika mereka buntu, mereka menelepon orang lain yang mungkin tahu lebih banyak.

Pendekatan ini berfungsi ketika kamu deploy sebulan sekali. Ini menjadi menyakitkan ketika kamu perlu deploy mingguan atau harian. Setiap deployment membawa risiko yang sama, karena prosesnya tidak pernah diperbaiki. Kesalahan berulang. Waktu terbuang untuk menemukan kembali solusi yang sama.

Perubahan Database Tanpa Jaring Pengaman

Manajemen database di Level 1 sangat berbahaya. Perubahan skema diterapkan langsung ke database production. Seorang pengembang login ke server database, menjalankan pernyataan ALTER TABLE, dan berharap tidak ada yang rusak.

Tidak ada skrip migrasi. Tidak ada pelacakan versi. Tidak ada rencana rollback. Jika perubahan menyebabkan masalah, pengembang yang sama harus mencari cara untuk membalikkannya, seringkali dengan menjalankan perintah SQL manual lain yang mungkin berhasil atau tidak.

Tim tidak punya cara untuk mengetahui versi skema mana yang sedang berjalan. Jika dua pengembang melakukan perubahan pada waktu yang sama, konflik tidak terdeteksi sampai sesuatu rusak. Data production bisa hilang, korup, atau tertinggal dalam keadaan tidak konsisten.

Infrastruktur yang Dikelola oleh Ingatan

Server diatur secara manual. Seseorang login, menginstal paket, mengkonfigurasi service, dan menyesuaikan pengaturan dengan tangan. Konfigurasi aplikasi berada di file di server, bukan di version control. Jika server mati, tim harus mengingat setiap langkah yang diperlukan untuk membuatnya kembali.

Tidak ada Infrastructure as Code. Tidak ada provisioning otomatis. Tidak ada proses setup yang dapat diulang. Tim mengandalkan ingatan, catatan tempel, dan itikad baik dari siapa pun yang menyiapkan server asli.

Ini berfungsi ketika kamu punya satu atau dua server. Ini menjadi tidak terkendali ketika kamu perlu scaling, pulih dari kegagalan, atau mereplikasi lingkungan untuk pengujian.

Mengapa Tim Tetap di Level 1

Tetap di Level 1 bukanlah tanda kemalasan atau kurangnya keterampilan. Banyak tim bertahan di sini karena alasan yang valid:

  • Tim sangat kecil, dan proses manual cukup cepat.
  • Deployment jarang terjadi, sehingga rasa sakitnya tidak konstan.
  • Aplikasi tidak kritis, sehingga kegagalan berdampak rendah.
  • Tim memiliki prioritas lain yang terasa lebih mendesak.

Alasan-alasan ini masuk akal dalam jangka pendek. Tapi mereka menciptakan biaya tersembunyi. Setiap deployment manual membawa risiko. Setiap langkah yang tidak terdokumentasi menciptakan ketergantungan. Setiap perubahan database langsung meningkatkan kemungkinan kehilangan data.

Masalahnya bukan karena tim melakukan sesuatu yang salah. Masalahnya adalah bahwa pendekatan saat ini tidak scalable. Ketika tim bertambah besar, ketika deployment menjadi lebih sering, atau ketika aplikasi menjadi lebih kritis, proses Ad Hoc menjadi liability.

Langkah Pertama Bukan Membeli Alat

Bergerak melampaui Level 1 tidak memerlukan alat mahal atau pipeline yang kompleks. Langkah pertama lebih sederhana dan lebih sulit: akui bahwa proses saat ini tidak dapat diandalkan, dan mulailah mendokumentasikan apa yang sebenarnya terjadi selama deployment.

Sebelum kamu mengotomatiskan apa pun, kamu perlu tahu apa yang kamu otomatiskan. Sebelum kamu membangun pipeline, kamu perlu menyepakati langkah-langkahnya. Sebelum kamu membeli platform CI/CD, kamu perlu memahami workflowmu sendiri.

Checklist Praktis untuk Bergerak Melampaui Ad Hoc

Jika kamu mengenali timmu dalam deskripsi ini, inilah tempat untuk memulai:

  • Tuliskan langkah-langkah persis untuk deployment, termasuk setiap perintah dan setiap titik keputusan.
  • Identifikasi siapa yang memegang pengetahuan kritis dan apa yang terjadi ketika orang itu tidak tersedia.
  • Daftar setiap langkah manual yang dapat menyebabkan kegagalan jika dilakukan dengan tidak benar.
  • Dokumentasikan skema database saat ini dan bagaimana perubahan diterapkan.
  • Catat proses setup server, termasuk semua paket, konfigurasi, dan dependensi.

Ini bukan tentang membuat dokumentasi yang sempurna. Ini tentang membuat yang tidak terlihat menjadi terlihat. Setelah proses dituliskan, kamu bisa melihat di mana risikonya dan di mana otomatisasi benar-benar akan membantu.

Intisari Konkret

Pengiriman Ad Hoc berfungsi sampai tidak berfungsi. Saat deployment gagal dan tidak ada yang tahu cara memperbaikinya, atau orang yang tahu tidak dapat dihubungi, biaya proses manual menjadi jelas. Jalan ke depan bukan tentang alat atau otomatisasi dulu. Ini tentang mengakui bahwa cara saat ini rapuh, dan mulai menuliskan apa yang kamu lakukan sehingga kamu akhirnya bisa melakukannya dengan lebih baik.