Perbaiki Capgo Default Channel yang Tidak Mengupdate Perangkat

Mengubah Cloud Default di Capgo langsung mengarahkan perangkat baru. Instalasi yang sudah ada mungkin tetap di channel lama sampai check-in lagi, yang menjelaskan banyak kasus ketika channel default cloud Capgo tidak memperbarui perangkat.

Lakukan pemeriksaan secara berurutan. Konfirmasi penugasan perangkat terlebih dahulu, lalu periksa build aplikasi, status sinkronisasi, aturan rollout, logs, dan pengaturan rollback.

Table of Contents

• Langkah 1: Pastikan Perangkat Di-assign ke Default Channel
• Langkah 2: Cek App, Native Runtime, dan Kompatibilitas Update
• Langkah 3: Verifikasi Deployment Sudah Masuk ke Default Channel
• Langkah 4: Paksa Sync Ulang dan Periksa Log di Sisi Device
• Langkah 5: Tinjau Aturan Rollout, Version Gate, dan Rollback Otomatis
• Langkah 6: Gunakan Real-Time Analytics untuk Menemukan Titik Kegagalan yang Tepat
• Langkah 7: Cegah Default Channel Menjadi Basi
• FAQ
• Kesimpulan

Langkah 1: Pastikan Perangkat Di-assign ke Default Channel

Tujuannya adalah mencari tahu aturan mana yang menentukan channel device saat ini. Cloud Default hanya berlaku jika assignment yang lebih kuat belum mengklaim device tersebut.

Buka dashboard Capgo dan periksa device yang terdampak. Cek channel saat ini, app ID, versi, dan waktu check-in terakhir. Bandingkan nilai itu dengan device yang menerima update sesuai harapan. Perbandingan ini sering langsung menunjukkan masalahnya.

Pemilihan channel mengikuti urutan tertentu. Forced channel diprioritaskan lebih dulu. Override device dari dashboard atau API menyusul. Setelah itu, channel lokal yang diatur oleh app. Lalu pengecekan CapgodefaultChanneldi konfigurasi native app. Cloud Default adalah fallback-nya.

Urutan ini berarti perangkat bisa mengabaikan perubahan Cloud Default tanpa error di dashboard. Contohnya, test build mungkin masih memakai channel lokal dari tes sebelumnya. App akan terus memakai nilai lokal tersebut sampai Anda menghapusnya.

Gunakan Panduan debugging updater Capgo saat channel yang di-resolve kosong atau tidak terduga. Ini mencakup kasus ketika app tidak punya default yang bisa dipakai dan perangkat tidak punya override.

Selanjutnya, cek konfigurasi Capacitor Anda. Setup umum bisa menyertakan channel seperti ini:

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

Field ini opsional. Jika dikosongkan, perangkat bisa mewarisi Cloud Default. Ini cocok untuk production build karena routing channel tetap di Capgo Cloud. Jika diisi, pastikan nilainya sesuai dengan channel yang Anda deploy.

Sekarang cari local override di code aplikasi. Pemanggilan kesetChannel()akan mengubah cache lokal. Ini tidak membuat Device Override di backend. Oleh karena itu, dashboard mungkin tidak menampilkan override meskipun app tetap memakai channel lokal.

Hapus nilai lokal tersebut saat perangkat harus kembali ke routing normal. Gunakan method plugin untuk menghapus assignment channel perangkat, atau hapus code yang mengatur channel lalu install ulang app untuk tes yang bersih.

Poin Penting: Perubahan Cloud Default tidak bisa menggantikan assignment channel yang lebih kuat di level device, app, atau lokal.

Langkah 2: Cek App, Native Runtime, dan Kompatibilitas Update

Tujuannya adalah membuktikan bahwa app yang terinstal bisa menerima bundle yang Anda upload. Channel yang benar tetap tidak bisa mengirim update ke native runtime yang tidak kompatibel.

Mulai dari app ID. App yang terinstal di device harus menggunakan identitas app yang sama dengan project tempat Anda mengupload bundle. Ketidakcocokan bisa terlihat seperti masalah channel karena device mengecek Capgo app yang salah.

Kemudian bandingkan versi native runtime dengan aturan kompatibilitas bundle. Capgo live updates dapat mengubah JavaScript, CSS, dan aset web. Namun, mereka tidak bisa menambahkan plugin native atau mengubah code di native project setelah app dirilis. Perubahan native tetap butuh build store baru.

Anggap native runtime sebagai frame di sekitar web code. Jika bundle baru membutuhkan API native yang tidak dimiliki app terinstal, Capgo seharusnya tidak menerapkannya. Build dan upload versi native yang kompatibel sebelum mengetes bundle tersebut.

Periksa versi dan platform app yang terinstal. Tes bundle Android di Android terlebih dahulu. Tes bundle iOS di iOS. Pastikan juga bundle menargetkan versi app yang tepat jika channel Anda menggunakan version gates.

Setelah mengubahdefaultChannel, jalankan perintah sync dari root project:

npx cap sync

Langkah ini menyalin konfigurasi terbaru ke dalam native project. Mengeditcapacitor.configtanpa melakukan sync akan membuat native app tetap menggunakan pengaturan channel lama. Build baru dari native project yang usang tersebut akan terus menghasilkan hasil yang sama.

Untuk pengujian yang bersih, build aplikasi baru setelah sinkronisasi. Jangan mengandalkan binary lama yang terinstal di ponsel. Uninstall saat Anda perlu menghapus cache state channel lokal, lalu install build baru dan cek channel-nya lagi.

Panduan dokumentasi perilaku update Capgo menjelaskan kapan updater mengecek bundle. Gunakan timing itu saat menguji. Jalankan aplikasi atau bawa kembali ke foreground, lalu biarkan pengecekan selesai sebelum menyimpulkan update gagal.

Cek juga native version gate pada bundle. Bundle bisa saja ada di channel yang benar tapi tetap tidak tersedia karena versi minimum app tidak cocok dengan perangkat. Baca detail rilis di dashboard daripada berasumsi upload terbaru berlaku untuk semua instalasi.

Jika aplikasi lolos pengecekan ini, Anda sudah mempersempit penyebab masalahnya. Pertanyaan selanjutnya adalah apakah rilis tersebut benar-benar sampai ke channel yang dituju.

Langkah 3: Verifikasi Deployment Sudah Masuk ke Default Channel

Tujuannya adalah memastikan bundle ada di channel yang di-resolve perangkat. Upload bundle ke satu channel tidak membuatnya tersedia di semua channel.

Buka channel di Capgo Cloud. Cek bundle yang aktif, versinya, dan status deployment-nya. Bandingkan nama channel dengan nilai yang dikembalikan aplikasi. Perhatikan perbedaan kecil sepertiproductionversusprod. Nama channel harus cocok persis.

Jika Anda deploy lewat CI/CD, periksa output command dari job yang sama yang mengunggah bundle. Pastikan app ID dan channel yang dikirim ke CLI sudah benar. Pipeline bisa selesai dengan status upload sukses, padahal salah menargetkan channel staging.

Selanjutnya, cek status bundle tersebut. Release yang berstatus draft atau tidak aktif mungkin terlihat di dashboard, tetapi tidak tersedia bagi device. Jika channel memakai staged rollout, device yang terdampak mungkin tidak memenuhi aturan rollout-nya.

Gunakan satu device test yang sudah diketahui. Beri peran yang jelas. Contohnya, pin satu device ke channel test dan biarkan device lain di Cloud Default. Upload perubahan kecil yang aman, lalu bandingkan catatan check-in keduanya. Ini menghilangkan tebak-tebakan saat testing.

Engine live OTA dari Capgo dirancang untuk perubahan web-layer. Engine ini bisa mengirim update bundle JavaScript, CSS, atau asset tanpa menunggu review store baru. Kecepatan itu bergantung pada release yang aktif di channel yang persis dicek oleh device.

Jika Anda baru saja mengubah Cloud Default, perhatikan timing pada device. Instalasi baru langsung memakai rute baru. Device yang sudah ada biasanya baru berpindah saat melakukan pengecekan update berikutnya. Menutup dan membuka kembali aplikasi bisa membantu memicu pengecekan itu, tapi tidak bisa menimpa channel yang sudah di-pin.

Sekarang verifikasi hasilnya di dalam aplikasi. PanggilgetChannel()setelah updater berjalan. Catat channel yang dikembalikan di samping versi app dan versi bundle. Ini lebih berguna daripada hanya mengecek dashboard karena menunjukkan apa yang diyakini device.

Perkirakan ada jeda jika aplikasi hanya mengecek saat launch atau foreground. Jangan menguji dengan membuka layar yang tidak pernah menjalankan updater. Letakkan pengecekan di jalur startup yang diketahui untuk build pengujian singkat, lalu hapus logging tambahan sebelum release.

Jika channel yang dikembalikan benar tetapi tidak ada bundle yang diterima, lanjutkan ke aturan kompatibilitas dan rollout. Jika channel yang dikembalikan salah, kembali ke Langkah 1 dan hapus penugasan yang mengungguli Cloud Default.

Langkah 4: Paksa Sync Ulang dan Periksa Log di Sisi Device

Tujuannya adalah memisahkan masalah state lokal yang sudah basi dari masalah pengiriman di sisi server. Check-in baru akan memberikan bukti tambahan.

Pertama, pastikan perangkat memiliki akses jaringan. Sesi aplikasi yang sukses tidak membuktikan bahwa updater dapat mencapai endpoint-nya. Filter perusahaan, aturan VPN, captive portal, atau sesi yang kedaluwarsa dapat memblokir permintaan update.

Selanjutnya, bawa aplikasi ke foreground. Tunggu hingga pemeriksaan updater selesai. Jika aplikasi Anda menyediakan event status update, catat event tersebut beserta channel saat ini. Hindari hanya mencatat “update dimulai.” Anda perlu mengetahui apakah aplikasi menemukan bundle, mengunduhnya, memverifikasinya, menginstalnya, atau menolaknya.

Gunakan log perangkat Capgo untuk menemukan tahap gagal pertama. Error pertama biasanya lebih berguna daripada pesan “update gagal” di akhir. Misalnya, channel yang hilang mengarah ke masalah routing. Penolakan kompatibilitas mengarah ke runtime native atau version gate. Error unduhan mengarah ke akses jaringan atau permintaan bundle.

Reinstall adalah tes yang berguna, tetapi mengubah bukti. Reinstall bisa menghapus state channel lokal. Gunakan setelah Anda menangkap channel dan logs saat ini, bukan sebelumnya.

Untuk pemeriksaan yang dapat diulang, catat nilai-nilai ini dalam satu baris log:

• App ID dan versi native app
• Channel yang di-resolve darigetChannel()
• Waktu terakhir pengecekan updater
• Versi bundle yang ditemukan server
• Hasil instalasi atau penolakan

Catatan kecil itu membantu saat perangkat milik tester yang tidak bisa mereproduksi masalah saat diminta. Ini juga memberi tim CI Anda sinyal jelas untuk smoke test otomatis.

Gunakan repositori sumber resmi Capgo Capacitor Updater saat Anda perlu memeriksa perilaku plugin API. Secara khusus, perhatikan perbedaan antara perubahan channel lokal dan penugasan perangkat di dashboard.

Tips Pro: Catat channel hasil resolusi sebelum Anda menghapusnya. Jika tidak, Anda mungkin memperbaiki state tetapi kehilangan petunjuk yang menjelaskan kegagalan.

Langkah 5: Tinjau Aturan Rollout, Version Gate, dan Rollback Otomatis

Tujuannya adalah memeriksa apakah Capgo sengaja menahan atau membatalkan bundle. Update yang hilang terkadang adalah aturan keamanan yang bekerja sesuai desain.

Buka pengaturan channel dan tinjau setiap aturan yang terkait dengan rilis. Cari versi app minimum, pengaturan rollout persentase, filter perangkat, dan kondisi yang terkait dengan rilis. Perangkat di luar aturan akan tetap pada bundle saat ini meskipun channel sudah benar.

Periksa juga format versi. Capgo menggunakan semantic versioning untuk membandingkan rilis. Gate versi yang terlihat benar bagi manusia bisa berperilaku berbeda jika app atau bundle menggunakan format yang tidak terduga. Jaga konsistensi format di seluruh native builds dan rilis OTA.

Lalu tinjau perilaku rollback. Rollback otomatis mungkin mengembalikan perangkat ke bundle sebelumnya setelah health check gagal. Dashboard dapat menampilkan code aktif yang lebih lama, sementara rilis yang Anda harapkan tetap ada tetapi tidak tersedia.

Jangan hapus bundle yang dicurigai sebelum meninjau event-nya. Penghapusan menghilangkan bukti yang berguna. Pertama, catat versi bundle, channel, status rollout, dan alasan rollback. Kemudian putuskan untuk menjeda rilis atau menerbitkan versi yang diketahui baik.

Gunakan channel bertahap untuk perubahan berisiko. Kirim bundle ke kelompok uji kecil terlebih dahulu. Pantau adopsi dan sinyal error. Setelah rilis berperilaku sesuai harapan, lanjutkan rollout. Ini mencegah perubahan web-layer yang buruk mencapai semua perangkat aktif sekaligus.

Rollback hanya memperbaiki code yang bisa diubah oleh OTA. Jika kegagalan berasal dari plugin native yang hilang atau API native yang tidak kompatibel, Anda perlu build store baru. Mengirim bundle JavaScript yang lebih lama tidak akan menambahkan komponen native yang hilang di aplikasi.

Saat memeriksa aturan, ajukan tiga pertanyaan:

• Apakah perangkat ini memenuhi kondisi versi aplikasi?
• Apakah perangkat berada di dalam grup rollout?
• Apakah health check atau tindakan manual mengembalikan perangkat ke bundle yang lebih lama?

Capgo berguna di sini karena model channel yang sama dapat membawa rilis bertahap, mendukung rollback, dan menampilkan aktivitas pembaruan dalam satu workflow. Jaga agar set aturan tetap kecil. Kebijakan yang singkat lebih mudah diaudit daripada tumpukan pengecualian yang dibuat selama insiden.

Jika Anda perlu pemeriksaan berbasis API, dokumentasi API publik Capgo menggambarkan sumber daya untuk perangkat, channel, dan bundle. Gunakan untuk membandingkan tampilan server dengan yang dilaporkan aplikasi. Perbandingan ini dapat mengungkapkan filter dashboard yang usang atau penugasan perangkat yang dibuat oleh otomasi.

Rollback adalah pengaman, bukan pengganti pengujian. Jaga agar satu bundle yang diketahui baik tersedia di setiap channel produksi.

Langkah 6: Gunakan Real-Time Analytics untuk Menemukan Titik Kegagalan yang Tepat

Tujuannya adalah berhenti memperlakukan “tidak diperbarui” sebagai satu kegagalan. Analytics dapat menunjukkan apakah perangkat tidak pernah check-in, tidak menemukan bundle yang memenuhi syarat, gagal saat download, atau di-rollback kemudian.

Mulai dari grup perangkat yang terdampak. Filter berdasarkan versi app, platform, channel, dan versi bundle. Cari polanya. Jika hanya satu build app lama yang gagal, masalahnya mungkin gate kompatibilitas native. Jika semua perangkat di satu channel gagal, periksa channel atau deployment-nya.

Bandingkan adopsi seiring waktu. Garis datar setelah rilis menunjukkan masalah routing atau eligibility. Kenaikan diikuti penurunan menunjukkan error install atau rollback. Kenaikan lambat mungkin hanya berarti perangkat belum membuka app.

Gunakan timestamp dengan hati-hati. Waktu event di dashboard mungkin berbeda dari waktu lokal pengguna. Cocokkan event update dengan check-in terakhir perangkat. Ini membantu saat tester melaporkan update gagal sebelum aplikasi benar-benar melakukan check-in.

Analytics juga membantu Anda menguji perubahan channel dengan aman. Ubah satu variabel dalam satu waktu. Biarkan bundle konstan saat menguji routing. Lalu biarkan routing konstan saat Anda menguji bundle baru. Jika Anda mengubah keduanya, data tidak bisa memberi tahu perubahan mana yang memperbaiki masalah.

Untuk insiden, simpan kumpulan bukti kecil:

• ID perangkat atau label test internal
• Channel yang ter-resolve
• Versi aplikasi native
• Bundle yang diharapkan dan bundle yang terpasang
• Waktu check-in terakhir
• Event rollback atau penolakan

Tampilan real-time Capgo paling berguna saat proses rilis Anda mengirim update lewat CI/CD. Job deployment dapat mengunggah bundle, sementara langkah monitoring memeriksa bahwa perangkat test melaporkan channel dan bundle yang dituju. Ini mengubah keluhan manual menjadi gate rilis.

Kaitkan data analytics dengan catatan rilis. Tulis referensi commit atau build di catatan deployment Anda. Saat dua bundle punya label versi yang mirip, referensi build memberi tahu Anda code mana yang benar-benar berubah.

Jika hanya perangkat yang sudah ada yang gagal setelah perubahan Cloud Default, tunggu check-in berikutnya sebelum mengubah pengaturan lain. Instalasi baru adalah kontrol yang berguna. Ini memberi tahu Anda apakah rute default berfungsi untuk perangkat yang tidak punya state lokal lama.

Langkah 7: Cegah Default Channel Menjadi Basi

Tujuannya agar channel drift terlihat sebelum berdampak ke user. Checklist rilis kecil bisa mencegah sebagian besar kasus berulang.

Pilih satu model routing untuk setiap environment aplikasi. Untuk produksi, Anda bisa mengabaikandefaultChanneldan biarkan Capgo Cloud mengatur default-nya. Untuk test build, Anda bisa set channel secara eksplisit. Setup yang berbahaya adalah campuran local override lama, native config yang usang, dan Cloud Default baru yang tidak diverifikasi siapa pun.

Masukkannpx cap syncke dalam build path setelah ada perubahan konfigurasi. Buat build gagal jika langkah sinkronisasi gagal. Command-nya sederhana, tapi melewatkannya bisa membuat channel kemarin tertanam di native binary hari ini.

Tambahkan smoke test setelah deployment. Perangkat uji harus menjalankan app, memanggilgetChannel(), mengecek bundle yang diharapkan, dan mencatat hasilnya. Verifikasi sering kali jadi langkah yang terlewat dalam workflow OTA. Upload saja tidak membuktikan banyak hal.

Simpan local channel code di balik feature flag yang jelas. Jika test helper memanggilsetChannel(), pastikan production build tidak menyertakannya tanpa sengaja. Ingat bahwa local cache mungkin tidak muncul sebagai dashboard override, jadi UI tidak bisa mendeteksi setiap masalah.

Gunakan checklist rilis seperti ini:

1. Pastikan app ID dan versi native.
2. Pilih target channel.
3. Upload bundle ke channel tersebut.
4. Konfirmasi bahwa bundle sudah aktif.
5. Jalankan smoke test perangkat.
6. Periksa channel yang dikembalikan dengangetChannel().
7. Pantau adopsi sebelum memperluas rollout.

Aktifkan perlindungan rollback untuk rilis produksi. Pola kegagalan yang umum adalah deploy tanpa channel atau rencana rollback yang jelas. Akibatnya tim punya lebih sedikit cara aman untuk menghentikan bundle yang bermasalah.

Capgo menggunakan langganan per organisasi, dengan uji coba gratis 14 hari. Anggap uji coba ini sebagai kesempatan untuk menguji alur rilis Anda pada build aplikasi nyata, bukan sekadar memeriksa dashboard. Coba satu deployment bertahap, satu uji rollback, dan satu pemeriksaan channel otomatis.

Keamanan harus ada di checklist yang sama. Lindungi token CI/CD. Batasi siapa yang dapat mengubah Cloud Default. Jauhkan kredensial deployment produksi dari skrip lokal. Perubahan channel yang tidak sah bisa tampak seperti perangkat yang usang sampai Anda memeriksa jejak audit.

Untuk tim yang sering merilis, jaga prosesnya tetap sederhana. Satu perintah untuk deploy. Satu perangkat uji yang sudah dikenal. Satu aturan channel yang jelas. Lacak, adopsi, rollback.

Poin Penting: Cegah routing usang dengan menyinkronkan config, menghindari override lokal tersembunyi, menguji channel yang sudah di-resolve, dan menjaga kesiapan rollback.

FAQ

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

Perangkat yang sudah ada mungkin tetap menggunakan channel lama hingga pengecekan update berikutnya. Channel lokal, override dashboard, atau penugasan paksa juga bisa memiliki prioritas lebih tinggi daripada Cloud Default. Konfirmasi channel yang teresolusi pada perangkat dengangetChannel(), hapus penugasan yang lebih kuat, lalu bawa aplikasi ke foreground.

Apakah mengubah Capgo Cloud Default mengubah semua aplikasi yang terinstal?

Tidak, mengubah Cloud Default tidak langsung menimpa channel di semua aplikasi yang sudah terpasang. Perangkat baru bisa langsung menggunakan default baru. Instalasi yang sudah ada harus melakukan check-in terlebih dahulu sebelum bisa beralih, dan tetap tidak akan beralih jika ada aturan channel yang lebih kuat atau override lokal yang berlaku.

Apa yang dilakukan npx cap sync untuk perubahan channel Capgo?

npx cap syncmenyalin konfigurasi Capacitor yang diperbarui ke proyek native. Jika Anda mengubahdefaultChanneltetapi melewatkan sync, native build berikutnya mungkin masih berisi pengaturan channel lama. Jalankan perintah dari root proyek, lalu build dan instal binary test yang baru.

Apakah setChannel membuat device override di Capgo?

Tidak,setChannel()mengubah channel yang disimpan secara lokal oleh aplikasi. Ini tidak membuat Device Override di backend, sehingga dashboard Capgo mungkin tidak menampilkan perangkat sebagai overridden. Hapus penugasan lokal ketika perangkat harus kembali ke routing default, lalu verifikasi hasilnya dengangetChannel().

Bisakah Capgo memperbarui code native melalui bundle OTA?

Tidak, update OTA Capgo hanya berlaku untuk code di web-layer seperti JavaScript, CSS, dan aset. Perubahan pada plugin native, permission, atau API native memerlukan build store baru. Jika bundle mengharapkan code native yang tidak dimiliki aplikasi terinstal, update bisa ditolak meskipun channel sudah benar.

Kesimpulan

Mulailah dengan channel yang sudah ditentukan, bukan default dashboard. Periksa assignment, jalankannpx cap sync, verifikasi bundle terhadap native runtime, dan periksa device logs sebelum mengubah aturan rollout. Kemudian tambahkan tes post-deploy kecil di Capgo yang memanggilgetChannel()dan mengonfirmasi bundle yang diharapkan.