Capgo Praktik Lingkungan Terbaik: Staging dengan Satu ID Aplikasi Mobile

Biasanya tim memilih salah satu dari tiga pendekatan untuk lingkungan mobile:

1. Dua ID aplikasi (produksi + pra-produksi)
2. Satu ID aplikasi + switching lingkungan runtime dinamis
3. Satu ID aplikasi + Capgo saluran

Dua-duanya dapat berfungsi, tetapi mereka menciptakan gesekan jangka panjang. Dalam tim nyata, model kanal Capgo biasanya adalah yang paling bersih.

Mengapa ID aplikasi yang diulang menjadi berisik

Menggunakan com.myapp dan com.myapp.beta terlihat sederhana, tetapi Anda segera mendapatkan duplikasi:

• Dua jalur rilis
• Dua set ID push, tautan dalam, dan pemetaan hak istimewa
• Dua analisis dan identitas kegagalan
• Konfigurasi yang berbeda dan perilaku yang tidak konsisten antara lingkungan

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

Mengapa pengaturan waktu eksekusi sering kali berantakan

Polanya "satu ID aplikasi + switch waktu eksekusi" biasanya berarti aplikasi Anda membaca variabel lingkungan atau flag pada startup dan mengarahkan API, kunci, dan perilaku pembaruan secara dinamis.

Ini berfungsi hingga:

• Pengujian kualitas memulai menghindari alur yang dimaksud karena kondisi konfigurasi sudah ketinggalan zaman,
• seseorang menggunakan endpoint yang salah di produksi,
• perubahan lingkungan menyebabkan bug yang sulit untuk direproduksi,
• anda perlu mengdebug “versi konfigurasi apa yang digunakan oleh binary ini?” di perangkat pengguna.

Kompleksitas ini bertumbuh dengan setiap rilis dan di mana tim kehilangan kecepatan.

Cara Capgo : satu ID aplikasi, banyak saluran

Capgo membuat kendali lingkungan eksplisit melalui saluran:

• Tetapkan satu ID aplikasi produksi di App Store / Play.
• Kirimkan satu binary native untuk “shell” (sampai perubahan native memerlukan rebuild yang benar).
• Rutekan perilaku oleh saluran, bukan oleh identitas aplikasi yang diulang.

Dalam prakteknya, ini berarti:

• production: semua pengguna
• staging: kandidat rilis internal dan QA
• beta: tester yang diundang
• hotfix: jalur pembaruan darurat

Aplikasi pengujian internal Anda di TestFlight/Play dapat tetap ada selamanya. Anda dapat melakukan pembaruan JS/CSS/asset secara berulang melalui __CAPGO_KEEP_0__ tanpa harus menerbitkan aplikasi native baru. staging forever. You do JS/CSS/asset updates there repeatedly through Capgo without publishing a new native app.

1) Basis rilis native

Binary native terakhir Anda tetap sama untuk banyak iterasi JS:

Anda hanya membangun kembali binary native ketika Anda benar-benar mengubah area permukaan native.

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

2) Gunakan saluran dedikasi untuk lingkungan

Publikasikan pembaruan dengan menggunakan saluran:

2) Gunakan saluran dedikasi untuk lingkungan

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

Tes di QA, perbaiki masalah, lalu promosikan:

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

Jika Anda lebih suka versi eksplisit:

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

3) Simpan TestFlight “selalu pre-prod”

Dalam alur kerja iOS, ini berarti build TestFlight Anda dapat tetap terkait dengan pembaruan pre-produksi:

• Tidak ada pengiriman native yang sering untuk setiap perubahan JS.
• QA selalu memvalidasi code yang mirip produksi melalui saluran staging.
• Pengguna produksi hanya menerima paket saluran produksi yang dipromosikan.

4) Gunakan switching saluran hanya untuk alur kerja yang dikendalikan

Untuk tim yang lebih maju, tunjukkan switch saluran yang dikendalikan untuk pengguna QA/admin:

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

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

Ini adalah opsional. Banyak tim menggunakan pengaturan saluran dari dashboard dan hanya mengganti saluran untuk pengguna internal, bukan semua pelanggan.

Daftar tugas operasional

• Satu ID aplikasi saja (tidak ada ID produksi/staging yang duplikat)
• Pipelining bangunan native dasar
• Peta saluran yang dokumentasi (staging, beta, production, hotfix)
• Jalan promosi diatur dalam CI/CD
• Rebuild native hanya pada perubahan native yang sebenarnya
• Rollback diuji secara teratur

Manfaat praktis

Dengan cara ini, kita menghilangkan pergeseran lingkungan, mengurangi perubahan bangunan, dan mempercepat perbaikan:

• QA mendapatkan aplikasi nyata (tidak ada identitas aplikasi “staging” palsu),
• Rute TestFlight Anda tetap stabil,
• Tim Anda menghindari “utang ID aplikasi dua,”
• Anda dapat menerapkan banyak perbaikan JavaScript hanya melalui Capgo dengan cepat.

Hasil akhirnya adalah penggajian yang lebih sederhana: lebih sedikit artefak, telemetri yang lebih bersih, dan lebih sedikit kejutan dalam operasi rilis.