Deployment Adalah: Arti, Proses, dan Strategi Deploy

Aplikasi atau website yang baru selesai dibuat biasanya hanya berjalan di satu tempat: komputer pembuatnya. Developer membukanya lewat alamat localhost, mencoba tombol demi tombol, dan semuanya tampak berfungsi. Namun, tidak ada orang lain yang bisa membukanya. Laptop itu tidak menyala 24 jam, tidak punya alamat publik, dan akan dibawa pulang pemiliknya.

Deployment adalah proses yang menjembatani jarak tersebut: memindahkan aplikasi dari lingkungan pembuatnya ke server yang bisa diakses pengguna, lalu menjalankannya di sana. Istilah ini terdengar sederhana, tetapi di baliknya ada urutan langkah, beberapa strategi, dan risiko yang cukup serius. Artikel ini membahas apa itu deployment, arti deploy, dan apa yang terjadi saat aplikasi di-deploy. Setelah itu, kita lihat cara-cara melakukannya dan alasan tim developer memperlakukan momen ini dengan sangat hati-hati.

Pengertian Deployment dan Arti Kata Deploy

Dalam dunia software, deployment adalah rangkaian kegiatan untuk memasang versi aplikasi ke lingkungan tempat ia akan dipakai, lalu membuatnya siap melayani pengguna. Lingkungan itu bisa berupa server web, layanan cloud, toko aplikasi, atau komputer-komputer di sebuah kantor. Secara harfiah, deployment artinya "penerapan", dan kadang diterjemahkan "penyebaran" atau "pemasangan". Di lingkungan kantor, istilah ini juga dipakai untuk memasang software ke banyak komputer sekaligus, misalnya lewat Office Deployment Tool dari Microsoft.

Kata kerjanya adalah deploy. Jadi, deploy artinya menerapkan atau memasang aplikasi ke server, misalnya "tim akan men-deploy versi baru malam ini". Adapun deployed menunjukkan status: deployed artinya aplikasi sudah terpasang dan berjalan di server tujuan. Dalam percakapan sehari-hari, developer Indonesia sering menulisnya "sudah di-deploy".

Asal katanya justru dari dunia militer. Kata deploy berasal dari bahasa Prancis déployer yang berarti "membentangkan". Dalam bahasa Inggris, kata ini tercatat sejak 1786 untuk menyebut pasukan yang dibentangkan dari barisan berbanjar menjadi barisan siap tempur. Makna itu masih terasa di software: aplikasi yang tadinya "terlipat" di laptop developer dibentangkan ke server agar siap bekerja.

Deploy, Development, Release, dan Hosting: Empat Istilah yang Sering Tertukar

Deployment baru benar-benar jelas saat diletakkan di samping tiga istilah yang sering dianggap sama dengannya. Tabel berikut merangkum perbedaannya:

Istilah	Pertanyaan yang dijawab	Contoh
Development	Bagaimana aplikasi dibuat?	Menulis kode fitur baru
Deployment	Bagaimana aplikasi sampai di server?	Memasang versi baru di server
Release	Kapan fitur dibuka untuk pengguna?	Menyalakan fitur untuk semua orang
Hosting	Di mana aplikasi berada?	Paket hosting atau VPS

Development (pengembangan) adalah pekerjaan membuat dan memperbaiki kode. Deployment datang sesudahnya dan tidak menambah fitur apa pun. Ia hanya memindahkan hasil development ke tempat yang tepat. Karena itu, kode yang bagus pun bisa gagal di tahap deploy, misalnya karena konfigurasi server berbeda.

Perbedaan dengan release (rilis) lebih halus. Deploy berarti kodenya sudah terpasang di server, sedangkan release berarti fiturnya sudah bisa dirasakan pengguna. Keduanya bisa dipisah dengan feature flag (sakelar fitur di dalam kode): fitur baru ikut ter-deploy hari Senin, tetapi baru dinyalakan hari Kamis setelah semua siap.

Adapun hosting adalah tempatnya, bukan kegiatannya. Hosting menyediakan server yang menyala terus dan terhubung ke internet, sementara deployment adalah proses menaruh aplikasi Anda di dalam server itu. Anda bisa punya hosting tanpa pernah melakukan deploy, tetapi tidak bisa deploy tanpa tempat tujuan.

Apa yang Terjadi Saat Aplikasi Di-deploy?

Proses deployment adalah urutan langkah yang kurang lebih sama, entah dikerjakan tangan atau otomatis. Detailnya berbeda antar-teknologi, tetapi kerangkanya seperti berikut:

1. Build: Kode sumber diolah menjadi bentuk siap jalan, disebut artefak. Untuk aplikasi Java, artefaknya berkas .jar. Untuk website React, artefaknya kumpulan berkas HTML, CSS, dan JavaScript yang sudah diperkecil. Untuk Docker, artefaknya berupa image.
2. Kirim ke server: Artefak disalin ke server tujuan, misalnya lewat FTP, SSH, atau registry container.
3. Konfigurasi dan migrasi: Pengaturan khusus server dipasang, seperti alamat database dan kunci API. Kalau struktur tabel berubah, migrasi database dijalankan di tahap ini.
4. Alihkan trafik: Server berhenti melayani versi lama dan mulai melayani versi baru. Tahap ini paling menentukan apakah pengguna merasakan jeda atau tidak.
5. Verifikasi: Tim memeriksa halaman utama, log error, dan metrik server selama beberapa menit pertama. Kalau ada masalah, versi lama dipulihkan. Langkah mundur ini disebut rollback.

Rollback sering dilupakan pemula, padahal ia jaring pengaman seluruh proses. Alat deploy seperti Capistrano secara bawaan menyimpan 5 rilis terakhir di server, sedangkan Deployer menyimpan 10. Tujuannya satu: kembali ke versi sebelumnya cukup dengan memindahkan satu penunjuk, tanpa build ulang.

Sebelum langkah pertama, banyak tim menguji versi baru di lingkungan staging, yaitu salinan server produksi yang tidak dibuka untuk publik. Dengan begitu, sebagian besar kejutan sudah muncul sebelum pengguna sungguhan terkena dampaknya.

Tiga Cara Deploy Website: Unggah Manual, Git, dan Pipeline Otomatis

Pertanyaan "deploy website adalah apa" paling mudah dijawab lewat cara orang benar-benar melakukannya. Ada tiga tingkat yang umum dilalui pemilik website, dari yang paling sederhana.

Tingkat 1: Unggah Berkas Manual

Berkas website disalin ke server lewat File Manager di cPanel atau aplikasi FTP seperti FileZilla. Cara ini cukup untuk website statis atau WordPress yang jarang diubah kodenya. Kelemahannya ada pada ketelitian manusia: satu berkas yang lupa diunggah membuat server berjalan dengan campuran versi lama dan baru. Riwayat perubahan pun tidak tercatat, sehingga rollback berarti mengunggah ulang dari cadangan.

Tingkat 2: Git Lewat SSH

Kode disimpan di repositori Git, lalu server menarik versi terbaru dengan perintah git pull melalui SSH. Setiap versi punya catatan, dan kembali ke versi sebelumnya cukup dengan satu perintah Git. cPanel juga menyediakan fitur Git Version Control yang bisa men-deploy repositori ke folder website berdasarkan berkas konfigurasi .cpanel.yml. Untuk aplikasi Laravel, Node.js, atau Python yang butuh akses terminal dan kendali root penuh, tingkat ini biasanya dijalankan di VPS.

Tingkat 3: Pipeline Otomatis

Setiap kali kode masuk ke cabang utama, sebuah pipeline (rangkaian tugas otomatis) menjalankan tes, membangun artefak, lalu men-deploy-nya tanpa campur tangan manusia. Alat yang populer untuk ini antara lain GitHub Actions, GitLab CI, dan Jenkins. Hasilnya konsisten karena langkahnya sama persis setiap kali, tetapi pipeline butuh waktu untuk dibangun dan dirawat.

Di luar tiga tingkat itu, ada layanan yang mengambil alih seluruh urusan deploy. Platform seperti Heroku menerima kode lewat git push lalu mengurus sisanya. Layanan serverless bahkan tidak memperlihatkan servernya sama sekali. Kemudahan itu dibayar dengan biaya yang lebih tinggi dan kendali yang lebih sempit.

Strategi Deployment: Recreate, Rolling, Blue-Green, dan Canary

Strategi deployment (deployment strategies) menjawab satu pertanyaan: bagaimana cara berpindah dari versi lama ke versi baru? Ada empat strategi yang paling sering dipakai, masing-masing dengan harga yang berbeda.

1. Recreate: Semua instance versi lama dimatikan, baru versi baru dinyalakan. Paling sederhana dan tidak butuh server tambahan, tetapi pengguna mengalami downtime (layanan tidak bisa diakses) selama jeda itu.
2. Rolling update: Instance diganti bergiliran, sebagian demi sebagian. Kubernetes memakai strategi ini secara bawaan, dengan paling banyak 25% pod tidak tersedia dan paling banyak 25% pod tambahan di atas jumlah yang diminta. Tanpa downtime, tetapi selama proses berlangsung dua versi melayani pengguna bersamaan.
3. Blue-green deployment: Ada dua lingkungan produksi yang identik. "Biru" melayani pengguna, sementara "hijau" diisi versi baru dan diuji. Setelah siap, router atau load balancer dipindahkan ke hijau. Rollback cukup dengan memindahkan router kembali ke biru. Konsekuensinya, Anda membutuhkan kapasitas server dua kali lipat selama perpindahan.
4. Canary deployment: Versi baru hanya diberikan ke sebagian kecil pengguna, misalnya 5%, lalu diperluas bertahap kalau metriknya aman. Namanya diambil dari burung kenari yang dulu dibawa penambang batu bara. Burung itu mati lebih dulu saat ada gas beracun, sehingga penambang sempat menyelamatkan diri.

Jadi, blue green deployment adalah strategi dua lingkungan kembar yang ditukar sekaligus, sedangkan canary deployment adalah strategi uji coba bertahap ke sebagian pengguna. Keduanya punya kelemahan yang sama: perubahan struktur database harus dirancang agar cocok dengan versi lama dan baru sekaligus, karena untuk sementara keduanya hidup berdampingan.

Kenapa Deploy Menjadi Momen Paling Rawan

Deployment adalah saat perubahan menyentuh sistem yang sedang dipakai orang, dan di situlah sebagian besar masalah bermula. Buku Site Reliability Engineering dari Google mencatat bahwa kira-kira 70% gangguan layanan disebabkan oleh perubahan pada sistem yang sedang berjalan. Karena itu Google menekankan tiga kebiasaan: perubahan diluncurkan bertahap, masalah dideteksi cepat, dan rollback dilakukan dengan aman.

Contoh paling mahal terjadi pada 1 Agustus 2012 di Knight Capital, perusahaan perantara saham di Amerika Serikat. Menurut laporan SEC, seorang teknisi tidak menyalin kode baru ke satu dari delapan server sistem perdagangannya. Tidak ada orang kedua yang memeriksa hasil deploy itu. Server yang tertinggal menjalankan kode lama yang sudah bertahun-tahun tidak dipakai. Dalam kira-kira 45 menit, sistem itu mengeksekusi lebih dari 4 juta transaksi, dan Knight menanggung kerugian lebih dari $460 juta.

Kasus yang lebih baru terjadi pada Juli 2024. Sebuah pembaruan konten dari CrowdStrike, perangkat lunak keamanan untuk Windows, dikirim sekaligus ke seluruh pelanggannya. Microsoft memperkirakan 8,5 juta perangkat Windows terdampak dan gagal menyala. Dalam laporan pasca-insidennya, CrowdStrike berjanji mengubah cara pengirimannya menjadi bertahap, diawali dengan canary deployment.

Kedua kasus itu tidak berawal dari kode yang rumit. Yang gagal adalah cara kodenya sampai ke server: satu salinan yang terlewat, dan satu pembaruan yang langsung dikirim ke semua perangkat.

Hal yang Perlu Anda Pertimbangkan Sebelum Deploy

Anda tidak perlu infrastruktur sebesar Google untuk men-deploy dengan aman. Kebiasaan berikut sudah mengurangi sebagian besar risiko, bahkan untuk website kecil:

1. Buat cadangan dulu: Simpan backup berkas dan database sesaat sebelum deploy, bukan backup harian semalam. Perubahan data pengguna sejak semalam ikut terlindungi.
2. Satu perubahan per deploy: Kalau sepuluh fitur di-deploy bersamaan lalu muncul bug, menemukan penyebabnya jauh lebih sulit daripada kalau hanya satu fitur yang berubah.
3. Pilih jam sepi: Deploy saat trafik rendah dan saat Anda masih punya waktu minimal satu sampai dua jam untuk memantau. Hindari deploy menjelang akhir pekan atau libur panjang.
4. Uji rollback, bukan hanya deploy: Rollback yang belum pernah dicoba sama dengan rollback yang tidak ada. Coba sekali di staging.
5. Pantau 15 menit pertama: Buka halaman penting, periksa log error, dan perhatikan penggunaan CPU serta memori server.

Ada sisi lain yang perlu dipertimbangkan. Otomatisasi penuh tidak selalu sepadan. Untuk blog statis yang berubah sebulan sekali, membangun pipeline bisa memakan waktu lebih lama daripada seluruh deploy manual setahun. Begitu pula blue-green: kapasitas server ganda masuk akal untuk toko online beromzet besar, tetapi berlebihan untuk profil perusahaan.

Kalau ingin mengukur kemajuan, pakai lima metrik DORA yang banyak dirujuk tim software:

• Deployment frequency: seberapa sering deploy dilakukan.
• Change lead time: lama sebuah perubahan kode sampai ke produksi.
• Change fail rate: persentase deploy yang langsung butuh penanganan.
• Failed deployment recovery time: lama pulih dari deploy yang gagal.
• Deployment rework rate: persentase deploy darurat akibat insiden di produksi.

Arti Deployment di Luar Dunia IT

Karena asal katanya umum, deployment juga dipakai di bidang lain dengan makna yang berbeda. Kalau Anda menemukan istilah ini di luar konteks software, kemungkinan maknanya salah satu dari berikut:

• Deployment karyawan: Dalam manajemen SDM, deployment karyawan adalah penempatan atau penugasan pegawai ke posisi, proyek, atau lokasi kerja tertentu sesuai kebutuhan organisasi.
• Deployment militer: Makna aslinya, yaitu pengerahan dan penempatan pasukan ke wilayah operasi.
• Quality Function Deployment (QFD): Metode perencanaan mutu yang dikembangkan Yoji Akao di Jepang sejak 1966 untuk menerjemahkan keinginan pelanggan menjadi spesifikasi teknis produk.

Di ranah software sendiri ada juga deployment diagram, yaitu diagram UML yang menggambarkan di perangkat keras mana tiap komponen aplikasi dipasang. Ia menggambarkan hasil deployment, bukan prosesnya.

Pertanyaan yang Sering Muncul

Deployment bahasa Indonesianya apa?

Padanan yang paling lazim adalah "penerapan". Dalam konteks teknis, "pemasangan" dan "penyebaran" juga dipakai. Meski begitu, sebagian besar developer Indonesia tetap memakai istilah aslinya, deploy atau deployment, karena sudah menjadi istilah baku di komunitas.

Apakah deploy sama dengan upload?

Tidak sepenuhnya. Upload hanya menyalin berkas ke server, dan itu baru satu bagian dari deploy. Deploy mencakup langkah lain seperti build, konfigurasi, migrasi database, menjalankan ulang aplikasi, dan memastikan versi baru benar-benar berfungsi. Untuk website HTML statis, keduanya memang hampir sama.

Deployed itu apa?

Deployed adalah status aplikasi yang sudah terpasang dan berjalan di server tujuan. Developer Indonesia biasa menyebutnya "sudah di-deploy". Namun, sudah di-deploy belum tentu berarti fiturnya sudah terlihat oleh pengguna, karena tim bisa menahan fitur baru dengan feature flag sampai waktu rilis.

Seberapa sering sebaiknya melakukan deploy?

Tidak ada angka baku, tetapi deploy kecil yang sering umumnya lebih aman daripada deploy besar yang jarang. Laporan DORA 2024 menunjukkan kelompok tim berperforma tertinggi melakukan deploy sesuai kebutuhan, bisa beberapa kali sehari, dengan tingkat kegagalan perubahan sekitar 5%. Untuk website kecil, deploy mingguan dengan perubahan kecil sudah merupakan ritme yang sehat.

Kesimpulan

Deployment adalah proses memindahkan aplikasi dari lingkungan pembuatnya ke server tempat pengguna bisa memakainya: build, kirim, konfigurasi, alihkan trafik, lalu verifikasi. Ia berbeda dari development yang membuat kode, release yang membuka fitur, dan hosting yang menyediakan tempatnya.

Untuk website kecil, unggah manual atau git pull lewat SSH sudah memadai, asalkan ada backup dan rencana rollback. Pipeline otomatis dan strategi seperti blue-green atau canary mulai sepadan ketika deploy makin sering dan dampak gangguannya makin mahal.

Semoga artikel ini membantu.