Cara Kerja Deployment: Tahap demi Tahap dari Build sampai Live

Kamu sudah tahu apa itu deployment — mengambil kodemu lalu menaruhnya di tempat yang bisa dijangkau orang sungguhan. Tapi waktu pertama kali menyaksikannya berjalan, rasanya seperti kotak hitam: kamu jalankan satu perintah, tunggu sebentar, dan perubahanmu tahu-tahu muncul di website yang sudah live. Sebenarnya apa yang terjadi di balik jeda itu? Ternyata deployment bukan satu lompatan misterius. Dia rangkaian langkah kecil yang masuk akal, dan begitu kamu bisa menyebut nama tiap langkahnya, semuanya berhenti terasa menakutkan.

Bagian yang bikin lega: langkah-langkah itu hampir selalu sama, apa pun alat atau platform yang kamu pakai. Layanan cloud sekali-klik maupun deploy manual yang kamu ketik tangan di server kosong sama-sama melewati tahap logis yang sama — bedanya cuma seberapa banyak yang disembunyikan dari pandanganmu. Pahami tahapannya sekali, dan kamu bakal mengenalinya di mana-mana.

Deployment itu pipeline, bukan satu momen

Gampang membayangkan deployment sebagai satu kejapan: detik ini kode “di sini”, detik berikutnya sudah “live”. Gambaran yang lebih akurat adalah sebuah pipeline — barisan langkah yang dilewati kodemu, masing-masing harus selesai sebelum langkah berikutnya mulai. Sebagian langkah menyiapkan kode, sebagian memindahkannya, sebagian menyiapkan server, dan beberapa langkah terakhir menyalakan saklarnya lalu memastikan tidak ada yang terbakar.

Berpikir dalam tahapan itu penting karena alasan praktis: waktu sebuah deployment gagal, dia gagal di satu tahap tertentu. Build-nya rusak, atau file gagal ditransfer, atau migrasi database error. Kalau kamu tahu tahapannya, pesan “deployment gagal” yang menakutkan tadi berubah jadi pertanyaan yang jauh lebih kecil — langkah yang mana? — dan itu hampir selalu bisa dijawab.

Kalau belum, ada baiknya kamu jernih dulu soal jurang yang sedang diseberangi deployment: beda antara kode yang jalan di mesinmu dan kode yang jalan untuk semua orang dibahas di localhost vs production. Deployment adalah jembatan antara dua dunia itu, dan tahapan di bawah adalah papan-papan penyusun jembatannya.

Tahapan universal

Hampir setiap deployment, dari yang paling sederhana sampai yang paling rumit, melewati versi dari tahapan berikut. Tidak semua proyek memakai seluruhnya, tapi inilah daftar lengkapnya.

  SOURCE         BUILD          PACKAGE        TRANSFER
  ───────  ──►  ────────  ──►  ─────────  ──►  ─────────
  kode kamu     compile /      bundel jadi    kirim ke
  + aset        bundel         rapi           server

                                                  │
                                                  ▼

  VERIFY    ◄──  SWITCH    ◄──  MIGRATE   ◄──  INSTALL
  ────────       ───────       ─────────      ──────────
  sudah naik     arahkan        update         pasang dep,
  dan sehat?     trafik ke      database       siapkan
                 versi baru     bila perlu     runtime

Ayo kita telusuri satu per satu dengan bahasa sederhana.

1. Build: ubah kode sumber jadi sesuatu yang bisa dijalankan

Kode yang kamu tulis tidak selalu sama dengan kode yang berjalan. Build adalah langkah yang mengubah kode sumber yang ramah-manusia jadi bentuk yang benar-benar dieksekusi server. Wujudnya tergantung stack-mu: proyek frontend mungkin membundel puluhan file jadi beberapa file yang sudah dioptimalkan, proyek TypeScript dikompilasi turun jadi JavaScript, bahasa terkompilasi mengubah kode sumber jadi binary. Bahkan proyek “tanpa perlu build” pun secara konsep punya langkah build yang kosong.

Ide pentingnya: build terjadi sebelum apa pun mendekati server, dan dia bisa gagal. Salah ketik yang bahkan tidak akan pernah dilihat server bisa menghentikan deploy di sini juga — dan justru itu yang kamu mau. Menangkap masalah saat build jauh lebih murah daripada menangkapnya saat sudah live.

# Langkah build khas untuk proyek web
npm install        # ambil library yang dibutuhkan kode
npm run build      # hasilkan output yang sudah dioptimalkan dan siap jalan

2. Package: bundel hasilnya jadi rapi

Begitu kamu punya output hasil build, biasanya kamu kumpulkan jadi satu unit yang rapi — kadang disebut artifact. Bentuknya bisa berupa file zip, binary terkompilasi, atau image container. Tujuannya satu hal yang utuh dan mandiri yang bisa kamu pindah-pindahkan dengan tenang: bundel persis inilah yang akan berjalan, tidak lebih dan tidak kurang.

Packaging inilah yang membuat deployment bisa diulang dengan hasil sama. Kalau kamu build sekali lalu mendeploy artifact yang sama ke staging dan kemudian ke production, kamu tahu yang sudah kamu uji adalah persis yang naik ke live. Build terpisah untuk tiap environment justru mengundang misteri klasik “tapi tadi di staging jalan”.

3. Transfer: pindahkan ke server

Sekarang bundel-nya harus benar-benar bepergian dari tempat dia di-build (laptopmu, atau sebuah build server) ke mesin yang akan menjalankannya. Di balik layar ini cuma menyalin file lewat jaringan — secara aman. Cara paling universal adalah lewat koneksi terenkripsi.

# Salin bundel hasil build ke server lewat koneksi aman
scp app.tar.gz user@server-kamu:/var/www/app/

Kamu tidak selalu mengetiknya sendiri. Sebuah platform mungkin menarik kodemu dari repository, atau sebuah build server yang mendorong artifact-nya untukmu. Tapi secara konsep, selalu ada sesuatu yang menyeberangi jurang dari “tempat dia di-build” ke “tempat dia akan berjalan”.

4. Install: siapkan runtime di server

Kode jarang berjalan sendirian. Dia butuh dependency-nya — library yang dia impor — dan sebuah runtime untuk mengeksekusinya (interpreter bahasa, mesin virtual, dan sebagainya). Tahap install memastikan server punya semua itu lengkap dan dengan versi yang tepat. Di server, langkah ini sering mirip dengan yang kamu jalankan secara lokal, cuma diarahkan ke mesin production.

Di sinilah juga server dan laptop bisa berbeda dengan cara yang sering menggigit orang. Versi sebuah alat di mesinmu mungkin beda dengan yang ada di server; library yang “jelas-jelas terpasang” di lokal bisa saja hilang di production. Memasang dependency secara eksplisit, dari daftar yang dikunci, adalah cara tim menjaga keduanya tetap selaras.

5. Migrate: bawa database ke kondisi terbaru

Kalau aplikasimu memakai database, kode baru mungkin mengharapkan bentuk data yang baru — kolom baru, tabel baru, sebuah field yang diganti namanya. Migrasi database adalah skrip kecil yang berurutan untuk membuat perubahan struktur tadi supaya database cocok dengan yang diharapkan kode baru. Migrasi dijalankan sebagai bagian dari deploy, sebelum kode baru mulai melayani trafik sungguhan.

Migrasi adalah langkah paling berisiko — perlakukan dengan hati-hati

Sebagian besar langkah deployment aman untuk dibatalkan: kalau kode baru berulah, kamu kembalikan kode lama. Perubahan database itu beda. Hapus satu kolom dan data di dalamnya lenyap — mengembalikan kode tidak akan membawanya kembali. Itulah kenapa tim yang berhati-hati menulis migrasi supaya bersifat menambah bila memungkinkan (tambah kolom baru, isi, alihkan, lalu hapus yang lama nanti di deploy terpisah), dan selalu mem-backup sebelum perubahan berisiko. Waktu sebuah deployment kacau parah, biang keroknya biasanya migrasi, bukan kodenya.

6. Switch: arahkan trafik ke versi baru

Sampai sekarang, versi lama aplikasimu diam-diam terus melayani pengguna selama ini. Switch adalah momen server mulai memakai versi baru sebagai gantinya. Seberapa mendadak ini terjadi tergantung susunanmu. Pendekatan paling sederhana menghentikan versi lama lalu menyalakan yang baru — cepat, tapi ada kedipan saat aplikasi sempat mati. Susunan yang lebih hati-hati menyalakan versi baru berdampingan dengan yang lama, memastikan dia sehat, dan baru setelah itu mengalihkan trafik ke sana, supaya pengguna tidak pernah melihat gangguan.

   SEBELUM SWITCH           SESUDAH SWITCH
   ──────────────           ──────────────
   trafik ──► v1 (lama)     trafik ──► v2 (baru)
              v2 (pemanasan) v1 (ditahan sebentar,
                              lalu dimatikan)

Pola kedua itu — nyalakan yang baru, buktikan dia jalan, lalu pindahkan — adalah inti dari yang orang sebut deploy “tanpa downtime”. Versi lama sering dibiarkan tetap hidup beberapa menit supaya kamu bisa melompat balik dengan cepat kalau yang baru berulah.

7. Verify: pastikan dia benar-benar jalan

Deploy belum selesai waktu versi baru menyala — dia selesai waktu kamu sudah memastikan dia sehat. Verifikasi bisa sesederhana membuka situs dan mengklik-klik, atau seotomatis sebuah health check: server (atau alat monitoring) menembak sebuah URL khusus yang menjawab “ya, saya hidup dan berfungsi”. Kalau cek itu gagal, pipeline yang baik bisa otomatis kembali ke versi terakhir yang diketahui bagus alih-alih membiarkan aplikasi rusak tetap live.

# Health check sering cuma endpoint kecil yang mengembalikan "OK"
curl https://aplikasi-kamu.example.com/health
# → {"status":"ok"}

Melewatkan verifikasi adalah cara sebuah deploy yang “sukses” diam-diam menjatuhkan situs selama satu jam sebelum ada yang sadar. Deploy-nya jalan; tidak ada yang mengecek. Selalu tutup lingkarannya.

Contoh utuh, dari awal sampai akhir

Ayo kita rangkai semuanya lewat cerita yang konkret tapi tetap umum. Tim di ACY Partner Indonesia punya sebuah aplikasi web dan Jane Doe baru saja menyelesaikan sebuah fitur. Inilah yang terjadi waktu dia mendeploy-nya.

1. BUILD     Kode Jane dikompilasi dan dibundel jadi file yang dioptimalkan.
             Salah ketik yang tersisa akan gagal di sini — ternyata tidak. ✓

2. PACKAGE   Output dikumpulkan jadi satu artifact (app-v2.tar.gz).

3. TRANSFER  Artifact disalin ke server production lewat SSH.

4. INSTALL   Di server, dependency dipasang dari daftar terkunci, persis
             sama dengan yang sudah diuji.

5. MIGRATE   Satu migrasi kecil menambah kolom "last_login". Di-backup
             dulu, untuk berjaga-jaga.

6. SWITCH    Versi baru menyala berdampingan dengan yang lama. Begitu dia
             menjawab sehat, trafik dipindahkan. Versi lama tinggal 5 menit.

7. VERIFY    Health check lolos dan Jane membuka situsnya sendiri.
             Hijau di mana-mana. Versi lama dimatikan.

Perhatikan apa yang tidak terjadi: tidak ada yang mengirim-kirim file lewat email, tidak ada yang mengedit kode langsung di server live, dan tidak ada satu titik pun di mana aplikasi mati total tanpa cadangan. Disiplin itulah — artifact yang bisa diulang, langkah yang berurutan, dan jalan untuk kembali — yang membedakan deploy yang tenang dari yang bikin deg-degan.

Bagaimana otomasi menjalankan langkah ini untukmu

Melakukan semua itu dengan tangan, tiap kali, bakal melelahkan dan rawan salah — dan manusia cenderung melewatkan langkah waktu lelah. Jadi tim mengotomasi pipeline-nya. Kamu menyambungkan repository kodemu ke sebuah sistem yang mengawasi perubahan, dan begitu kamu mendorong kode baru, sistem itu menjalankan tahapan di atas secara otomatis: build, test, package, deploy, verify. Inilah ide di balik CI/CD (continuous integration / continuous delivery).

   kamu push kode
        │
        ▼
   ┌──────────────────────────────────────────┐
   │  PIPELINE OTOMATIS                         │
   │  build → test → package → deploy → verify  │
   └──────────────────────────────────────────┘
        │
        ▼
   live, atau otomatis di-rollback kalau ada langkah gagal

Pergeseran cara pandang yang krusial: otomasi tidak menggantikan tahapan, dia menjalankan tahapan yang sama dengan andal. Setiap konsep di atas tetap berlaku. Pipeline cuma asisten tak kenal lelah yang melakukan urutan persis itu dengan cara yang sama setiap kali, menolak melanjutkan kalau ada langkah gagal, dan bisa membatalkan pekerjaannya sendiri waktu verifikasi tidak lolos. Itu sebabnya “di mesin saya jalan kok” jadi kurang relevan di pipeline yang baik — mesin yang mem-build dan menguji selalu mesin yang sama, bukan laptopmu.

Tahapan yang sama bersembunyi di balik platform sekali-klik

Platform hosting modern bisa membuat deployment terasa seperti satu tombol atau satu git push. Itu pengalaman yang menyenangkan, tapi ada baiknya kamu tahu itu bukan sihir — di balik tombol itu, platform sedang menjalankan tahapan yang ada di artikel ini juga. Waktu ada yang salah, log platform bakal menyebut build yang gagal, install yang error, health check yang timeout. Kamu sudah tahu arti kata-kata itu, jadi kamu tahu harus melihat ke mana.

Rollback: tombol undo

Pipeline yang bisa mendeploy juga sebaiknya bisa membatalkan deploy. Rollback adalah kembali ke versi terakhir yang bekerja waktu versi baru ternyata rusak. Karena kamu sudah mengemas tiap versi sebagai artifact-nya sendiri dan menyimpan yang lama, rollback sering secepat mengarahkan trafik lagi ke versi sebelumnya — langkah switch, dijalankan terbalik.

Justru inilah kenapa pola hati-hati tadi terbayar. Membiarkan versi lama hidup beberapa menit, menulis migrasi yang sifatnya menambah, membangun artifact yang tidak berubah — semua itu bukan kerja sia-sia. Semuanya demi satu kalimat tenang yang ingin bisa kamu ucapkan waktu sebuah deploy bermasalah: “santai, balikin saja.” Proses deployment yang tidak bisa kamu batalkan adalah proses yang mengubah kesalahan kecil jadi gangguan panjang.

Kenapa memahami tahapan ini berguna buatmu

Mungkin sekarang kamu pakai platform yang mengurus semua ini untukmu, dan itu bagus. Tapi memahami tahapannya tetap terus terbayar. Waktu sebuah deploy gagal, kamu bakal membaca error-nya dan langsung tahu apakah ini masalah build, masalah migrasi, atau masalah health check — dan itu memberitahumu di mana harus memperbaikinya. Waktu memilih alat, kamu bakal paham apa sebenarnya yang sedang mereka otomasikan. Dan waktu nanti kamu mendeploy sesuatu dengan cara susah, di server polos, langkah-langkahnya tidak bakal mengagetkan, karena kamu sudah melihat bentuknya di sini.

Deployment berhenti jadi kotak hitam begitu kamu bisa menyebut apa isinya. Dia bukan satu lompatan — dia build, package, transfer, install, migrate, switch, verify, dengan rollback yang menunggu kalau-kalau kamu membutuhkannya. Setiap alat yang bakal kamu pakai cuma susunan dari ide-ide yang sama itu.

Penutup

Ini semuanya dalam satu tempat:

Deployment itu pipeline, bukan satu momen — kode mengalir lewat tahapan berurutan, dan kegagalan terjadi di satu tahap yang bisa dikenali.
Tahapan universalnya adalah: build (kode sumber → siap jalan), package (satu artifact rapi), transfer (pindahkan ke server), install (dependency + runtime), migrate (update database), switch (arahkan trafik ke versi baru), dan verify (pastikan dia sehat).
Migrasi adalah tahap paling berisiko karena perubahan data tidak selalu bisa dibatalkan — backup dulu dan utamakan perubahan yang sifatnya menambah.
Tanpa downtime datang dari menyalakan versi baru berdampingan dengan yang lama, membuktikan dia sehat, baru memindahkan trafik.
Otomasi (CI/CD) tidak menggantikan tahapan ini — dia menjalankan tahapan yang sama dengan andal setiap kali, dan bisa otomatis rollback waktu ada langkah gagal.
Rollback adalah tombol undo, dan dia hanya bekerja kalau prosesmu memang dirancang untuk membolehkannya.

Berikutnya, ada baiknya kamu lihat bagaimana tahapan ini berbeda tergantung apa yang kamu kirim — sebuah folder berisi file statis berperilaku sangat beda dari sebuah proses server yang berjalan terus, dan mengetahui mana yang kamu punya bakal mengubah hampir setiap langkah di atas.