Saluran

Saluran Pembaruan Langsung menunjuk ke sebuah build bundle JS aplikasi yang akan dibagikan dengan perangkat apa pun yang telah dikonfigurasi untuk mendengarkan saluran tersebut untuk pembaruan. Ketika Anda menginstal Capgo Saluran Pembaruan Langsung SDK di aplikasi Anda, setiap binary native yang dikonfigurasi ke saluran tersebut akan memeriksa pembaruan yang tersedia setiap kali aplikasi dijalankan. Anda dapat mengubah build yang ditunjuk oleh saluran kapan saja dan juga dapat kembali ke build sebelumnya jika perlu.

Saluran Tidak Menyediakan Rahasia

Saluran mengontrol kelayakan pembaruan, bukan rahasia bundle. Bahkan jika saluran adalah privat atau pengasasan sendiri telah dinonaktifkan, bundle yang tidak dienkripsi yang diunggah ke Capgo masih harus dianggap sebagai aset publik yang disampaikan kepada klien. Pengenkripsi melindungi jalur pengiriman dan keaslian pembaruan, tetapi bundle yang dikirimkan masih dapat direkayasa balik dari aplikasi yang didistribusikan dengan cukup usaha karena kunci publik adalah bagian dari klien. Lihat Pengenkripsi Pembaruan Langsung untuk detail.

Bagaimana perangkat memilih saluran (prioritas)

Ketika perangkat memeriksa pembaruan, Capgo memutuskan mana saluran yang digunakan dalam urutan ini (prioritas tertinggi terlebih dahulu):

1. Peta Perangkat (Dashboard) – Mengunci perangkat spesifik ke saluran tertentu secara manual. Gunakan untuk debugging darurat atau pengujian terkendali dengan pengguna asli tunggal.
2. Overset Perangkat (per-device) melalui Dashboard atau API – Dibuat ketika Anda mengubah saluran perangkat di dashboard atau melalui API. Gunakan untuk pengguna QA yang beralih antara saluran fitur / PR atau untuk mereproduksi masalah pengguna. Menginstal ulang binary tidak menghapusnya; menghapus entri perangkat.
3. Plugin setChannel() saluran lokal – Dibuat ketika aplikasi memanggil setChannel() dan backend memvalidasi bahwa saluran target memungkinkan pengasasan sendiri. Saluran yang dipilih disimpan secara lokal pada perangkat tersebut, efektif segera, dan tidak ditampilkan di UI Overset Perangkat.

Penggantian Saluran Instan dengan setChannel()

Mulai dari versi plugin 5.34.0, 6.34.0, 7.34.0, atau 8.0.0 (tergantung pada versi utamamu), setChannel() berfungsi berbeda: menghubungi backend untuk mengvalidasi apakah saluran tersebut diizinkan (mengatur apakah pengasasan sendiri diaktifkan untuk saluran tersebut), kemudian menyimpan saluran tersebut secara lokal di perangkat defaultChannelsebagai . Ini berarti saluran baru berlaku langsung

untuk periksa update berikutnya—tidak perlu menunggu replikasi. setChannel() Sebelumnya, saluran pengganti disimpan ke database backend (seperti Dashboard atau API perubahan), dan perangkat harus menunggu replikasi data (sampai 2 menit) sebelum saluran baru diakui. perilaku baru hanya membaca dari backend (untuk validasi) dan menyimpan secara lokal, membuat perubahan saluran instan.

Karena setChannel() hanya lokal, maka tidak membuat entri Pengaturan Perangkat di dashboard __CAPGO_KEEP_0__. Antarmuka Pengaturan Perangkat hanya menampilkan pengaturan yang dibuat dari dashboard atau Public __CAPGO_KEEP_1__. create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

Meskipun saluran menjadi tidak diizinkan setelah diatur secara lokal, backend masih akan memvalidasi saluran selama cek pembaruan, sehingga keamanan tetap terjaga. Perlu diingat:

Jika perubahan saluran dilakukan melalui Dashboard atau __CAPGO_KEEP_0__, masih ada lag replikasi hingga 2 menit sebelum semua server edge menampilkan perubahan. Untuk mengaktifkan saluran secara instan, gunakan dari aplikasi API—ini memvalidasi dengan backend, kemudian mengatur saluran secara lokal untuk efek segera. setChannel() Konfigurasi code

4. Capacitor config defaultChannel – Jika ada di __CAPGO_KEEP_0__— __CAPGO_KEEP_0__ config capacitor.config.* dan tidak ada saluran paksa/override/local yang ada, aplikasi dimulai pada saluran ini (misalnya beta, qa, pr-123). Direkayakan untuk TestFlight / build internal sehingga tester langsung berada di saluran pre-release otomatis.
5. Saluran Default Cloud (jalan utama ~99% pengguna) – Jika Anda menandai saluran default di dashboard, semua pengguna normal (tidak paksa, tidak Dashboard/API override, tidak plugin local channel, tidak konfigurasi defaultChannel) akan menghubungkan ke sini. Perubahan ke saluran ini untuk mengeluarkan atau mengembalikan secara instan—tidak ada binary baru. Jika Anda memiliki default platform khusus (misalnya, satu iOS-only, satu Android-only, satu Electron-only), setiap perangkat akan menghubungkan ke default yang sesuai dengan platformnya. Mengosongkan saluran default cloud diizinkan; dalam hal itu perangkat harus sesuai dengan langkah-langkah 1–4 untuk menerima pembaruan.

Praktik terbaik:

• Tangani 1–4 sebagai lapisan kecuali / pengujian; ketika Anda menetapkan default cloud, pengguna nyata harus mengalir ke dalamnya. Jika Anda memilih tidak menetapkan satu, maka Anda harus sengaja tentang bagaimana pengguna menghubungkan (biasanya melalui defaultChannel di konfigurasi atau perangkat pengguna override).
• Hanya konfigurasi defaultChannel di binary yang Anda kirim secara eksplisit kepada tester. Mengosongkannya menjaga logika produksi tetap sentral di dashboard.
• Gunakan setChannel() sangat jarang di produksi—utamanya untuk QA atau diagnostik sasaran.

Jika saluran tertentu dinonaktifkan untuk platform (iOS/Android/Electron toggle) ketika akan dipilih, proses seleksi melompatinya dan melanjutkan ke daftar.

Ringkasan: Force > Dashboard/API Override > Plugin setChannel() saluran lokal > Konfigurasi defaultChannel > Cloud Default.

Default Channel Behavior

Mengatur default cloud tidak wajib, tetapi biasanya berfungsi sebagai jalur default untuk perangkat baru. Tanpa satu, hanya perangkat yang sesuai dengan petaan paksa, penggantian, atau defaultChannel dalam konfigurasi Capacitor yang akan menerima update. Ketika Anda memilih untuk menandai default, perhatikan pola-pola berikut:

• Default tunggal (yang paling umum) – Jika sebuah saluran memiliki iOS, Android, dan Electron diaktifkan, maka menjadi default tunggal; perangkat tanpa penggantian akan menempel di sini.
• Pengaturan default spesifik platform – Jika Anda membagi saluran berdasarkan platform (misalnya, ios-production dengan hanya iOS diaktifkan, android-production dengan hanya Android diaktifkan, dan electron-production dengan hanya Electron diaktifkan), tandai masing-masing sebagai default untuk platformnya. Perangkat iOS pergi ke default iOS, perangkat Android pergi ke default Android, dan aplikasi Electron pergi ke default Electron.

Ingatlah bahwa default awan dan defaultChannel di capacitor.config.* keduanya mengisi lapisan keputusan yang sama. Jika Anda menetapkan default awan, Anda tidak perlu mengulangi nilai di konfigurasi Capacitor Anda—biarkan defaultChannel kosong untuk pembangunan produksi. Simpan defaultChannel untuk biner yang Anda sengaja kirim ke tester atau QA ketika Anda ingin mereka memulai di saluran non-produksi bahkan jika default awan berbeda.

Anda dapat mengubah default kapan saja di dashboard. Ketika Anda mengganti default, perangkat baru mengikuti routing baru segera dan perangkat yang ada mengikuti aturan keutamaan normal pada saat mereka memeriksa kembali.

Pengaturan Saluran

Pada saat proses onboarding Anda membuat saluran pertama (banyak tim menamainya “Produksi”), tetapi tidak ada yang terkunci—Anda dapat menamai atau menghapus saluran mana pun kapan saja. Untuk menambahkan saluran tambahan kemudian:

1. Pergi ke bagian “Saluran” dari Capgo dashboard
2. Klik tombol “Channel Baru”
3. Masukkan nama untuk channel dan klik “Buat”

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

• Development - untuk menguji pembaruan hidup di perangkat lokal atau emulator
• QA - untuk tim QA Anda untuk memverifikasi pembaruan sebelum rilis yang lebih luas
• Staging - untuk pengujian akhir di lingkungan produksi yang mirip
• Production - untuk versi aplikasi yang pengguna akhir menerima dari toko aplikasi

Mengatur Channel di Aplikasi Anda

Setelah channel Anda dibuat, Anda perlu mengatur aplikasi Anda untuk mendengarkan channel yang tepat. Dalam contoh ini, kita akan menggunakan Development channel.

Buka capacitor.config.ts atau capacitor.config.jsonfile. Di bawah plugins bagian ini, Anda dapat memilih defaultChannel untuk build uji build produksi. Untuk build produksi, lebih baik Anda tidak mengatur ini agar perangkat menggunakan Default Cloudflare kecuali secara eksplisit diatur ulang.

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

Langkah berikutnya, buat aplikasi web Anda dan jalankan npx cap sync untuk menyalin file konfigurasi yang diperbarui ke proyek iOS, Android, dan Electron Anda. Jika Anda melewatkan langkah sinkronisasi ini, proyek native Anda akan terus menggunakan saluran yang telah diatur sebelumnya.

Peringatan

Urutan pilihan saluran: Paksa > Dashboard/API pengaturan perangkat > Plugin setChannel() saluran lokal > Konfigurasi defaultChannel > Default Cloud.

Gunakan defaultChannel hanya dalam build internal/test; tinggalkan saja untuk produksi agar pengguna mengikuti Default Cloud (ketika diatur) bukan mengulangi routing di konfigurasi native.

Anda masih bisa memaksa (menahan) perangkat atau menerapkan pengaturan tambahan kemudian—keduanya langsung menggantikan nilai konfigurasi.

Nama saluran sangat sensitif terhadap huruf besar/kecil.

Opsi dan Strategi Saluran

Saluran memiliki beberapa opsi yang mengontrol siapa yang dapat menerima update dan bagaimana update disampaikan. Opsi-opsi paling penting ada di bawah. Anda bisa mengonfigurasi ini dari aplikasi web, CLI, atau API Publik.

• Saluran default: Opsionalnya tandai saluran atau saluran khusus platform yang perangkat baru terhubung ke. Lihat “Pengaturan Saluran Default” untuk skenario routing.
• Pengguna filter platform: Aktifkan atau nonaktifkan pengiriman ke iOS, Android, Electron perangkat per saluran.
• Matikan auto downgrade di native: Menghambat pengiriman pembaruan ketika versi aplikasi native perangkat lebih baru dari bundle saluran (misalnya, perangkat pada 1.2.3 sementara saluran memiliki 1.2.2).
• Izinkan bangunan pengembangan: Izinkan pembaruan ke bangunan pengembangan (bermanfaat untuk tes).
• Izinkan perangkat emulator: Izinkan pembaruan ke emulator/simulator (bermanfaat untuk tes).
• Izinkan perangkat penugasan sendiri: Biarkan aplikasi berganti ke saluran ini pada waktu runtime menggunakan setChannelJika dinonaktifkan, setChannel akan gagal untuk saluran ini.

Strategi Auto Update yang Diblokir

Gunakan ini untuk membatasi jenis-jenis pembaruan yang akan secara otomatis disampaikan oleh saluran. Pilihan:

• versi utama: Menghalangi target bundle yang versi utamanya lebih tinggi dari basis native perangkat (version_buildContoh: 1.2.3 -> 2.0.0 is diblokir; 1.2.3 -> 1.9.0 diperbolehkan.
• minor: Mengblokir suatu bundle target yang versi mayor atau minor berbeda dari version_build. Contoh: 1.2.3 -> 1.3.0 diblokir; 1.2.3 -> 1.2.4 diperbolehkan.
• patch: Mode paling ketat. Mengblokir perubahan apa pun pada nomor mayor, minor, atau patch. Hanya perubahan sufiks yang diperbolehkan sementara MAJOR.MINOR.PATCH tetap identik. Contoh: 1.0.0-beta.1 -> 1.0.0-beta.2 diperbolehkan, 1.0.0+build.1 -> 1.0.0+build.2 diperbolehkan, 1.0.0 -> 1.0.1 diblokir.
• metadata: Memerlukan versi update minimum metadata pada setiap bundle. Konfigurasi melalui CLI menggunakan --min-update-version atau --auto-min-update-version. Jika tidak ada, saluran tersebut akan ditandai tidak terkonfigurasi dan pembaruan akan ditolak sampai diatur.
• none: Izinkan semua pembaruan sesuai dengan kompatibilitas semver Strategi-strategi ini membandingkan bundle target saluran terhadap basis native yang dikirim sebagai.

, bukan bundle yang diunduh saat ini yang dikirim sebagai version_buildPelajari lebih lanjut detail dan contoh di Strategi Nonaktifkan Pembaruan di /docs/__CAPGO_KEEP_0__/perintah/#nonaktifkan-pembaruan version_name.

Contoh (cli):

Example (CLI):

# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

Bagian berjudul “Menggunakan setChannel() dari Aplikasi Anda”

Mengizinkan aplikasi Anda untuk berganti saluran secara programatis pada waktu runtime. Ini sangat berguna untuk: setChannel() Menu QA/debug di mana tester dapat berganti antara saluran

• Alur penerimaan program beta
• Implementasi flag fitur
• Skenario uji coba A/B
• Salin ke clipboard

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

// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });

// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

Kapan

dipanggil: setChannel() Validasi backend (hanya baca)

1. __CAPGO_KEEP_0__: Mengirim permintaan ke backend Capgo untuk memvalidasi apakah saluran tersebut diizinkan (mengatur izin pengaturan sendiri)
2. Penyimpanan lokal diperbarui: Jika validasi berhasil, saluran tersebut disimpan ke penyimpanan lokal perangkat sebagai defaultChannel
3. Efek instan: Pengecekan update selanjutnya menggunakan saluran baru segera (tidak menunggu replikasi)

Mengapa ini penting: Pada versi lama, setChannel() menyimpan pengaturan saluran override ke database backend (sama seperti Dashboard atau API perubahan). Perangkat harus menunggu replikasi backend (sampai 2 menit) sebelum perubahan saluran efektif. Sekarang, setChannel() hanya membaca dari backend (untuk validasi) dan menyimpan secara lokal, membuat perubahan saluran instan.

Keterlihatan Dashboard: Saluran yang ditetapkan dengan plugin tidak membuat perangkat muncul sebagai Pengaturan Perangkat di UI Capgo. Hanya pengaturan saluran yang dibuat dari dashboard atau Public API yang terdaftar di sana. Gunakan dashboard atau API ketika Anda membutuhkan pengaturan override yang terlihat oleh admin.

Pemberitahuan Keamanan: Meskipun izin saluran berubah setelah ditetapkan secara lokal (misalnya, pengasasan diri sendiri dinonaktifkan), backend akan masih lagi memvalidasi saluran selama periksa update, memastikan keamanan tetap terjaga.

Penggabungan metode perubahan saluran:

Metode	Waktu Efek	Dimasukkan di Mana	Ditampilkan di Perangkat Penggantian UI	Penggunaan Kasus
setChannel() melalui plugin	Instan	Hanya perangkat (lokal)	Tidak	Penggantian saluran yang diinisiasi pengguna dalam aplikasi
Dashboard penggeser perangkat	Hingga 2 menit	Database backend	Ya	Perubahan admin yang ditentukan untuk perangkat tertentu
Pengaturan saluran API	Hingga 2 menit	Database backend	Ya	Integrasi backend otomatis

Untuk pengalaman pengguna yang terbaik ketika membangun UI penggeser saluran, selalu gunakan metode plugin. setChannel() Untuk pengalaman pengguna yang terbaik ketika membangun UI penggeser saluran, selalu gunakan metode plugin.

Versi minimum untuk switching saluran lokal: 5.34.0, 6.34.0, 7.34.0, atau 8.0.0 (tergantung pada versi utama Anda). Setiap nomor versi minor mewakili set fitur yang sama di semua versi utama (misalnya, X.34.0 mencakup fitur yang sama apapun X adalah 5, 6, 7, atau 8). Lihat pemasangan plugin untuk tag versi.

Pengalokasian Paket ke Saluran

Untuk mengaktifkan pembaruan live, Anda perlu mengunggah bundle JS baru dan mengalokasikannya ke saluran. Anda bisa melakukannya dalam satu langkah dengan menggunakan Capgo CLI:

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

Langkah ini akan mengunggah aset web yang dibangun dan mengatur bundle baru sebagai build aktif untuk saluran. Aplikasi-aplikasi yang dikonfigurasi untuk mendengarkan saluran tersebut akan menerima pembaruan pada saat mereka memeriksa pembaruan berikutnya. Development Salinan ke clipboard

Anda juga dapat menugaskan bangun dari bagian “Bundles” dari Capgo dashboard. Klik ikon menu di samping bangun dan pilih “Tugaskan ke Saluran” untuk memilih saluran untuk bangun tersebut.

Versi Paket dan Saluran

Perlu diingat bahwa paket dalam Capgo adalah global untuk aplikasi Anda, bukan spesifik untuk saluran individu. Paket yang sama dapat ditugaskan ke beberapa saluran.

Ketika Anda melakukan versi paket, kami merekomendasikan menggunakan versi semantik dengan Capgo’s Semver Tester dan identifikasi pre-release untuk bangun spesifik saluran. Misalnya, rilis beta mungkin versi sebagai 1.2.3-beta.1.

Dengan cara ini memiliki beberapa keuntungan:

• Mengkomunikasikan hubungan antara bangun secara jelas. 1.2.3-beta.1 Tampaknya jelas bahwa ini adalah pre-release dari 1.2.3.
• Mengizinkan penggunaan nomor versi kembali di saluran, mengurangi kebingungan.
• Mengaktifkan jalur rollback yang jelas. Jika Anda perlu kembali dari 1.2.3Apakah Anda tahu 1.2.2 adalah rilis stabil sebelumnya.

Contoh berikut menunjukkan cara Anda mungkin menyesuaikan versi bundle Anda dengan pengaturan saluran biasa:

• Development saluran: 1.2.3-dev.1, 1.2.3-dev.2dan seterusnya.
• QA saluran: 1.2.3-qa.1, 1.2.3-qa.2dan seterusnya.
• Staging saluran: 1.2.3-rc.1, 1.2.3-rc.2dan seterusnya.
• Production saluran: 1.2.3, 1.2.4dan seterusnya.

Menggunakan semver dengan identifikasi pre-release adalah pendekatan yang direkomendasikan, tetapi tidak secara ketat diperlukan. Kunci adalah menemukan skema versi yang dengan jelas menyampaikan hubungan antara build Anda dan berpadu dengan proses pengembangan tim Anda.

Kembali ke Versi Hidup

Jika Anda mengunduh versi hidup yang memperkenalkan bug atau perlu diubah kembali, Anda dapat dengan mudah kembali ke build sebelumnya. Dari bagian “Saluran” dashboard:

1. Pilih nama saluran yang ingin Anda kembali ke
2. Cari build yang ingin Anda kembalikan dan klik ikon mahkota
3. Konfirmasi aksi

Build yang dipilih akan langsung menjadi build aktif untuk saluran tersebut lagi. Aplikasi akan menerima versi yang dikembalikan pada saat mereka memeriksa update berikutnya.

Mengautomasi Pengunduhan

Untuk alur kerja yang lebih maju, Anda dapat mengautomatisasi pengiriman update hidup Anda sebagai bagian dari pipeline CI/CD Anda. Dengan mengintegrasikan Capgo ke dalam proses pembangunan Anda, Anda dapat mengunggah bundle baru secara otomatis dan menugaskan mereka ke saluran ketika Anda push ke cabang-cabang tertentu atau membuat rilis baru.

Cek tautan ini Integrasi CI/CD dokumen untuk mempelajari lebih lanjut tentang mengautomatisasi update hidup Capgo.

Mengirimkan ke Perangkat

Sekarang Anda sudah memahami saluran, Anda siap untuk memulai mengirimkan update hidup ke perangkat nyata. Proses dasar adalah:

1. Pasang Capgo SDK di aplikasi Anda
2. Konfigurasi aplikasi untuk mendengarkan saluran yang diinginkan Anda
3. Unggah build dan tugaskan ke saluran tersebut
4. Luncurkan aplikasi dan tunggu update!

Untuk walkthrough yang lebih rinci, lihat Deploying Live Updates Petunjuk. Selamat mengupdate!

Penggunaan Saluran Lanjutan: Segmentasi Pengguna

Saluran dapat digunakan untuk lebih dari hanya tahap pengembangan. Mereka adalah alat yang kuat untuk segmentasi pengguna, memungkinkan fitur seperti:

• Bendera fitur untuk tingkat pengguna yang berbeda
• Pengujian A/B
• Pengaktifan fitur secara bertahap
• Program uji coba beta

Belajar cara menerapkan kasus penggunaan lanjutan ini dalam panduan kami: Bagaimana Mengsegmentasikan Pengguna berdasarkan Paket dan Saluran untuk Bendera Fitur dan Pengujian A/B.

Teruskan dari Saluran

Jika Anda menggunakan Channel untuk merencanakan routing channel dan peluncuran tahap demi tahap, hubungkan dengan Channel untuk detail implementasi di Channel Channel untuk detail implementasi di Channel Solusi Pengujian Beta untuk alur kerja produk di Solusi Pengujian Beta Solusi Target Versi untuk alur kerja produk di Solusi Target Versi Capgo Praktik Terbaik Lingkungan: Staging dengan Satu ID Aplikasi Mobile untuk konteks praktis di Capgo Praktik Terbaik Lingkungan: Staging dengan Satu ID Aplikasi Mobile