Langsung ke konten

Saluran

Channel Live Update mengarah ke build bundle JS tertentu dari aplikasi Anda yang akan dibagikan dengan perangkat yang dikonfigurasi untuk mendengarkan channel tersebut untuk pembaruan. Ketika Anda menginstal Capgo Live Updates SDK di aplikasi Anda, setiap binary native yang dikonfigurasi ke channel tersebut akan memeriksa pembaruan yang tersedia setiap kali aplikasi diluncurkan. Anda dapat mengubah build yang ditunjuk channel kapan saja dan juga dapat kembali ke build sebelumnya jika diperlukan.

Bagaimana Perangkat Memilih Channel (Prioritas)

Section titled “Bagaimana Perangkat Memilih Channel (Prioritas)”

Ketika perangkat memeriksa pembaruan, Capgo memutuskan channel mana yang akan digunakan dalam urutan ketat ini (prioritas tertinggi lebih dulu):

  1. Pemetaan perangkat paksa (Dashboard) – Pin ID perangkat tertentu ke channel secara manual. Gunakan untuk debugging mendesak atau pengujian terkontrol dengan satu pengguna nyata. Ini selalu menang.
  2. Override cloud (per-perangkat) via Dashboard atau API – Dibuat ketika Anda mengubah channel perangkat di dashboard atau via API. Gunakan untuk pengguna QA yang beralih antar channel fitur/PR atau untuk mereproduksi masalah pengguna. Menginstal ulang binary tidak menghapusnya; menghapus entri perangkat yang menghapusnya.
  1. Capacitor config defaultChannel (default build test) – Jika ada di capacitor.config.* dan tidak ada force/override, aplikasi mulai di channel ini (misalnya beta, qa, pr-123). Ditujukan untuk build TestFlight/internal agar tester otomatis masuk ke channel pre-release. Build produksi biasanya membiarkan ini tidak diatur.
  2. Cloud Default Channel (jalur utama ~99% pengguna) – Jika Anda menandai channel default di dashboard, semua pengguna akhir normal (tanpa force, tanpa override, tanpa config defaultChannel) terhubung di sini. Ubah untuk roll out atau roll back secara instan—tidak perlu binary baru. Jika Anda memiliki default spesifik platform (satu khusus iOS, satu khusus Android), setiap perangkat masuk ke default yang sesuai dengan platformnya. Membiarkan cloud default tidak diatur diperbolehkan; dalam hal ini perangkat harus cocok di langkah 1-3 untuk menerima pembaruan.

Best practice:

  • Perlakukan 1-3 sebagai layer pengecualian/pengujian; ketika Anda mengatur cloud default, pengguna nyata harus mengalir ke sana. Jika Anda memilih untuk tidak mengaturnya, sengaja tentukan bagaimana pengguna terhubung (biasanya via defaultChannel di config atau override per-perangkat).
  • Hanya konfigurasikan defaultChannel di binary yang Anda kirim secara eksplisit ke tester. Membiarkannya tidak diatur menjaga logika produksi terpusat di dashboard.
  • Gunakan setChannel() dengan hemat di produksi—terutama untuk QA atau diagnostik tertarget.

Jika channel dinonaktifkan untuk platform (toggle iOS/Android) ketika seharusnya dipilih, proses seleksi melewatinya dan melanjutkan ke bawah daftar.

Ringkasan: Force > Override > Config defaultChannel > Cloud Default.

Mengatur cloud default bersifat opsional, tetapi biasanya berfungsi sebagai jalur catch-all untuk perangkat baru. Tanpanya, hanya perangkat yang cocok di pemetaan paksa, override, atau defaultChannel di config Capacitor yang akan menerima pembaruan. Ketika Anda memilih untuk menandai default, ingat pola-pola ini:

  • Default tunggal (paling umum) – Jika channel mengaktifkan iOS dan Android, ia menjadi satu-satunya default; perangkat apa pun tanpa override akan terhubung di sini.
  • Default spesifik platform – Jika Anda memisahkan channel berdasarkan platform (misalnya, ios-production dengan hanya iOS diaktifkan dan android-production dengan hanya Android diaktifkan), tandai masing-masing sebagai default untuk platformnya. Perangkat iOS pergi ke default iOS, perangkat Android pergi ke default Android.

Ingat bahwa cloud default dan defaultChannel di capacitor.config.* keduanya menempati layer keputusan yang sama. Jika Anda mengatur cloud default, Anda tidak perlu menduplikasi nilai di config Capacitor Anda—biarkan defaultChannel kosong untuk build produksi. Cadangkan defaultChannel untuk binary yang Anda sengaja kirim ke tester atau QA ketika Anda ingin mereka mulai di channel non-produksi meskipun cloud default berbeda.

Anda dapat mengubah default kapan saja di dashboard. Ketika Anda menukar default, perangkat baru mematuhi routing baru segera dan perangkat yang ada mengikuti aturan prioritas normal saat mereka check in berikutnya.

Selama onboarding Anda membuat channel pertama (kebanyakan tim menamakannya “Production”), tetapi tidak ada yang terkunci—Anda dapat mengganti nama atau menghapus channel kapan saja. Untuk menambahkan channel tambahan nanti:

  1. Buka bagian “Channels” di dashboard Capgo
  2. Klik tombol “New Channel”
  3. Masukkan nama untuk channel dan klik “Create”

Nama channel bisa apa saja yang Anda inginkan. Strategi yang umum adalah menyesuaikan channel dengan tahap pengembangan Anda, seperti:

  • Development - untuk menguji live update di perangkat lokal atau emulator
  • QA - untuk tim QA Anda memverifikasi pembaruan sebelum rilis yang lebih luas
  • Staging - untuk pengujian akhir di lingkungan seperti produksi
  • Production - untuk versi aplikasi Anda yang diterima pengguna akhir dari app store

Dengan channel Anda yang telah dibuat, Anda perlu mengkonfigurasi aplikasi untuk mendengarkan channel yang sesuai. Dalam contoh ini, kita akan menggunakan channel Development.

Buka file capacitor.config.ts (atau capacitor.config.json) Anda. Di bagian plugins, secara opsional atur defaultChannel untuk build test (internal/QA). Untuk build produksi, lebih baik menghilangkannya agar perangkat menggunakan Cloud Default kecuali secara eksplisit di-override.

import { CapacitorConfig } from '@capacitor/cli';
const config: CapacitorConfig = {
plugins: {
CapacitorUpdater: {
// Untuk build QA/TestFlight – tester mulai di channel Development secara otomatis.
defaultChannel: 'Development',
// Build produksi biasanya menghilangkan ini agar pengguna terhubung ke Cloud Default channel.
},
},
};

Selanjutnya, build aplikasi web Anda dan jalankan npx cap sync untuk menyalin file konfigurasi yang diperbarui ke proyek iOS dan Android Anda. Jika Anda melewatkan langkah sinkronisasi ini, proyek native Anda akan terus menggunakan channel yang sebelumnya dikonfigurasi.

Channel memiliki beberapa opsi yang mengontrol siapa yang dapat menerima pembaruan dan bagaimana pembaruan dikirim. Yang paling penting ada di bawah. Anda dapat mengkonfigurasinya dari web app, CLI, atau Public API.

  • Channel default: Secara opsional tandai channel atau channel spesifik platform tempat perangkat baru terhubung. Lihat “Perilaku Channel Default” untuk skenario routing.
  • Filter platform: Aktifkan atau nonaktifkan pengiriman ke perangkat iOS dan/atau Android per channel.
  • Nonaktifkan auto downgrade di bawah native: Mencegah pengiriman pembaruan ketika versi aplikasi native perangkat lebih baru dari bundle channel (misalnya, perangkat di 1.2.3 sementara channel memiliki 1.2.2).
  • Izinkan build development: Izinkan pembaruan ke build development (berguna untuk pengujian).
  • Izinkan perangkat emulator: Izinkan pembaruan ke emulator/simulator (berguna untuk pengujian).
  • Izinkan self-assignment perangkat: Memungkinkan aplikasi beralih ke channel ini saat runtime menggunakan setChannel. Jika dinonaktifkan, setChannel akan gagal untuk channel ini.

Gunakan ini untuk membatasi jenis pembaruan apa yang akan dikirim channel secara otomatis. Opsi:

  • major: Blokir pembaruan cross-major (0.0.0 → 1.0.0). Pembaruan minor dan patch masih diizinkan.
  • minor: Blokir pembaruan cross-minor (misalnya, 1.1.0 → 1.2.0) dan major. Pembaruan patch masih diizinkan. Catatan: tidak memblokir 0.1.0 → 1.1.0.
  • patch: Sangat ketat. Hanya mengizinkan versi patch yang meningkat dalam major dan minor yang sama. Contoh: 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
  • metadata: Memerlukan metadata versi pembaruan minimum di setiap bundle. Konfigurasikan via CLI menggunakan --min-update-version atau --auto-min-update-version. Jika tidak ada, channel ditandai salah konfigurasi dan pembaruan akan ditolak sampai diatur.
  • none: Izinkan semua pembaruan sesuai kompatibilitas semver.

Pelajari detail dan contoh lebih lanjut di strategi Nonaktifkan pembaruan di /docs/cli/commands/#disable-updates-strategy.

Contoh (CLI):

Terminal window
# Blokir pembaruan major di channel Production
npx @capgo/cli@latest channel set production com.example.app \
--disable-auto-update major
# Izinkan perangkat untuk self-assign ke channel Beta
npx @capgo/cli@latest channel set beta com.example.app --self-assign

Menggunakan setChannel() dari Aplikasi Anda

Section titled “Menggunakan setChannel() dari Aplikasi Anda”

Metode setChannel() memungkinkan aplikasi Anda untuk beralih channel secara programatik saat runtime. Ini sangat berguna untuk:

  • Menu QA/debug di mana tester dapat beralih antar channel
  • Alur opt-in program beta
  • Implementasi feature flag
  • Skenario A/B testing
import { CapacitorUpdater } from '@capgo/capacitor-updater';
// Beralih ke channel beta
await CapacitorUpdater.setChannel({ channel: 'beta' });
// Secara opsional memicu pemeriksaan pembaruan segera setelah beralih
await CapacitorUpdater.setChannel({
channel: 'beta',
triggerAutoUpdate: true
});

Untuk menerapkan live update, Anda perlu mengunggah build bundle JS baru dan menetapkannya ke channel. Anda dapat melakukan ini dalam satu langkah dengan Capgo CLI:

Terminal window
npx @capgo/cli@latest bundle upload --channel=Development

Ini akan mengunggah aset web yang telah di-build dan menetapkan bundle baru sebagai build aktif untuk channel Development. Setiap aplikasi yang dikonfigurasi untuk mendengarkan channel tersebut akan menerima pembaruan saat mereka memeriksa pembaruan berikutnya.

Anda juga dapat menetapkan build ke channel dari bagian “Bundles” di dashboard Capgo. Klik ikon menu di sebelah build dan pilih “Assign to Channel” untuk memilih channel untuk build tersebut.

Penting untuk dicatat bahwa bundle di Capgo bersifat global untuk aplikasi Anda, tidak spesifik untuk channel individual. Bundle yang sama dapat ditetapkan ke beberapa channel.

Saat memversikan bundle Anda, kami merekomendasikan menggunakan semantic versioning semver dengan pengidentifikasi pre-release untuk build khusus channel. Misalnya, rilis beta mungkin diversion sebagai 1.2.3-beta.1.

Pendekatan ini memiliki beberapa keuntungan:

  • Dengan jelas mengkomunikasikan hubungan antara build. 1.2.3-beta.1 jelas merupakan pre-release dari 1.2.3
  • Memungkinkan penggunaan kembali nomor versi di beberapa channel, mengurangi kebingungan
  • Memungkinkan jalur rollback yang jelas. Jika Anda perlu melakukan rollback dari 1.2.3, Anda tahu 1.2.2 adalah rilis stabil sebelumnya

Berikut contoh bagaimana Anda mungkin menyelaraskan versi bundle Anda dengan pengaturan channel yang umum:

  • Channel Development: 1.2.3-dev.1, 1.2.3-dev.2, dll.
  • Channel QA: 1.2.3-qa.1, 1.2.3-qa.2, dll.
  • Channel Staging: 1.2.3-rc.1, 1.2.3-rc.2, dll.
  • Channel Production: 1.2.3, 1.2.4, dll.

Menggunakan semver dengan pengidentifikasi pre-release adalah pendekatan yang direkomendasikan, tetapi tidak wajib. Yang terpenting adalah menemukan skema versioning yang dengan jelas mengkomunikasikan hubungan antara build Anda dan selaras dengan proses pengembangan tim Anda.

Jika Anda menerapkan live update yang memperkenalkan bug atau perlu dikembalikan karena alasan lain, Anda dapat dengan mudah kembali ke build sebelumnya. Dari bagian “Channels” di dashboard:

  1. Klik nama channel yang ingin Anda rollback
  2. Temukan build yang ingin Anda kembalikan dan klik ikon mahkota Rollback build
  3. Konfirmasi tindakan

Build yang dipilih akan segera menjadi build aktif untuk channel tersebut lagi. Aplikasi akan menerima versi yang di-rollback saat mereka memeriksa pembaruan berikutnya.

Untuk alur kerja yang lebih canggih, Anda dapat mengotomatisasi deployment live update Anda sebagai bagian dari pipeline CI/CD Anda. Dengan mengintegrasikan Capgo ke dalam proses build Anda, Anda dapat secara otomatis mengunggah bundle baru dan menetapkannya ke channel setiap kali Anda push ke branch tertentu atau membuat rilis baru.

Lihat dokumen Integrasi CI/CD untuk mempelajari lebih lanjut tentang mengotomatisasi live update Capgo.

Sekarang setelah Anda memahami channel, Anda siap untuk mulai menerapkan live update ke perangkat nyata. Proses dasarnya adalah:

  1. Instal SDK Capgo di aplikasi Anda
  2. Konfigurasi aplikasi untuk mendengarkan channel yang Anda inginkan
  3. Unggah build dan tetapkan ke channel tersebut
  4. Luncurkan aplikasi dan tunggu pembaruannya!

Untuk panduan yang lebih detail, lihat panduan Menerapkan Live Update. Selamat memperbarui!

Penggunaan Channel Lanjutan: Segmentasi Pengguna

Section titled “Penggunaan Channel Lanjutan: Segmentasi Pengguna”

Channel dapat digunakan untuk lebih dari sekadar tahap pengembangan. Ini adalah alat yang kuat untuk segmentasi pengguna, memungkinkan fitur seperti:

  • Feature flag untuk tier pengguna yang berbeda
  • A/B testing
  • Rollout fitur bertahap
  • Program beta testing

Pelajari cara mengimplementasikan kasus penggunaan lanjutan ini di panduan kami: How to Segment Users by Plan and Channels for Feature Flags and A/B Testing.