Fix Capgo Default Channel Not Updating Devices

Mengubah Cloud Default di __CAPGO_KEEP_0__ Capgo routes brand-new devices right away. Existing installs may stay on their old channel until they check in again, which explains many cases where a Capgo cloud default channel is not updating devices.

Periksa langkah-langkah tersebut secara berurutan. Pastikan pengaturan perangkat terlebih dahulu, lalu periksa pembangunan aplikasi, keadaan sinkron, aturan peluncuran, log, dan pengaturan rollback.

Isi Kandungan

• Langkah 2: Periksa Aplikasi, Runtime Nativ, dan Kompabilitas Update
• Langkah 3: Verifikasi Pengiriman Benar-Benar Mencapai Saluran Default
• Langkah 4: Paksa Sinkronan Baru dan Periksa Log Perangkat
• Langkah 5: Tinjau Aturan Peluncuran, Pintu Versi, dan Pengembalian Otomatis
• Langkah 6: Gunakan Analitik Real-Time untuk Menemukan Titik Gagal yang Tepat
• Langkah 7: Tinjau Aturan Peluncuran, Pintu Versi, dan Pengembalian Otomatis
• Langkah 7: Mencegah Saluran Default dari Mengalami Keterlambatan
• FAQ
• Kesimpulan

Langkah 1: Pastikan Perangkat Terdaftar di Saluran Default

Tujuan adalah menemukan aturan mana yang saat ini memutuskan saluran perangkat. Cloud Default hanya berlaku ketika penugasan yang lebih kuat belum mengklaim perangkat.

Buka dashboard Capgo dan periksa perangkat yang terkena dampak. Periksa saluran saat ini, ID aplikasi, versi, dan waktu pemeriksaan terakhir. Bandingkan nilai-nilai tersebut dengan perangkat yang menerima pembaruan yang diharapkan. Perbandingan ini sering menunjukkan masalah dengan cepat.

Pemilihan saluran mengikuti urutan tertentu. Saluran paksa memiliki prioritas pertama. Saluran dashboard atau API perangkat kemudian datang. Saluran lokal yang ditetapkan oleh aplikasi mengikuti itu. Kemudian Capgo memeriksadefaultChanneldi konfigurasi aplikasi asli. Default Cloud adalah alternatifnya.

Urutan itu berarti perangkat dapat mengabaikan Cloud Default yang berubah tanpa ada kesalahan dashboard. Misalnya, bangun uji coba masih memiliki saluran lokal dari uji coba sebelumnya. Aplikasi tetap menggunakan nilai lokal tersebut sampai Anda menghapusnya.

Pakai Capgo guide pembaruan debugging ketika saluran yang diresolusi kosong atau tidak diharapkan. Ini mencakup kasus di mana aplikasi tidak memiliki default yang dapat digunakan dan perangkat tidak memiliki override.

Langkah berikutnya, periksa konfigurasi Capacitor Anda. Konfigurasi yang umum mungkin mencakup saluran seperti ini:

const config = { plugins: { CapacitorUpdater: { defaultChannel: 'production' } }
}

Field ini tidak wajib. Jika Anda meninggalkannya, perangkat dapat mewarisi Cloud Default. Hal ini dapat berfungsi baik untuk build produksi karena routing saluran tetap di Capgo Cloud. Jika Anda termasuknya, pastikan nilai yang Anda masukkan sesuai dengan saluran yang Anda gunakan.

Sekarang cari pengaturan lokal di aplikasi code. Panggilan kesetChannel()mengubah cache lokal. Namun, tidak akan membuat pengaturan Device Override di backend. Oleh karena itu, dashboard mungkin tidak menampilkan pengaturan override meskipun aplikasi masih menggunakan saluran lokal.

Hapus nilai lokal tersebut ketika perangkat harus kembali ke routing normal. Gunakan metode plugin yang menghapus pengaturan saluran perangkat, atau hapus code yang mengatur saluran dan reinstall aplikasi untuk tes yang bersih.

Kesimpulan Utama: Tidak ada perubahan Cloud Default yang dapat menggantikan pengaturan perangkat, aplikasi, atau saluran lokal yang lebih kuat.

Langkah 2: Periksa Aplikasi, Runtime Asli, dan Kompabilitas Update

context: Halaman/area: Halaman tentang Capgo. Peran: Label UI. Dilihat di: halaman tentang .astro. Kunci pesan `about_how_step_label` (About How Step Label).

Start with the app ID. The app installed on the device must use the same app identity as the project where you uploaded the bundle. A mismatch can look like a channel problem because the device checks the wrong Capgo app.

Bandingkan versi runtime native dengan aturan kompatibilitas bundle. Capgo pembaruan hidup dapat mengubah JavaScript, CSS, dan aset web. Mereka tidak dapat menambahkan plugin native atau mengubah proyek native code setelah aplikasi telah dikirim. Perubahan native masih memerlukan build toko baru.

Pikirkan runtime native sebagai kerangka sekitar web code. Jika bundle baru mengharapkan API native yang tidak dimiliki aplikasi yang terpasang, Capgo tidak boleh menerapkannya. Buat dan unggah versi native yang kompatibel sebelum menguji bundle tersebut.

Periksa versi aplikasi yang terpasang dan platformnya. Uji bundle Android di Android terlebih dahulu. Uji bundle iOS di iOS. Selain itu, pastikan bundle tersebut mengarah ke versi aplikasi yang tepat ketika saluran Anda menggunakan pintu versi.

Setelah mengubahdefaultChannelJalankan perintah sinkron dari root proyek:

npx cap sync

Langkah ini menyalin konfigurasi yang diperbarui ke proyek native. Mengeditcapacitor.configtanpa sinkron akan meninggalkan aplikasi native pada pengaturan saluran lama. Bangun ulang dari proyek native yang ketinggalan akan terus menghasilkan hasil yang sama.

Untuk tes yang bersih, bangun aplikasi baru setelah sinkron. Jangan bergantung pada binary lama yang terinstal di ponsel Anda. Uninstall aplikasi tersebut ketika Anda perlu menghapus status saluran lokal yang disimpan secara lokal, kemudian instal build baru dan periksa saluran lagi.

Saluran Capgo update behavior documentation explains when the updater checks for a bundle. Use that timing when you test. Launch the app or move it back to the foreground, then allow the check to finish before deciding that the update failed.

Periksa juga versi pintas bundel. Bundel dapat ada di saluran yang benar namun tidak tersedia karena versi aplikasi minimumnya tidak sesuai dengan perangkat. Baca detail rilis di dashboard daripada menganggap upload terbaru berlaku untuk setiap instalasi.

Jika aplikasi melewati periksa ini, Anda telah menyempitkan kesalahan. Pertanyaan berikutnya adalah apakah rilis mencapai saluran yang diinginkan secara keseluruhan.

Langkah 3: Verifikasi Pengiriman Benar Mencapai Saluran Default

Tujuan adalah untuk memastikan bahwa bundel ada di saluran yang ditentukan oleh perangkat. Mengunggah bundel ke satu saluran tidak membuatnya tersedia di setiap saluran.

Buka saluran di Capgo Cloud. Periksa bundel aktif, versinya, dan status pengiriman. Bandingkan nama saluran dengan nilai yang dikembalikan oleh aplikasi. Perhatikan perbedaan kecil sepertiproductionatauprod. Nama saluran harus cocok secara tepat.

Jika Anda mengunggah melalui CI/CD, periksa output perintah dari job yang sama yang mengunggah bundel. Pastikan ID aplikasi dan saluran yang dikirimkan ke CLI. Pipa dapat selesai dengan upload sukses sementara mengarah ke saluran pengujian secara tidak sengaja.

Periksa status bundel berikutnya. Rilis draft atau tidak aktif mungkin terlihat di dashboard namun tidak tersedia untuk perangkat. Jika saluran memiliki peluncuran bergulir, perangkat yang terkena mungkin tidak memenuhi aturan peluncuran.

Gunakan satu perangkat uji yang diketahui. Berikan peran yang jelas. Misalnya, pin satu perangkat ke saluran uji dan biarkan perangkat lain tetap pada Cloud Default. Unggah perubahan yang tidak berbahaya, kemudian bandingkan catatan pendaftaran mereka. Ini menghilangkan spekulasi dari tes.

Mesin OTA hidup Capgo dirancang untuk perubahan layer web. Ini dapat memindahkan bundle JavaScript, CSS, atau aset update tanpa menunggu tinjauan toko baru. Kecepatan ini tergantung pada rilis yang aktif di saluran yang tepat yang perangkat cek.

Jika Anda mengubah Cloud Default beberapa saat yang lalu, ingatlah waktu perangkat. Instalasi baru menggunakan rute baru segera. Perangkat yang sudah ada biasanya berganti ketika mereka melakukan cek update berikutnya. Menutup dan membuka aplikasi dapat membantu memicu cek tersebut, tetapi tidak dapat mengatasi saluran yang dipin.

Verifikasi hasilnya di dalam aplikasi. Panggil getChannel()setelah pembaruan dimulai. Catat saluran yang dikembalikan di samping versi aplikasi dan versi bundle. Ini lebih berguna daripada hanya memeriksa dashboard karena menunjukkan apa yang dipercaya perangkat.

Harapkan penundaan jika aplikasi hanya memeriksa pada peluncuran atau latar depan. Jangan tes dengan membuka layar yang tidak pernah memulai pembaruan. Tempatkan cek di jalur startup yang diketahui untuk bangun versi uji singkat, kemudian hapus logging tambahan sebelum rilis.

Jika saluran yang dikembalikan benar tetapi tidak ada bundle yang datang, pindah ke kompatibilitas dan aturan peluncuran. Jika saluran yang dikembalikan salah, kembali ke Langkah 1 dan hapus penugasan yang menang atas Cloud Default.

Langkah 4: Paksa Sinkronisasi Baru dan Inspeksi Log Perangkat-Sisi

Tujuan adalah memisahkan kondisi lokal yang ketinggalan dari masalah pengiriman server. Periksa ulang yang segar memberikan bukti baru.

Terlebih dahulu, pastikan perangkat memiliki akses jaringan. Suatu sesi aplikasi sukses tidak membuktikan bahwa pembarui dapat mencapai endpointnya. Filter korporat, aturan VPN, portal tertangkap, atau sesi yang telah kedaluwarsa dapat menghalangi permintaan pembarui.

Selanjutnya, bawa aplikasi ke latar depan. Tunggu hingga pembarui cek selesai. Jika aplikasi Anda menampilkan acara status pembarui, log acara tersebut bersama dengan saluran saat ini. Hindari hanya mengelogkan “pembarui dimulai.” Anda perlu mengetahui apakah aplikasi menemukan paket, mengunduhnya, memverifikasinya, menginstalnya, atau menolaknya.

Pakai log perangkat Capgo untuk menemukan tahap pertama gagal. Kesalahan pertama biasanya lebih berguna daripada pesan “pembarui gagal” final. Misalnya, kekurangan saluran menunjukkan routing. Penolakan versi native menunjukkan runtime native atau pintu versi.

Reinstal adalah tes yang berguna, tetapi mengubah bukti. Reinstal dapat menghapus status saluran lokal. Gunakan setelah Anda mencapai saluran saat ini dan log, bukan sebelumnya.

Untuk memeriksa ulang, catat nilai-nilai ini dalam satu baris log:

• ID Aplikasi dan versi native aplikasi
• Saluran yang diresolusi darigetChannel()
• Waktu pengecekan pembaruan terakhir
• Versi paket yang ditemukan oleh server
• Hasil instalasi atau penolakan

Catatan kecil itu membantu ketika perangkat milik seorang tester yang tidak dapat mereproduksi masalah tersebut secara langsung. Ini juga memberikan tim CI Anda tanda yang jelas untuk melakukan tes asap otomatis.

Pilih sumber repositori pembaruan resmi Capgo Capacitor ketika Anda membutuhkan untuk memeriksa perilaku plugin API. Terutama, perhatikan perbedaan antara perubahan saluran lokal dan pengaturan perangkat dashboard.

Tips Pro: Tangkap saluran yang diresolusi sebelum Anda menghapusnya. Jika tidak, Anda mungkin memperbaiki status dan kehilangan petunjuk yang menjelaskan gagalnya.

Langkah 5: Tinjau Aturan Rollout, Pintu Versi, dan Rollback Otomatis

Tujuan adalah untuk memeriksa apakah Capgo sengaja menahan atau membalikkan paket. Keterlambatan pembaruan terkadang merupakan aturan keamanan yang bekerja seperti yang direncanakan.

Terbuka pengaturan saluran dan tinjau setiap aturan yang terikat pada rilis. Cari versi aplikasi minimum, pengaturan perbandingan persentase, filter perangkat, dan kondisi yang terkait dengan rilis. Perangkat di luar aturan akan tetap pada paket saat ini bahkan ketika saluran sudah benar.

Periksa juga format versi. Capgo menggunakan versi semantik untuk membandingkan rilis. Jika versi yang terlihat benar bagi manusia masih dapat berperilaku berbeda jika aplikasi atau paket menggunakan format yang tidak terduga. Pastikan format konsisten di antara build asli dan rilis OTA.

Kemudian tinjau perilaku rollback. Rollback otomatis dapat mengembalikan perangkat ke paket sebelumnya setelah tes kesehatan gagal. Dashboard dapat menampilkan code aktif yang lebih tua sementara rilis yang diharapkan tetap ada tetapi tidak tersedia.

Tidak hapus paket yang dicurigai sebelum meninjau eventnya. Penghapusan akan menghilangkan bukti yang berguna. Pertama, catat versi paket, saluran, status perluasan, dan alasan rollback. Kemudian putuskan apakah harus membatalkan rilis atau menerbitkan versi yang sudah terbukti baik.

Pakai saluran yang dipersiapkan untuk perubahan yang berisiko. Kirim paket ke kelompok uji kecil terlebih dahulu. Amati adopsi dan sinyal kesalahan. Setelah rilis berperilaku seperti yang diharapkan, lanjutkan perluasan. Ini akan mencegah perubahan layer web yang buruk mencapai setiap perangkat aktif sekaligus.

Rollback only repairs code that OTA can change. If the failure comes from a missing native plugin or an incompatible native API, you need a new store build. Sending an older JavaScript bundle will not add the native piece that the app lacks.

When you menginspeksi aturan, tanyakan tiga pertanyaan:

• Apakah perangkat ini memenuhi syarat versi aplikasi?
• Apakah perangkat berada di dalam kelompok peluncuran?
• Apakah periksa kesehatan atau aksi manual mengembalikannya ke bundle yang lebih tua?

Capgo berguna di sini karena model saluran yang sama dapat membawa rilis yang dipersiapkan, mendukung rollback, dan menampilkan aktivitas pembaruan dalam satu alur kerja. Simpan set aturan kecil. Kebijakan yang singkat lebih mudah diverifikasi daripada stack kecuali yang dibuat selama insiden.

Jika Anda membutuhkan API-based checks, Capgo dokumentasi publik API menggambarkan sumber daya untuk perangkat, saluran, dan bundle. Gunakan untuk membandingkan pandangan server dengan apa yang dilaporkan oleh aplikasi. Perbandingan tersebut dapat menunjukkan filter dashboard yang ketinggalan zaman atau pengaturan perangkat yang dibuat oleh otomatisasi.

Rollback adalah penghalang, bukan pengganti untuk pengujian. Simpan satu bundle yang diketahui baik di setiap saluran produksi.

Langkah 6: Gunakan Analitik Real-Time untuk Menemukan Titik Gagal yang Tepat

Tujuan adalah untuk menghentikan penggunaan “tidak diperbarui” sebagai satu gagal. Analitik dapat menunjukkan apakah perangkat tidak pernah memeriksa masuk, tidak menemukan paket yang layak, gagal selama download, atau kembali ke versi sebelumnya.

Mulai dengan kelompok perangkat yang terkena dampak. Filter berdasarkan versi aplikasi, platform, saluran, dan versi paket. Cari pola. Jika hanya satu versi aplikasi lama yang gagal, masalah mungkin adalah pintu gerbang kompatibilitas native. Jika semua perangkat di satu saluran gagal, periksa saluran atau pengiriman.

Bandingkan adopsi waktu. Garis datar setelah rilis menunjukkan masalah routing atau kelayakan. Naik turun setelah naik menunjukkan kesalahan instalasi atau kembali ke versi sebelumnya. Naik lambat mungkin hanya berarti perangkat belum membuka aplikasi.

Pakai timestamp dengan hati-hati. Waktu acara dashboard mungkin berbeda dengan waktu lokal pengguna. Match acara update dengan waktu periksa terakhir perangkat. Ini membantu ketika seorang tester mengatakan update gagal sebelum aplikasi memeriksa.

Analitik juga membantu Anda menguji perubahan saluran dengan aman. Ubah satu variabel sekaligus. Tahan paket tetap sambil menguji routing. Kemudian tahan routing tetap sambil menguji paket baru. Jika Anda mengubah kedua hal, data tidak dapat menunjukkan perubahan mana yang memperbaiki masalah.

Untuk insiden, simpan set kecil bukti:

• Identifikasi perangkat atau label uji internal
• Saluran yang diperbaiki
• Versi aplikasi native
• Paket yang diharapkan dan paket yang diinstal
• Waktu periksa terakhir
• Acara kembali atau penolakan

Capgo’s tampilan waktu nyata paling berguna ketika proses rilis Anda mengirimkan pembaruan melalui CI/CD. Tugas deploymen dapat mengunggah bundle, sementara langkah monitoring memeriksa apakah perangkat uji melaporkan saluran dan bundle yang diharapkan. Ini mengubah keluhan manual menjadi pintu rilis.

Jaga data analitik terkait dengan rekaman rilis. Tulis referensi komit atau bangun ke dalam catatan deploymen. Ketika dua bundle memiliki label versi yang mirip, referensi bangun memberitahu Anda mana code yang sebenarnya bergerak.

Jika hanya perangkat yang ada sebelumnya gagal setelah perubahan Cloud Default, tunggu mereka untuk memeriksa ulang sebelum mengubah pengaturan lainnya. Instalasi baru adalah kontrol yang berguna. Ini memberitahu Anda apakah jalur default berfungsi untuk perangkat yang tidak memiliki state lokal lama.

Langkah 7: Mencegah Saluran Default Mengalami Keterlambatan

Tujuan kami adalah membuat drift channel terlihat sebelum mempengaruhi pengguna. Checklist rilis kecil dapat mencegah kasus yang sering terjadi.

Pilih satu model routing untuk setiap lingkungan aplikasi. Untuk produksi, Anda mungkin mengabaikandefaultChanneldan biarkan Capgo mengontrol saluran default secara cloud. Untuk bangun uji, Anda mungkin menetapkan saluran eksplisit. Konfigurasi berbahaya adalah campuran override lokal lama, konfigurasi native yang ketinggalan zaman, dan saluran Cloud Default baru yang tidak diverifikasi.

Masukkannpx cap syncke dalam jalur bangun setelah perubahan konfigurasi. Buat bangun gagal jika langkah sinkronisasi gagal. Perintah ini sederhana, tetapi melewatinya dapat membuat saluran kemarin masuk ke dalam biner native hari ini.

Tambahkan tes asap setelah deploymen. Perangkat uji harus meluncurkan aplikasi, menghubungigetChannel()Periksa apakah paket yang diharapkan sudah tersedia, dan catat hasilnya. Verifikasi sering kali menjadi langkah yang terlewat dalam alur kerja OTA. Mengunggah saja tidak membuktikan banyak hal.

Jaga saluran lokal code di balik flag fitur yang jelas. Jika asisten uji coba memanggilsetChannel()Pastikan build produksi tidak termasuk dalamnya secara tidak sengaja. Ingatlah bahwa cache lokal mungkin tidak muncul sebagai override dashboard, sehingga UI tidak dapat menangkap setiap masalah.

Gunakan daftar checklist rilis seperti ini:

1. Konfirmasikan ID aplikasi dan versi native.
2. Pilih saluran target.
3. Unggah paket ke saluran tersebut.
4. Konfirmasikan bahwa paket tersebut aktif.
5. Lakukan uji coba asap perangkat.
6. Periksa saluran yang dikembalikan dengangetChannel().
7. Perhatikan adopsi sebelum memperluas peluncuran.

Jaga perlindungan rollback aktif untuk rilis produksi. Pola gagal umum adalah mengunggah tanpa saluran yang jelas atau rencana rollback. Itu meninggalkan tim dengan cara yang lebih sedikit untuk menghentikan paket yang buruk.

Capgo menggunakan langganan per organisasi, dengan uji coba 14 hari gratis. Gunakan uji coba sebagai kesempatan untuk menguji alur rilis pada aplikasi yang sebenarnya, bukan hanya untuk memeriksa dashboard. Cobalah satu pengiriman tahap demi tahap, satu tes rollback, dan satu pengecekan saluran otomatis.

Keamanan harus ada dalam daftar checklist yang sama. Lindungi token CI/CD. Batasi siapa yang dapat mengubah Saluran Default Cloud. Jangan biarkan kredit pengiriman produksi masuk ke skrip lokal. Perubahan saluran tidak berwenang dapat terlihat seperti perangkat yang ketinggalan zaman hingga Anda memeriksa jejak audit.

Untuk tim yang sering mengirimkan aplikasi, jadikan prosesnya menjadi biasa. Satu perintah untuk mengirimkan. Satu perangkat uji yang diketahui. Satu aturan saluran yang jelas. Pantau, terima, dan kembali.

Kesimpulan Utama: Mencegah routing ketinggalan zaman dengan menyinkronkan konfigurasi, menghindari pengaturan lokal yang disembunyikan, menguji saluran yang diresolusi, dan siapkan rollback.

FAQ

Mengapa saluran default cloud Capgo tidak memperbarui perangkat yang sudah ada?

Perangkat yang sudah ada mungkin akan mempertahankan saluran lama hingga periksaannya berikutnya. Pengaturan saluran lokal, pengaturan dashboard, atau penugasan paksa juga dapat memprioritaskan Saluran Default Cloud. Konfirmasikan saluran yang diresolusi perangkat dengangetChannel()Jelaskan pengaturan saluran yang lebih kuat, lalu bawa aplikasi ke latar depan.

Mengubah Saluran Default Capgo akan mengubah setiap aplikasi yang terinstal?

Ya, mengubah Cloud Default tidak langsung menulis ulang setiap aplikasi yang terpasang ke channel baru. Perangkat baru dapat menggunakan default baru segera. Instalasi yang sudah ada perlu memeriksa ulang sebelum dapat berganti, dan mereka masih tidak akan berganti jika aturan channel yang lebih kuat atau override lokal berlaku.

Apa yang dilakukan npx cap sync ketika ada perubahan pada saluran Capgo?

npx cap syncmengcopy konfigurasi Capacitor yang diperbarui ke proyek-proyek native. Jika Anda mengubahdefaultChanneltetapi melewatkan sync, build native berikutnya mungkin masih mengandung pengaturan channel lama. Jalankan perintah dari root proyek, kemudian build dan instal biner uji yang segar.

Apakah setChannel membuat pengaturan perangkat override di Capgo?

No,setChannel()changes the channel stored locally by the app. It does not create a backend Device Override, so the Capgo dashboard may not show the device as overridden. Clear the local assignment when the device should return to default routing, then verify the result withgetChannel().

Bisa Capgo memperbarui aplikasi native code melalui bundle OTA?

No, Capgo OTA updates apply to web-layer code such as JavaScript, CSS, and assets. A native plugin, permission, or native API change needs a new store build. If the bundle expects native code that the installed app lacks, the update may be rejected even when the channel is correct.

Conclusion

Mulai dengan saluran yang telah ditentukan, bukan default dashboard. Periksa pengaturan, jalankannpx cap sync, verify the bundle against the native runtime, and inspect the device logs before changing rollout rules. Then add a small post-deploy test in Capgo that callsgetChannel()dan memastikan bundle yang diharapkan.