.png)
Sumber: ChatGPT
Ketika Rilis Menjadi Peristiwa yang Ditakuti
Di banyak organisasi, menerapkan pembaruan ke sistem produksi adalah kegiatan yang dijadwalkan pada dini hari, melibatkan banyak orang, dan disertai kesiapan untuk membatalkan bila terjadi masalah.
Prosedur seperti ini terasa hati-hati, tetapi konsekuensinya justru berbahaya. Karena rilis mahal dan menegangkan, tim cenderung menundanya dan menumpuk banyak perubahan dalam satu kali penerapan. Semakin banyak perubahan yang dirilis bersamaan, semakin besar kemungkinan ada yang bermasalah dan semakin sulit menemukan mana penyebabnya.
Layanan IT project dengan hasil efisien dan cepat justru berangkat dari arah sebaliknya. Rilis dibuat sedemikian aman sehingga bisa sering dilakukan, dan karena sering, setiap rilis memuat sedikit perubahan yang mudah ditelusuri.
Tiga Cara Merilis Tanpa Menghentikan Layanan
Ada beberapa pendekatan yang masing-masing punya keunggulan dan biaya berbeda, sehingga pemilihannya bergantung pada kondisi masing-masing sistem.
Menyiapkan lingkungan kedua yang identik. Versi baru dipasang di lingkungan terpisah dan diuji sepenuhnya, lalu trafik dialihkan sekaligus. Keunggulannya, pembatalan bisa dilakukan dalam hitungan detik dengan mengembalikan arah trafik. Biayanya, dibutuhkan kapasitas dua kali lipat selama masa peralihan.
Merilis ke sebagian kecil pengguna terlebih dahulu. Versi baru hanya menerima sebagian kecil trafik, lalu perilakunya dipantau. Bila indikatornya wajar, porsinya dinaikkan bertahap. Keunggulannya, masalah yang lolos pengujian hanya berdampak pada sebagian kecil pengguna.
Mengganti instance secara bertahap. Unit aplikasi lama diganti satu per satu sehingga layanan tetap tersedia sepanjang proses. Keunggulannya, tidak membutuhkan kapasitas berlebih. Kekurangannya, pembatalan lebih lambat karena harus mengganti kembali satu per satu.
Hambatan Terbesar Ada di Basis Data
Mengganti versi aplikasi relatif mudah. Yang jauh lebih sulit adalah mengubah struktur data, karena data tidak bisa digandakan begitu saja seperti aplikasi.
Persoalannya, selama masa peralihan akan ada dua versi aplikasi yang berjalan bersamaan dan keduanya harus bisa bekerja dengan struktur data yang sama. Perubahan yang langsung menghapus atau mengganti nama kolom akan merusak versi yang belum diperbarui.
Solusinya adalah memecah perubahan menjadi beberapa tahap yang aman. Tahap pertama hanya menambahkan struktur baru tanpa menyentuh yang lama, sehingga kedua versi tetap bisa berjalan. Tahap kedua memindahkan data ke struktur baru secara bertahap. Tahap ketiga, setelah versi lama benar-benar tidak dipakai lagi, struktur lama baru dibersihkan.
Pendekatan bertahap ini membuat setiap tahap bisa dibatalkan tanpa kehilangan data, dan inilah yang membuat rilis tanpa penghentian layanan benar-benar mungkin.
Yang Harus Ada Sebelum Ini Bisa Diterapkan
Pendekatan di atas hanya aman bila didukung beberapa hal yang perlu disiapkan lebih dulu.
Pengujian otomatis yang memadai. Tanpa ini, rilis yang sering justru memperbanyak kesempatan memasukkan kesalahan ke produksi.
Pemeriksaan kesehatan yang bermakna. Pemeriksaan yang hanya menjawab bahwa aplikasi menyala tidak cukup. Yang dibutuhkan adalah pemeriksaan yang memastikan aplikasi benar-benar siap melayani, termasuk koneksi ke basis data dan layanan pendukungnya.
Pemantauan dengan pembanding. Untuk menilai apakah versi baru berperilaku wajar, dibutuhkan gambaran mengenai perilaku normal sebelumnya.
Prosedur pembatalan yang pernah diuji. Kemampuan membatalkan yang belum pernah dicoba pada kondisi nyata tidak bisa diandalkan saat benar-benar dibutuhkan.
Kapan Proses Rilis Anda Perlu Dibenahi
Proses rilis yang berat jarang dianggap sebagai masalah karena sudah menjadi kebiasaan.
Sinyal bahwa proses rilis Anda perlu diperbaiki: Rilis dijadwalkan di luar jam kerja karena menuntut penghentian layanan. Frekuensi rilis rendah sehingga setiap rilis memuat banyak perubahan sekaligus. Pembatalan rilis membutuhkan waktu lama dan berisiko kehilangan data. Perubahan struktur basis data selalu menjadi bagian paling menegangkan. Tidak ada pengujian otomatis yang berjalan sebelum penerapan. Pemeriksaan kesehatan hanya memastikan aplikasi menyala, bukan siap melayani. Tim menghindari rilis menjelang akhir pekan atau hari libur. Langkah Memulai Bersama Sagara Sagara memulai dari menilai kesiapan pendukungnya, bukan langsung menerapkan pendekatan rilis yang baru. Konsultasi discovery untuk memahami proses rilis yang berjalan dan hambatannya. Audit arsitektur untuk menilai kesiapan pengujian, pemeriksaan kesehatan, dan pemantauan. Implementasi bertahap yang dimulai dari layanan dengan risiko paling rendah agar tim terbiasa sebelum diterapkan pada layanan kritis. Kesimpulan Rilis yang menegangkan membuat tim menundanya, dan penundaan justru menumpuk risiko yang seharusnya bisa disebar ke banyak rilis kecil. Layanan IT project dengan hasil efisien dan cepat berangkat dari membuat rilis cukup aman untuk sering dilakukan, sehingga setiap perubahan mudah ditelusuri bila bermasalah. Sagara Technology membantu perusahaan Indonesia mengubah pembaruan sistem dari peristiwa yang ditakuti menjadi kegiatan rutin yang terprediksi.
