Apa yang Sebenarnya Terjadi Saat Anda Melakukan Deployment: Menempatkan Artifak ke Lingkungan

Anda telah membangun aplikasi, menjalankan pengujian, dan menyimpan artifak yang telah terverifikasi. Sekarang tibalah momen yang diperhatikan semua orang: deployment. Ini adalah saat versi baru Anda mulai berjalan di suatu tempat yang nyata — apakah itu server staging untuk pengujian internal atau production tempat pengguna nyata bergantung padanya.

Deployment adalah tindakan menempatkan artifak ke lingkungan target dan membuatnya aktif. Tetapi jika Anda berpikir deployment hanya menyalin file ke server, Anda akan terkejut. Cara Anda melakukan deployment sepenuhnya tergantung pada apa yang Anda deploy: kode aplikasi, perubahan database, atau konfigurasi infrastruktur. Masing-masing memiliki mekanisme, risiko, dan strateginya sendiri.

Deployment Tidak Bersifat Satu-Untuk-Semua

Saat Anda melakukan deployment aplikasi, Anda mengganti versi yang sedang berjalan dengan yang baru. Ini bisa berarti mengirim image container baru ke Kubernetes, menukar file biner di server, atau memulai ulang service. Tujuannya sederhana: menghentikan versi lama dan memulai versi baru dengan gangguan minimal.

Deployment database adalah hal yang berbeda. Anda tidak mengganti file; Anda menjalankan skrip migrasi yang mengubah skema atau mentransformasi data. Database menyimpan state — catatan pengguna, pesanan, konfigurasi — yang harus tetap konsisten sebelum, selama, dan setelah perubahan. Anda tidak bisa begitu saja "menimpa" database seperti mengganti file JAR. Migrasi yang menambahkan kolom mungkin aman, tetapi yang mengganti nama tabel bisa merusak setiap kueri yang berjalan. Dan tidak seperti kode aplikasi, perubahan database seringkali tidak dapat diubah atau memerlukan skrip rollback yang hati-hati.

Deployment infrastruktur menambahkan lapisan lain. Di sini Anda menerapkan konfigurasi ke penyedia cloud atau alat provisioning seperti Terraform, Pulumi, atau Ansible. Deployment membuat, memodifikasi, atau menghancurkan resource: mesin virtual, load balancer, database, aturan jaringan. Kesalahan dalam deployment infrastruktur dapat menghapus database production atau mengekspos data sensitif ke internet. Taruhannya tinggi, dan loop umpan baliknya lebih lambat daripada deployment aplikasi.

Diagram alur berikut membandingkan tiga alur deployment secara berdampingan:

flowchart TD subgraph App["Deployment Aplikasi"] A1["Ganti instance"] --> A2["Rolling / Blue-Green / Canary"] A2 --> A3["Gangguan minimal"] end subgraph DB["Deployment Database"] D1["Jalankan skrip migrasi"] --> D2["Ubah skema / transformasi data"] D2 --> D3["Semua-atau-tidak sama sekali; rollback diperlukan"] end subgraph Infra["Deployment Infrastruktur"] I1["Terapkan konfigurasi ke cloud"] --> I2["Buat / ubah / hapus resource"] I2 --> I3["Umpan balik lambat; risiko tinggi"] end

Strategi Berbeda untuk Artifak Berbeda

Karena setiap jenis artifak berperilaku berbeda, strategi deployment yang berhasil untuk satu jenis mungkin tidak berhasil untuk yang lain.

Untuk aplikasi, Anda memiliki beberapa strategi yang terkenal:

Sebagai contoh, manifes Deployment Kubernetes untuk rolling update mungkin terlihat seperti ini:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
      - name: app
        image: my-app:v2.1.0
        ports:
        - containerPort: 8080
  • Rolling update: Ganti instance satu per satu. Versi lama secara bertahap digantikan oleh yang baru. Tidak ada downtime, tetapi versi lama dan baru berjalan berdampingan untuk sementara waktu.
  • Blue-green: Siapkan lingkungan baru yang lengkap (green) di samping lingkungan saat ini (blue). Setelah lingkungan green siap dan terverifikasi, alihkan semua traffic ke sana. Perpindahan instan, tetapi biaya infrastruktur dua kali lipat selama peralihan.
  • Canary: Kirim versi baru ke subset kecil pengguna terlebih dahulu. Pantau error atau degradasi kinerja. Jika semuanya baik, tingkatkan traffic secara bertahap. Jika tidak, rollback canary tanpa memengaruhi sebagian besar pengguna.

Strategi ini berhasil karena instance aplikasi bersifat stateless atau dapat dikuras (drained) dengan baik. Anda dapat menjalankan beberapa versi secara bersamaan tanpa merusak data.

Database tidak memiliki kemewahan itu. Anda tidak dapat menjalankan dua versi skema pada waktu yang sama dan mengharapkan perilaku yang konsisten. Rolling update untuk migrasi database jarang memungkinkan karena perubahan skema bersifat global — setiap kueri melihat struktur yang sama. Canary deployment untuk database juga sama rumitnya. Anda dapat menjalankan migrasi di replika terlebih dahulu, tetapi saat Anda mempromosikannya menjadi primary, semua pengguna terpengaruh. Perubahan database biasanya bersifat all-or-nothing: Anda menerapkan migrasi, memverifikasinya, dan jika ada yang salah, Anda menjalankan migrasi rollback.

Deployment infrastruktur berada di antara keduanya. Anda dapat menggunakan blue-green untuk infrastruktur dengan menyediakan serangkaian resource paralel dan mengalihkan target DNS atau load balancer. Tetapi perubahan infrastruktur seringkali memiliki dependensi: Anda tidak dapat membuat instance database baru tanpa juga memperbarui konfigurasi aplikasi yang mengarah ke sana. Dan perubahan infrastruktur bisa lambat — menyediakan cluster server baru mungkin memakan waktu menit, bukan detik.

Dua Prinsip yang Tidak Bisa Ditawar

Terlepas dari apa yang Anda deploy atau strategi mana yang Anda pilih, dua prinsip berlaku untuk setiap deployment.

Pertama: deployment harus dapat diulang (repeatable). Jika Anda menjalankan pipeline yang sama dua kali dengan artifak yang sama, Anda harus mendapatkan hasil yang sama. Ini berarti Anda harus men-deploy artifak yang sudah Anda verifikasi, bukan membangun ulang dari source pada saat deploy. Membangun ulang memperkenalkan ketidakpastian: mungkin server build memiliki versi library yang berbeda, mungkin jaringan lambat, mungkin compiler mengoptimalkan secara berbeda. Gunakan biner, image container, atau paket yang persis sama yang lulus pengujian Anda.

Repeatability juga mengharuskan lingkungan target Anda berada dalam state yang diketahui. Jika Anda tidak dapat menjamin apa yang sudah berjalan, Anda tidak dapat memprediksi apa yang akan terjadi saat Anda melakukan deployment. Infrastructure-as-code membantu di sini: ia mendefinisikan state yang diinginkan dari lingkungan Anda, sehingga deployment Anda tahu apa yang diharapkan.

Kedua: setiap deployment harus dicatat. Catat apa yang di-deploy, versi mana, commit mana, lingkungan mana, stempel waktu yang tepat, dan siapa atau apa yang memicunya. Ini bukan dokumen untuk auditor kepatuhan. Ini adalah garis pertahanan pertama Anda saat terjadi kesalahan. Saat pengguna mulai melaporkan error setelah deployment, log deployment memberi tahu Anda persis apa yang berubah. Tanpanya, Anda hanya menebak-nebak. Apakah itu perubahan kode? Pembaruan konfigurasi? Migrasi database? Perubahan infrastruktur? Log deployment yang baik langsung mempersempit pencarian.

Deployment Belum Selesai Saat Artifak Ditempatkan

Ini adalah kesalahan umum: pipeline menandai deployment berhasil saat artifak mendarat di lingkungan. Tetapi menempatkan artifak hanya setengah dari pekerjaan. Anda perlu memverifikasi bahwa versi baru benar-benar berjalan dengan benar.

Verifikasi setelah deployment adalah tahap terpisah. Ini memeriksa bahwa service merespons health check, bahwa migrasi database selesai tanpa error, bahwa resource infrastruktur berada dalam state yang diinginkan. Beberapa tim menjalankan smoke test — serangkaian cepat perjalanan pengguna kritis — untuk memastikan deployment tidak merusak sesuatu yang jelas.

Sampai verifikasi lulus, deployment belum selesai. Jika verifikasi gagal, pipeline harus memicu rollback atau memberi tahu tim segera. Menunggu seseorang menyadari masalah berjam-jam kemudian mengalahkan tujuan otomatisasi.

Checklist Praktis Sebelum Deployment Berikutnya

Sebelum Anda menekan tombol deploy atau membiarkan pipeline Anda berjalan, jalankan checklist singkat ini:

  • Apakah artifak yang sama yang lulus semua pengujian? (Tidak ada build ulang pada saat deploy.)
  • Apakah lingkungan target dalam state yang diketahui? (Tidak ada perubahan manual yang mungkin bertentangan.)
  • Apakah strategi deployment sesuai untuk jenis artifak? (Rolling untuk aplikasi, migrasi untuk database, provision untuk infrastruktur.)
  • Apakah ada rencana rollback? (Dapatkah Anda mengembalikan perubahan dengan cepat? Untuk database, apakah Anda memiliki skrip migrasi rollback yang siap?)
  • Apakah deployment akan dicatat secara otomatis? (Versi, commit, stempel waktu, pemicu.)
  • Apakah ada langkah verifikasi setelah deployment? (Health check, smoke test, atau alert monitoring.)

Intisari

Deployment adalah momen di mana pekerjaan Anda bertemu dengan kenyataan. Ini bukan operasi penyalinan file. Ini adalah serah terima yang direncanakan dengan cermat antara pipeline Anda dan sistem yang berjalan. Jenis artifak menentukan strategi, state lingkungan menentukan risiko, dan log deployment menentukan seberapa cepat Anda dapat pulih dari kegagalan. Perlakukan deployment dengan ketelitian yang sama seperti menulis kode — karena deployment yang buruk dapat membatalkan berminggu-minggu kerja baik dalam hitungan detik.