Capgo Praktik Terbaik Lingkungan: Staging dengan Satu ID Aplikasi Mobile

Tim biasanya 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

The first two can work, but they create long-term friction. In real teams, the Capgo channel model is usually the cleanest.

Mengapa ID aplikasi duplikat menjadi bising

Menggunakan com.myapp dan com.myapp.beta terlihat sederhana, tapi Anda cepat mendapatkan duplikasi:

• Dua alur rilis
• Dua set ID push, tautan dalam, dan pemetaan hak
• Dua identitas analitis dan crash
• 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 “ID aplikasi + switch runtime” biasanya berarti aplikasi membaca variabel lingkungan atau flag pada startup dan mengarahkan API, kunci, dan perilaku pembaruan secara dinamis.

Hal ini berfungsi hingga:

• QA mulai menghindari alur yang dimaksud karena status pengaturan sudah ketinggalan zaman,
• seseorang menggunakan endpoint yang salah di produksi,
• drift lingkungan menyebabkan bug yang sulit direproduksi,
• anda perlu debug “apa versi pengaturan ini menggunakan?” di perangkat pengguna.

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

Cara Capgo : satu ID aplikasi, banyak saluran

Capgo membuat kontrol lingkungan eksplisit melalui saluran:

• Pertahankan satu ID aplikasi produksi di App Store / Play.
• Kirim satu biner native untuk "shell" (sampai perubahan native memerlukan rebuild yang benar).
• Tentukan perilaku routing oleh saluran, bukan oleh identitas aplikasi yang diulang.

Dalam prakteknya, ini berarti:

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

Aplikasi pengujian internal Anda / Play dapat tetap pada staging selamanya. Anda dapat melakukan pembaruan JS/CSS/asset secara berulang di sana melalui Capgo tanpa menerbitkan aplikasi native baru.

Struktur yang direkomendasikan dalam praktek

1) Basis rilis native

Binari native terakhir Anda tetap sama untuk banyak iterasi JS:

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

Hanya bangun kembali binari native ketika Anda benar-benar mengubah area permukaan native.

2) Gunakan saluran dedikasi untuk lingkungan

Publikasikan update dengan saluran:

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

Jalankan 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, hal ini berarti build TestFlight Anda dapat tetap terkait dengan update pre-produksi:

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

4) Gunakan perubahan saluran hanya untuk alur kerja yang dikendalikan

Untuk tim lanjut, terbuka saluran switch yang dikendalikan untuk pengguna QA/admin:

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

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

Ini optional. Tim kebanyakan menggunakan pengaturan saluran dari dashboard dan hanya mengganti saluran untuk pengguna internal, bukan semua pelanggan.

Daftar tugas operasional

• ID aplikasi hanya satu (tidak ada ID produksi/double staging)
• Pipelining bangunan asli native satu
• Peta saluran yang dokumentasi (staging, beta, production, hotfix)
• Jalur promosi diaktifkan di CI/CD
• Rebuild native hanya pada perubahan native yang benar
• Rollback diuji secara teratur

Manfaat praktis

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

• QA mendapatkan binary yang realistis (tidak ada identitas “aplikasi staging” palsu),
• path Anda di TestFlight tetap stabil,
• tim Anda menghindari "utang ID aplikasi dua,"
• Anda dapat menerapkan banyak perbaikan JS hanya melalui Capgo dengan cepat.

Hasilnya adalah penggajalan yang lebih sederhana: lebih sedikit artefak, telemetri yang lebih bersih, dan lebih sedikit kejutan dalam operasi rilis.

Teruskan dari Capgo Best Practices Lingkungan: Staging dengan Satu ID Aplikasi Mobile

Jika Anda menggunakan Capgo Best Practices Lingkungan: Staging dengan Satu ID Aplikasi Mobile untuk merencanakan routing saluran dan peluncuran yang dipersiapkan, hubungkannya dengan Channels untuk detail implementasi di Channels, Channels untuk detail implementasi di Channels, Saluran untuk detail implementasi di Saluran, Pengujian Beta untuk alur kerja produk di Pengujian Beta, dan Pengaturan Target Versi untuk alur kerja produk di Pengaturan Target Versi.