Mengapa Strategi Deployment Anda Bergantung pada Jenis Aplikasi yang Dibangun

Saat pertama kali mulai membangun perangkat lunak, setiap aplikasi tampak kurang lebih sama. Anda menulis kode, menjalankannya, dan seseorang menggunakannya. Namun, begitu Anda perlu mengirimkan aplikasi tersebut ke tempat di mana pengguna nyata bergantung padanya, Anda akan segera menemukan bahwa aplikasi memiliki kepribadian yang sangat berbeda. Dan perbedaan-perbedaan itu menentukan segalanya tentang cara Anda melakukan deployment.

Aplikasi Stateless: Sederhana dan Mudah Diganti

Bayangkan sebuah API cuaca. Ia menerima nama kota, mengembalikan data suhu dan kelembaban. Setiap permintaan bersifat independen. Aplikasi mengambil data baru setiap kali, tidak menyimpan apa pun secara lokal, dan tidak memiliki memori tentang siapa yang menanyakan apa.

Jenis aplikasi ini disebut stateless. Ia tidak peduli dengan permintaan sebelumnya. Setiap panggilan adalah lembaran baru.

Aplikasi stateless adalah yang paling mudah di-deploy. Jika versi baru rusak, Anda tinggal menggantinya dengan versi lama. Tidak ada data yang perlu dikhawatirkan, tidak ada migrasi yang harus dibatalkan, tidak ada sakit kepala kompatibilitas. Anda dapat melakukan rollback dalam hitungan detik. Anda dapat melakukan scaling horizontal dengan menjalankan lebih banyak salinan. Anda dapat mematikan instance tanpa upacara.

Risikonya terbatas. Jika ada yang salah, kerusakan hanya terbatas pada permintaan yang sedang berlangsung. Tidak ada yang kehilangan data. Tidak ada sesi pengguna yang rusak.

Aplikasi Stateful: Hati-hati dan Rumit

Sekarang bayangkan sistem pemesanan tiket bioskop. Aplikasi ini menyimpan kursi mana yang sudah terisi, siapa yang membelinya, dan bagaimana mereka membayar. Setiap transaksi mengubah status sistem. Database memegang kebenaran, dan kode aplikasi harus tetap sinkron dengan kebenaran itu.

Ini adalah aplikasi stateful. Ia bergantung pada data yang persisten. Dan itu mengubah segalanya tentang deployment.

Anda tidak bisa begitu saja menukar versi. Jika versi baru mengubah cara membaca atau menulis data, skema database mungkin perlu dimigrasi terlebih dahulu. Jika migrasi berjalan dan kode baru memiliki bug, rollback tidaklah mudah. Kode lama mungkin tidak memahami skema baru. Data mungkin sudah berubah. Anda mungkin harus mengembalikan dari backup, yang memakan waktu dan berisiko kehilangan transaksi terbaru.

Aplikasi stateful membutuhkan urutan yang hati-hati: migrasi database, deploy kode baru, verifikasi semuanya berfungsi, dan memiliki rencana untuk apa yang harus dilakukan jika tidak berfungsi. Rollback jarang berupa satu perintah. Ini sering kali merupakan prosedur multi-langkah yang membutuhkan koordinasi.

Spektrum Dampak: Alat Internal vs Layanan Publik

Aplikasi juga berbeda dalam seberapa besar kerusakan yang dapat ditimbulkan saat rusak.

Pertimbangkan dashboard admin internal yang digunakan oleh lima orang di perusahaan Anda. Jika down selama sepuluh menit, seseorang mungkin kesal, tetapi tidak ada yang kehilangan uang. Deployment bisa dilakukan secara langsung. Anda bisa mentolerir beberapa waktu henti. Anda bisa mendorong perubahan dan memperbaiki masalah nanti.

Sekarang pertimbangkan gateway pembayaran atau halaman checkout e-commerce. Ribuan pengguna mengaksesnya setiap detik. Jika rusak, transaksi gagal, pengguna mengeluh, pendapatan turun. Dampaknya langsung dan terukur.

Perbedaan dampak ini menentukan seberapa hati-hati Anda perlu selama deployment. Aplikasi berdampak rendah dapat di-deploy secara langsung dengan sedikit upacara. Aplikasi berdampak tinggi membutuhkan peluncuran bertahap, pemantauan, feature flags, dan rencana rollback yang jelas. Anda mungkin deploy ke satu server terlebih dahulu, pantau kesalahan, lalu secara bertahap tingkatkan lalu lintas. Anda mungkin menjalankan versi baru bersama versi lama untuk sementara waktu. Anda mungkin menggunakan canary deployment atau strategi blue-green.

Diagram alir berikut membantu Anda memutuskan strategi deployment yang sesuai dengan sifat aplikasi dan tingkat risikonya:

flowchart TD A[Mulai: Aplikasi macam apa?] --> B{Stateless atau Stateful?} B -->|Stateless| C{Tingkat dampak?} B -->|Stateful| D{Tingkat dampak?} C -->|Rendah| E[Rolling update sederhana] C -->|Tinggi| F[Blue-green atau canary] D -->|Rendah| G[Rolling dengan rencana migrasi] D -->|Tinggi| H[Peluncuran bertahap + migrasi DB + monitoring] E --> I[Rollback cepat dengan swap] F --> J[Pergeseran lalu lintas bertahap] G --> K[Uji prosedur rollback] H --> L[Rencana rollback multi-langkah]

Tingkat proses harus sesuai dengan tingkat risiko. Tidak setiap aplikasi membutuhkan pipeline deployment multi-jam dengan persetujuan dan runbook. Tetapi aplikasi yang dapat menyebabkan kerusakan nyata layak mendapatkan perhatian itu.

Ketergantungan: Kopling Tersembunyi

Beberapa aplikasi bersifat mandiri. Mereka berjalan tanpa membutuhkan apa pun. Anda deploy, mereka bekerja.

Kebanyakan aplikasi tidak seperti itu. Mereka bergantung pada database, API eksternal, antrean pesan, atau layanan internal lainnya. Versi baru aplikasi Anda mungkin bergantung pada endpoint baru dari API yang belum diperbarui. Mungkin mengharapkan format respons tertentu yang tidak disediakan oleh API lama. Mungkin membutuhkan migrasi database yang belum dijalankan.

Ketergantungan menciptakan kopling. Saat Anda deploy versi baru, Anda harus memastikan bahwa semua yang bergantung padanya tersedia dan kompatibel. Ini bukan hanya tentang uptime. Ini tentang kompatibilitas kontrak. Kode baru Anda mungkin berfungsi sempurna secara terisolasi tetapi gagal di produksi karena skema database berubah, respons API berubah, atau format pesan berubah.

Inilah mengapa urutan deployment itu penting. Jika aplikasi Anda bergantung pada database, migrasi database biasanya dilakukan terlebih dahulu. Jika bergantung pada layanan lain, layanan itu harus di-deploy terlebih dahulu atau setidaknya kompatibel mundur. Jika Anda tidak dapat menjamin kompatibilitas, Anda perlu mendesain deployment untuk menangani versi lama dan baru yang berjalan bersamaan.

Artinya bagi Pipeline CI/CD Anda

Semua perbedaan ini — stateless versus stateful, dampak rendah versus tinggi, mandiri versus bergantung — membentuk cara Anda membangun pipeline CI/CD.

Tidak ada satu strategi deployment yang cocok untuk setiap aplikasi. Pipeline yang dirancang untuk microservice stateless akan gagal untuk monolit stateful. Proses deployment yang dibangun untuk alat internal akan terlalu berisiko untuk sistem pembayaran yang berhadapan dengan pelanggan. Rencana rollback yang berfungsi untuk aplikasi mandiri akan rusak untuk aplikasi yang bergantung pada database yang telah dimigrasi.

Pipeline Anda harus mencerminkan sifat aplikasi yang dilayaninya. Itu berarti:

  • Aplikasi stateless dapat menggunakan pipeline sederhana dengan rollback cepat.
  • Aplikasi stateful membutuhkan langkah migrasi yang hati-hati dan prosedur rollback yang teruji.
  • Aplikasi berdampak tinggi membutuhkan deployment bertahap dan gate monitoring.
  • Aplikasi bergantung membutuhkan pemeriksaan kompatibilitas dan deployment yang diurutkan.

Daftar Periksa Praktis untuk Mengevaluasi Kebutuhan Deployment Aplikasi Anda

Sebelum mendesain atau menyesuaikan pipeline deployment Anda, jalankan daftar periksa ini:

  • Apakah aplikasi menyimpan data yang harus bertahan dari deployment? Jika ya, rencanakan migrasi database dan perubahan skema yang dapat dibalik.
  • Berapa banyak pengguna yang terpengaruh jika aplikasi down? Jika jumlahnya besar atau dampak finansialnya tinggi, tambahkan peluncuran bertahap dan monitoring.
  • Apakah aplikasi bergantung pada layanan atau database lain? Jika ya, verifikasi kompatibilitas dan rencanakan urutan deployment.
  • Dapatkah Anda melakukan rollback dengan menukar versi lama, atau Anda perlu mengembalikan perubahan data? Jika yang terakhir, uji prosedur rollback sebelum Anda membutuhkannya.
  • Dapatkah aplikasi menangani menjalankan dua versi secara bersamaan? Jika tidak, Anda mungkin memerlukan waktu henti atau pola deployment blue-green.

Intisari Konkret

Cara Anda melakukan deployment aplikasi tidak ditentukan oleh bahasa pemrograman, framework, atau alat yang Anda gunakan. Itu ditentukan oleh sifat aplikasi: apakah ia menyimpan state, seberapa besar kerusakan yang disebabkan oleh kegagalan, dan apa yang menjadi ketergantungannya. Pahami ketiga hal itu terlebih dahulu. Kemudian desain pipeline Anda. Segala sesuatu yang lain adalah detail implementasi.