Meluncurkan, mengunggah, menerapkan — esensi istilah dan perbedaan

Apa arti “meluncurkan”, “mengunggah”, “menerapkan”

“Meluncurkan” — istilah paling umum yang berarti mempublikasikan versi baru produk perangkat lunak, fitur, atau perubahan. “Kami meluncurkan pembaruan”, “kami meluncurkan perbaikan”, “kami meluncurkan rilis” — dalam semua kasus, yang dimaksud adalah bahwa perubahan telah tersedia bagi pengguna. Istilah ini mengasumsikan tindakan yang cukup besar: biasanya versi keseluruhan diluncurkan, bukan satu file.

“Mengunggah” — istilah yang lebih spesifik yang berarti mengunggah file, data, atau artefak ke server atau repositori. “Unggah build ke server”, “unggah skrip ke DB”, “unggah aset ke CDN”. Berbeda dengan “meluncurkan”, istilah ini tidak berarti bahwa yang diunggah telah tersedia bagi pengguna — file mungkin ada di server tetapi belum terhubung ke aplikasi. Nuansa: “mengunggah” juga digunakan untuk mengirim kode ke repositori (“saya mengunggah ke GitHub”).

“Menerapkan” — istilah yang berarti menerapkan perubahan di atas versi yang ada. “Terapkan migrasi”, “terapkan patch”, “terapkan konfig”. Perbedaan utama — perubahan diterapkan di atas tanpa penggantian total. Jika “meluncurkan” adalah menjalankan versi baru menggantikan yang lama, maka “menerapkan” adalah menambahkan perubahan ke apa yang sudah berjalan. Istilah ini umum dalam konteks basis data (migrasi) dan rilis patch.

Istilah tambahan dari bidang semantik yang sama: “menyebarkan” (menyebarkan perubahan ke semua server di cluster), “memutar balik” (mengembalikan versi sebelumnya), “secara tidak sengaja men-deploy” (secara tidak sengaja men-deploy versi yang salah). Semua kata kerja ini menggambarkan tindakan dengan kode sebagai objek fisik yang dapat “digulung”, “dituang”, dan “dikembalikan”.

Asal usul istilah slang

Istilah “meluncurkan” berasal dari metafora mobil: “mengeluarkan mobil dari garasi”. Ketika kode siap untuk dirilis, kode tersebut “diluncurkan” — dikeluarkan, dibuat tersedia bagi pengguna. Metafora menyebar pada awal tahun 2000-an dengan munculnya praktik continuous delivery, ketika rilis menjadi teratur, bukan tahunan. “Hari ini kita ada peluncuran” — berarti hari rilis.

Istilah “mengunggah” berakar dari web awal, ketika situs diunggah ke server melalui FTP. “Mengunggah file ke server” — secara harfiah mentransfer file melalui protokol yang diasosiasikan dengan “menuangkan” data. Kata ini bertahan, meskipun deployment modern menggunakan pipeline CI/CD, bukan klien FTP. Fakta menarik: dalam bahasa Inggris analognya adalah “push” (push to server), bukan “pour”. Bahasa Rusia memilih metafora yang berbeda.

Istilah “menerapkan” berasal dari lingkungan produksi: “menerapkan roda”, “menerapkan mur”. Dalam konteks perangkat lunak — menerapkan perubahan pada sistem yang ada, seperti memasang ulir pada baut. Dalam basis data, istilah ini sangat organik: migrasi justru “diterapkan” (apply) dan “dikembalikan” (rollback). Rollback — salah satu dari sedikit istilah Inggris yang memiliki padanan Indonesia yang tepat “pemutaran balik”.

Perbedaan antara istilah dalam konteks berbeda

Dalam konteks basis data: migrasi “diterapkan”, data “diunggah”, versi skema “diluncurkan”. Jika perlu menambahkan kolom baru — migrasi diterapkan. Jika perlu memasukkan data uji — dump diunggah. Jika struktur basis data berubah total — skema baru diluncurkan. Perbedaan mencerminkan operasi yang berbeda: apply, insert/load, deploy.

Dalam konteks DevOps: “meluncurkan” — menjalankan pipeline, “mengunggah” — mengunggah image Docker ke registry, “menerapkan” — menerapkan konfigurasi ke server melalui Ansible. Contoh: “pertama kita unggah image ke registry, lalu terapkan konfig ke server, dan baru kemudian luncurkan rilis”. Setiap istilah sesuai dengan tahap terpisah dari pipeline CI/CD.

Dalam konteks pengembangan seluler: “mengunggah” — mengirim build ke App Store Connect atau Google Play Console, “meluncurkan” — mempublikasikan di toko aplikasi, “menerapkan” — mengirimkan pembaruan melalui mekanisme in-app updates. Untuk iOS “meluncurkan” berarti melewati Review, untuk Android — rollout melalui Play Console. Skala waktu: “mengunggah” memakan waktu menit, “meluncurkan” — jam atau hari (karena review).

Tahapan proses rilis: dari commit ke produksi

Tahap 1: Build (Build). Kode dikompilasi, artefak (binari, image Docker, APK/IPA) dibuat. Server CI menjalankan build setelah setiap commit ke branch utama. Hasil build — artefak siap deployment dengan tag versi unik (semantic versioning atau commit hash). Jika build gagal — seluruh pipeline berhenti, pengembang mendapat notifikasi.

Tahap 2: Pengujian (Test). Pengujian unit, pengujian integrasi, linter, pemeriksaan keamanan (SAST) dijalankan. Tahap ini tidak boleh lebih dari 10–15 menit — jika lebih lama, pengembang kehilangan konteks dan beralih ke tugas lain. Umpan balik cepat — prinsip utama CI/CD. Menurut Puppet State of DevOps 2023, tim dengan pengujian cepat (<10 menit) melakukan 3 kali lebih banyak rilis.

Tahap 3: Deployment ke staging (Staging Deploy). Artefak di-deploy ke lingkungan staging, identik dengan produksi. Di staging, pengujian E2E, pengujian smoke, dan jika perlu, pengujian manual QA dilakukan. Jika regresi terdeteksi di staging — rilis diblokir, perubahan dikirim untuk diperbaiki.

Tahap 4: Rollout ke produksi (Production Deploy). Artefak di-deploy ke server produksi. Tergantung pada strategi deployment (rolling, blue-green, canary), rollout dapat berlangsung dari beberapa detik hingga beberapa jam. Setelah rollout, pengujian post-deploy dan monitoring dijalankan — jika metrik normal, rilis dianggap berhasil. Pemutaran balik otomatis saat melebihi ambang batas kesalahan — praktik standar.

Strategi deployment: rolling, blue-green, canary

Rolling deploy — memperbarui server satu per satu. Sementara satu server diperbarui, yang lain terus melayani pengguna. Setelah server pertama berhasil diperbarui, server kedua diperbarui, dan seterusnya. Kekurangan: selama deployment, versi berbeda berjalan di server, yang dapat menyebabkan ketidakcocokan. Kelebihan: zero-downtime dan tidak perlu jumlah server dua kali lipat.

Blue-green deploy — dua lingkungan identik: Blue (versi saat ini) dan Green (versi baru). Setelah Green sepenuhnya siap dan diuji, load balancer mengalihkan lalu lintas dari Blue ke Green. Jika masalah terdeteksi di Green — kami beralih kembali ke Blue. Kelebihan: rollback instan. Kekurangan: perlu dua kali lipat sumber daya (server) untuk mendukung dua lingkungan. Peralihan memakan waktu detik.

Canary deploy — versi baru pertama kali di-deploy ke persentase kecil server (5–10%). Sebagian pengguna masuk ke versi baru, sisanya ke versi lama. Jika metrik di grup canary normal (error rate tidak meningkat, latency tidak bertambah), versi baru secara bertahap di-rollout ke semua server. Google, Netflix, Spotify menggunakan canary deploy untuk meminimalkan risiko. Kekurangan: kompleksitas monitoring dan analisis metrik.

Alat otomatisasi deployment

Server CI/CD — Jenkins, GitLab CI, GitHub Actions, CircleCI, Bitrise (untuk seluler). Dipilih tergantung pada stack: Jenkins — universal, GitLab CI — jika repositori di GitLab, Bitrise — untuk iOS/Android. Tugas utama server CI/CD — menjalankan pipeline build, pengujian, dan deployment secara otomatis tanpa campur tangan manusia.

Kontainerisasi — Docker, Kubernetes. Docker membuat kontainer terisolasi dengan aplikasi dan semua dependensi. Kubernetes mengelola deployment kontainer di cluster server: rolling update otomatis, penskalaan, penyeimbangan. Menurut CNCF Survey 2023, 96% organisasi menggunakan kontainer dalam produksi, 67% di antaranya menggunakan Kubernetes.

Infrastructure as Code — Terraform, Ansible, Pulumi. Terraform mendeskripsikan infrastruktur (server, jaringan, load balancer) dalam bentuk kode dan mengelola statusnya. Ansible — konfigurasi server: instalasi perangkat lunak, pengaturan parameter. Kombinasi Terraform + Ansible memberikan infrastruktur yang sepenuhnya otomatis: Terraform membuat server, Ansible mengonfigurasinya. Immutable infrastructure — server tidak diperbarui, tetapi diganti dengan yang baru dengan image yang diperbarui.