Praktik Terbaik Environment Capgo: Staging dengan Satu Mobile App ID

Tim biasanya memilih salah satu dari tiga pendekatan untuk lingkungan mobile:

Dua app ID (produksi + pra-produksi)
Satu app ID + pengalihan lingkungan runtime dinamis
Satu app ID + channel Capgo

Dua opsi pertama bisa berjalan, tapi menimbulkan friksi jangka panjang. Di tim nyata, model channel Capgo biasanya paling rapi.

Mengapa duplikasi app ID bikin repot

Menggunakan com.myapp dan com.myapp.beta kelihatannya simpel, tapi cepat berujung duplikasi:

Dua pipeline rilis
Dua set push ID, deep link, dan pemetaan entitlement
Dua identitas analytics dan crash
Konfigurasi berbeda dan perilaku tidak konsisten antar environment

Anda akhirnya mengelola dua produk di berbagai konsol store, tim, dan instruksi QA internal.

Mengapa konfigurasi runtime-switching sering berantakan

Pola “satu app ID + runtime switch” biasanya berarti aplikasi Anda membaca environment variables atau flag saat startup, lalu mengarahkan ulang API, key, dan perilaku update secara dinamis.

Cara ini berfungsi sampai:

QA mulai melewati alur yang direncanakan karena state config sudah usang,
seseorang menggunakan endpoint yang salah di production,
environment drift menyebabkan bug yang sulit direproduksi,
Anda perlu debug "versi config apa yang digunakan binary ini?" di perangkat pengguna.

Kompleksitas ini bertambah dengan setiap release, dan di situlah tim kehilangan kecepatan.

Cara Capgo: satu app ID, banyak channel

Capgo membuat kontrol environment eksplisit lewat channel:

Pertahankan satu app ID produksi di App Store / Play.
Rilis satu binary native untuk “shell” (sampai perubahan native memerlukan rebuild penuh).
Arahkan perilaku berdasarkan channel, bukan identitas aplikasi yang diduplikasi.

Dalam praktiknya, ini berarti:

production: semua pengguna
staging: QA internal dan kandidat rilis
beta: penguji yang diundang
hotfix: jalur patch darurat

Aplikasi pengujian internal TestFlight/Play Anda bisa tetap aktif staging selamanya. Anda bisa update JS/CSS/aset di sana berulang kali lewat Capgo tanpa menerbitkan aplikasi native baru.

Struktur yang direkomendasikan dalam praktik

1) Baseline rilis native

Binary native terakhir Anda tetap sama selama banyak iterasi JS:

bun run build
bunx cap sync
# generate Xcode/Android Studio archives as usual

Anda hanya perlu rebuild binary native saat benar-benar ada perubahan di sisi native.

2) Gunakan channel khusus tiap environment

Publikasikan update dengan channel:

bun run build
bunx @capgo/cli deploy --channel staging

Uji di QA, perbaiki masalah, lalu promosikan:

bunx @capgo/cli promote vX.Y.Z --channel production

Jika Anda lebih suka versioning eksplisit:

bunx @capgo/cli deploy vX.Y.Z --channel staging
bunx @capgo/cli promote vX.Y.Z --channel production

3) Jaga TestFlight tetap “always pre-prod”

Dalam workflow iOS, ini berarti build TestFlight Anda dapat tetap terkait dengan update pre-production:

Tidak perlu sering submit native untuk setiap perubahan JS.
QA selalu memvalidasi code yang mendekati produksi melalui channel staging.
Pengguna produksi hanya menerima bundle channel produksi yang sudah dipromosikan.

4) Gunakan switching channel hanya untuk workflow terkontrol

Untuk tim advanced, sediakan switch channel yang terkontrol untuk pengguna QA/admin:

import { CapacitorUpdater } from '@capgo/capacitor-updater';

await CapacitorUpdater.setChannel({
  channel: 'staging',
  triggerAutoUpdate: true
});

Ini opsional. Sebagian besar tim memakai penugasan channel dari dashboard dan hanya beralih channel untuk pengguna internal, bukan semua pelanggan.

Checklist operasional

Hanya satu app ID (tanpa duplikasi ID production/staging)
Satu pipeline build native baseline
Pemetaan channel terdokumentasi (staging, beta, production, hotfix)
Jalur promosi ditegakkan di CI/CD
Native rebuild hanya pada perubahan native nyata
Rollback diuji secara rutin

Manfaat praktis

Pendekatan ini menghilangkan environment drift, mengurangi build churn, dan mempercepat perbaikan:

QA mendapatkan biner yang realistis (tanpa identitas “staging app” palsu),
jalur TestFlight Anda tetap stabil,
tim Anda terhindar dari “hutang dua app ID”,
Anda dapat mendorong banyak perbaikan JS-only melalui Capgo dengan cepat.

Hasil akhirnya adalah tata kelola yang lebih sederhana: lebih sedikit artefak, telemetri yang lebih rapi, dan lebih sedikit kejutan dalam operasi rilis.

Lanjutkan dari Capgo Praktik Terbaik Environment: Staging dengan Satu Mobile App ID

Jika Anda menggunakan Praktik Terbaik Environment Capgo: Staging dengan Satu Mobile App ID untuk merencanakan routing channel dan staged rollout, hubungkan dengan Channel untuk detail implementasi di Channels, Channel untuk detail implementasi di Channels, Channel untuk detail implementasi di Channels, Solusi Beta Testing untuk workflow produk di Solusi Beta Testing, dan Solusi Version Targeting untuk workflow produk di Version Targeting Solution.