Template Deployment yang Benar-Benar Dipakai

Setiap tim pasti punya cerita tentang deployment yang gagal karena seseorang lupa satu langkah. Mungkin artifact build tidak pernah didorong ke registry. Mungkin smoke test dilewati karena "ini cuma perubahan kecil." Mungkin rencana rollback sudah dibahas di rapat tapi tidak pernah ditulis, dan ketika terjadi masalah, tidak ada yang sepakat harus berbuat apa.

Masalah-masalah ini bukan tentang kemampuan. Ini tentang proses. Ketika tekanan meningkat—insiden produksi, tenggat waktu ketat, manajer yang terus menanyakan progres—orang mulai melewatkan langkah. Bukan karena mereka ingin, tapi karena tidak ada checklist yang jelas untuk diikuti.

Template deployment menjawab masalah ini. Ini bukan dokumen birokrasi. Ini adalah jaring pengaman.

Apa yang Dilakukan Template Deployment

Template deployment adalah daftar langkah yang harus dijalankan setiap kali Anda mendorong versi baru aplikasi ke environment mana pun. Template ini tidak memberi tahu cara bekerja. Ia memberi tahu apa yang tidak boleh dilupakan.

Template ini berlaku untuk backend API, aplikasi web, dan background worker. Detail teknisnya berbeda—satu tim menggunakan Docker image, tim lain menggunakan binary hasil kompilasi—tapi strukturnya tetap sama. Struktur itu memiliki empat fase: build dan verifikasi, deploy ke staging, deploy ke produksi, dan menyiapkan rencana rollback.

Diagram di bawah menunjukkan keempat fase dan bagaimana mereka terhubung, termasuk feedback loop ketika suatu fase gagal.

flowchart TD A[Build dan Verifikasi] -->|lolos| B[Deploy ke Staging] A -->|gagal| A B -->|lolos| C[Deploy ke Produksi] B -->|gagal| A C -->|lolos| D[Rencana Rollback] C -->|gagal| D D -->|rollback dipicu| A D -->|tidak rollback| E[Deployment Selesai]

Fase Satu: Build dan Verifikasi

Sebelum kode Anda pergi ke mana pun, Anda perlu membuktikan bahwa kode itu benar-benar berjalan. Fase ini adalah tempat sebagian besar tim sudah memiliki otomatisasi, tapi template memastikan tidak ada yang terlewat.

Langkah-langkahnya sederhana:

Berikut adalah workflow GitHub Actions yang mengimplementasikan Fase Satu untuk aplikasi Node.js:

name: Build and Verify
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test
      - run: npm run build
      - name: Push Docker image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker tag myapp:${{ github.sha }} registry.example.com/myapp:${{ github.sha }}
          docker push registry.example.com/myapp:${{ github.sha }}

Workflow ini dipicu setiap ada push ke main, menjalankan tes, membangun aplikasi, dan mendorong Docker image ke registry. Jika ada langkah yang gagal, deployment berhenti secara otomatis.

  • Check out kode dari branch yang benar. Bukan branch yang Anda kira benar. Yang benar-benar sudah diverifikasi.
  • Jalankan proses build. Ini menghasilkan artifact—Docker image, file JAR, binary hasil kompilasi, apa pun yang digunakan stack Anda.
  • Jalankan unit test dan integration test. Ini memastikan kode berperilaku sesuai harapan dan semua bagian terhubung dengan baik.
  • Periksa error dan warning yang bisa menghentikan proses. Build yang lolos dengan warning tetaplah build yang lolos, tapi beberapa warning menandakan masalah serius.
  • Dorong artifact ke registry yang bisa diakses oleh environment target Anda. Jika artifact tidak disimpan, Anda tidak bisa mendeploynya nanti.

Jika ada langkah dalam fase ini yang gagal, deployment berhenti. Anda perbaiki kode dan mulai lagi. Tidak ada pengecualian.

Fase Dua: Deploy ke Staging

Staging adalah ruang latihan Anda. Environment ini mencerminkan produksi semirip mungkin, tapi tidak pernah disentuh pengguna nyata. Di sinilah Anda menangkap masalah yang tidak bisa ditemukan oleh tes—ketidakcocokan konfigurasi, bug spesifik environment, masalah integrasi dengan layanan yang hanya ada di setup mirip produksi.

Langkah-langkah di sini meliputi:

  • Tarik artifact dari registry. Gunakan artifact yang persis sama dengan yang lolos fase satu.
  • Deploy ke environment staging. Ini harus menggunakan mekanisme deployment yang sama dengan yang akan digunakan di produksi.
  • Jalankan smoke test. Ini adalah pemeriksaan cepat untuk memastikan aplikasi merespons request, terhubung ke database, dan berkomunikasi dengan dependensinya.
  • Periksa log untuk error yang tidak terduga. Aplikasi yang sehat menghasilkan log yang bisa diprediksi. Apa pun yang tidak biasa layak diselidiki.
  • Jalankan integration test yang membutuhkan environment lengkap. Beberapa tes hanya masuk akal ketika seluruh sistem berjalan.

Jika semuanya terlihat baik, Anda lanjut ke fase berikutnya. Jika ada yang rusak, Anda kembali ke fase satu, perbaiki kode, build ulang, dan deploy ulang ke staging.

Fase Tiga: Deploy ke Produksi

Ini adalah fase kritis. Pengguna nyata bergantung pada aplikasi Anda. Kesalahan di sini berdampak pada pekerjaan nyata.

Deployment produksi harus dilakukan secara bertahap. Blue-green deployment, canary releases, atau rolling updates semuanya bisa digunakan. Kuncinya adalah Anda tidak mengganti semuanya sekaligus.

Langkah-langkahnya:

  • Konfirmasi tidak ada deployment lain yang sedang berlangsung. Dua deployment berjalan bersamaan menciptakan kekacauan.
  • Tarik artifact yang sama yang lolos staging. Jangan build ulang. Gunakan artifact yang sudah terverifikasi.
  • Deploy menggunakan strategi yang Anda pilih. Jika menggunakan canary releases, mulai dengan persentase traffic yang kecil.
  • Pantau metrik: response time, error rate, penggunaan CPU, konsumsi memori, throughput request. Angka-angka ini memberi tahu apakah versi baru sehat.
  • Jalankan health check dan smoke test setelah deployment. Ini memastikan aplikasi benar-benar melayani traffic dengan benar.

Jika metrik terlihat salah, jangan menunggu. Picu rollback.

Fase Empat: Rencana Rollback

Setiap deployment butuh cara untuk kembali. Bukan sekadar ide kabur tentang kembali. Tapi rencana konkret yang ditulis sebelum deployment dimulai.

Rencana rollback menjawab tiga pertanyaan:

  • Kapan Anda rollback? Tentukan pemicunya. Contoh: error rate melebihi 5 persen, response time naik 50 persen, atau endpoint kritis berhenti merespons.
  • Bagaimana cara rollback? Sebutkan mekanismenya. Ini bisa berupa mengarahkan traffic ke versi sebelumnya, mendeploy ulang artifact lama, atau menjalankan script pembalikan migrasi database.
  • Siapa yang memutuskan? Tentukan nama atau peran yang berwenang memanggil rollback. Dalam insiden, menunggu konsensus hanya membuang waktu.

Tulis rencana rollback. Bagikan dengan tim. Dapatkan persetujuan sebelum Anda memulai deployment produksi.

Checklist Praktis untuk Deployment Aplikasi

Berikut adalah checklist pendek yang bisa Anda adaptasi untuk tim Anda. Ini tidak lengkap, tapi mencakup hal-hal esensial.

Build dan Verifikasi

  • Code checkout dari branch yang sudah diverifikasi
  • Build berhasil
  • Unit dan integration test lolos
  • Artifact didorong ke registry

Deploy ke Staging

  • Artifact ditarik dari registry
  • Deployment selesai tanpa error
  • Smoke test lolos
  • Log tidak menunjukkan error tak terduga

Deploy ke Produksi

  • Tidak ada deployment bersamaan yang berjalan
  • Artifact dari staging digunakan
  • Strategi deployment bertahap diterapkan
  • Metrik dipantau selama 10-15 menit
  • Health check lolos

Rencana Rollback

  • Pemicu rollback ditentukan
  • Mekanisme rollback disebutkan
  • Pengambil keputusan diidentifikasi
  • Rencana dibagikan dan disetujui sebelum deployment

Adaptasi Template untuk Tim Anda

Tim yang baru memulai mungkin menggunakan versi sederhana: build, deploy ke staging, deploy ke produksi, rollback. Tim yang matang mungkin menambahkan security scan, performance test, atau approval gate di setiap fase.

Yang penting bukanlah berapa banyak langkah yang Anda sertakan. Tapi bahwa Anda menggunakan template secara konsisten. Template yang disimpan di wiki yang tidak pernah dibaca tidak berguna. Template yang tertanam di pipeline deployment Anda, ditinjau sebelum setiap rilis, dan diperbarui ketika Anda belajar sesuatu yang baru—itulah yang membuat deployment lebih aman.

Kesimpulan

Template deployment ada karena ingatan tidak bisa diandalkan, terutama di bawah tekanan. Tulis langkah-langkahnya. Bagikan. Gunakan setiap kali. Ketika sesuatu salah, Anda akan tahu persis apa yang harus dilakukan—dan begitu juga semua orang di tim Anda.