Belajar Backstage - Production Deployment & Adoption

#Pendahuluan

Episode 20 membuat Backstage kalian transparan — setiap sinyal bisa dilihat dan dipantau. Episode 21 ini membawanya keluar dari development menuju lingkungan sungguhan. Di sini kalian mempelajari sisi operasional dan kultural: membungkus Backstage ke dalam Docker image, menggelar dengan Helm chart di Kubernetes, menyusun pipeline CI/CD, menjaga backup dan restore, mengatur strategi upgrade mingguan dengan backstage-cli versions:bump, lalu menutupnya dengan adoption playbook agar tim benar-benar memakai platform.

#Menyiapkan Deployment

Sebelum menggelar, pilih model deployment yang paling cocok dengan infrastruktur kalian:

Dari tiga opsi itu, kombinasi Helm di Kubernetes adalah pilihan yang paling umum untuk deployment production Backstage.

#Docker Image

Backstage bisa dibungkus dengan Docker multi-stage: tahap build menyiapkan dependensi dan output, tahap runtime hanya berisi hasil build dan runtime produksi:

FROM node:20-bookworm-slim AS build
WORKDIR /app
COPY package.json ./
COPY packages ./packages
RUN yarn install --frozen-lockfile --network-timeout 600000
RUN yarn backstage-cli repo build
 
FROM node:20-bookworm-slim
WORKDIR /app
COPY --from=build /app/packages/backend/dist ./packages/backend/dist
ENV NODE_ENV=production
EXPOSE 7007
CMD ["node", "packages/backend"]

Image yang dihasilkan kecil dan hanya berisi yang dibutuhkan runtime. Tag image dengan versi rilis — bukan hanya latest — agar rollback selalu mungkin.

#Helm Chart di Kubernetes

Backstage menyediakan Helm chart resmi di repositori backstage/charts. Dengan chart, deployment, service, ingress, dan koneksi database dikelola secara declarative. Gambaran nilai yang umum disetel:

backstage:
  image:
    repository: registry.internal/backstage
    tag: 1.53.0
  replicaCount: 3
  appConfig:
    app:
      baseUrl: https://backstage.example.com
    backend:
      baseUrl: https://backstage.example.com
      database:
        client: pg
        connection:
          host: postgres.internal
          password: ${POSTGRES_PASSWORD}
 
ingress:
  enabled: true
  className: nginx
  hosts:
    - host: backstage.example.com

Konfigurasi rahasia seperti password database sebaiknya diambil dari Kubernetes Secrets atau vault, bukan ditulis mentah di chart. Deployment:

helm repo add backstage https://backstage.github.io/charts
helm repo update
helm upgrade --install backstage backstage/backstage \
  --namespace backstage \
  --values values.yaml

#CI/CD Pipeline

Pipeline CI/CD yang baik membawa perubahan dari commit ke production secara otomatis dan dapat diaudit. Alurnya kira-kira:

stages:
  - lint
  - test
  - build
  - docker-push
  - helm-upgrade
  - smoke-test

Urutannya: lint dan test dijalankan pertama untuk menjaring kesalahan, lalu build image dan push ke registry, dilanjutkan dengan helm upgrade --install ke staging, dan terakhir smoke test untuk memastikan instance baru sehat sebelum meneruskan ke production.

#Backup dan Restore

State Backstage yang paling berharga ada di PostgreSQL: entitas catalog, data plugin, dan sesi. Entitas sumber berada di repositori git, tetapi data runtime tetap perlu dicadangkan.

Strategi backup yang wajar:

• Backup database berkala — dump PostgreSQL sesuai interval yang disepakati.
• Backup konfigurasi — simpan file konfigurasi, chart values, dan Secrets sebagai kode.
• Latih restore — uji prosedur restore secara berkala, bukan hanya saat terjadi bencana.

Contoh backup database:

pg_dump -h postgres.internal -U backstage -d backstage \
  -F custom -f backstage-$(date +%Y%m%d).dump

#Strategi Upgrade

Backstage dirilis mingguan — setiap pekan ada versi baru. Mengikuti rilis secara rutin adalah cara paling aman untuk menjaga keamanan dan kompatibilitas. Alat kuncinya adalah backstage-cli versions:bump, yang memperbarui semua dependensi Backstage ke versi terbaru secara konsisten.

backstage-cli versions:check
backstage-cli versions:bump

Strategi yang disarankan:

• Periksa rilis dan changelog sebelum menabrak.
• Jalankan versions:bump di cabang terpisah dan uji di staging dulu.
• Tetapkan ritme — misalnya dua minggu sekali — agar jarak antar upgrade tidak melebar.
• Selesaikan security fix secepatnya, bukan menunggu jadwal berikutnya.

#Adoption Playbook

Deployment hanyalah setengah dari pekerjaan. Setengah lainnya adalah membuat tim mau dan mampu memakai Backstage.

#Golden Path Pertama

Mulailah dengan golden path: satu jalur standar yang diinginkan untuk semua service baru. Wujudkan sebagai template scaffolder yang mengikutkan ownership, dokumentasi, CI, dan security default yang benar. Ketika golden path dipakai, kualitas naik tanpa perlu memaksa — karena jalur yang benar adalah yang paling mudah.

#Onboarding Tim

Onboarding tidak cukup dengan satu email. Siapkan dokumentasi internal, workshop singkat, dan contoh nyata. Tunjuk champion per tim yang bisa menjawab pertanyaan awal dan menjadi penghubung ke tim platform. Semakin cepat tim merasakan manfaat — membuat service baru dalam hitungan menit — semakin cepat adopsi tumbuh.

#Pengukuran Adopsi

Apa yang tidak diukur tidak bisa diperbaiki. Beberapa metrik yang praktis:

• Jumlah entitas terdaftar dan yang punya owner aktif.
• Pemakaian scaffolder: berapa template dipakai, berapa service dibuat per bulan.
• Pemakaian search dan TechDocs: berapa pencarian dan pembacaan dokumentasi.
• Analytics events (dari episode 20) untuk melihat alur pemakaian nyata.

#Roadmap Internal Platform

Platform engineering bukan proyek sekali selesai. Susun roadmap internal yang jelas — golden path berikutnya, plugin baru, integrasi security, dan perbaikan UX — dengan pemilik dan tenggat yang nyata. Roadmap inilah yang menjaga platform tetap hidup dan relevan seiring pertumbuhan organisasi.

#Penutup

Pada episode 21 ini, kalian memahami production deployment Backstage: Docker image multi-stage, Helm chart di Kubernetes, pipeline CI/CD, backup dan restore database, serta strategi upgrade mingguan dengan backstage-cli versions:bump. Kalian juga belajar adoption playbook: golden path pertama, onboarding tim, pengukuran adopsi, dan roadmap internal platform.

Inti yang harus dibawa pulang:

• Helm di Kubernetes adalah default production — declarative, scalable, dan reproducible.
• Backup dan restore harus diuji — cadangan yang tidak pernah direstorasi hanyalah harapan.
• Upgrade kecil dan rutin menang — rilis mingguan diikuti dengan backstage-cli versions:bump agar tidak menumpuk.
• Adopsi adalah pekerjaan kultural — golden path, onboarding, dan pengukuran membuat platform benar-benar dipakai.

Di episode 22, sebagai episode terakhir series ini, kita melihat ke depan: ekosistem modern & refleksi akhir. Kalian akan mengenal fitur Backstage 2026 seperti New Frontend System default dan MCP integration untuk AI agents, membandingkan Backstage dengan alternatif komersial, merangkum seluruh perjalanan dari episode 0 sampai 21, dan menyusun checklist production-grade untuk platform kalian.