Saluran

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

Saluran Tidak Menyediakan Keamanan Rahasia

Saluran mengontrol kelayakan pembaruan, bukan rahasia paket. Bahkan jika saluran privat atau pengasasan sendiri dinonaktifkan, paket tidak terenkripsi yang diunggah ke Capgo masih harus dianggap sebagai aset publik yang disampaikan ke klien. Pengamanan melindungi jalur pengiriman dan keaslian pembaruan, tetapi paket yang dikirim masih dapat direkayasa balik dari aplikasi yang didistribusikan dengan usaha yang cukup karena kunci publik adalah bagian dari klien. Lihat Pengaturan Update Langsung untuk detail lebih lanjut.

Bagaimana perangkat memilih saluran (prioritas)

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

1. Pengaturan perangkat paksa (Dashboard) – Pasang perangkat ID tertentu secara manual ke saluran. Gunakan untuk debugging darurat atau pengujian terkendali dengan pengguna nyata tunggal. Ini selalu menang.
2. Pengaturan Cloud (per-perangkat) 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 melakukan.

Pindai 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 validasi apakah saluran tersebut diizinkan (mengatur apakah pengaturan saluran sendiri diaktifkan untuk saluran tersebut), kemudian menyimpan saluran secara lokal di perangkat sebagai defaultChannel. Ini berarti saluran baru berlaku langsung untuk periksa update berikutnya—tidak perlu menunggu replikasi.

Sebelumnya, setChannel() menghematkan pengaturan saluran ke database backend (seperti Dashboard atau API perubahan), dan perangkat harus menunggu replikasi data (hingga 2 menit) sebelum saluran baru diakui. perilaku baru hanya membaca dari backend (untuk validasi) dan menyimpan secara lokal, membuat perubahan saluran instan.

Catatan: Meskipun saluran menjadi tidak diizinkan setelah diatur secara lokal, backend akan masih melakukan validasi saluran selama periksa update, sehingga keamanan tetap dipertahankan.

Penting: Ketika perubahan saluran dilakukan melalui Dashboard atau API, masih ada lag replikasi hingga 2 menit sebelum semua server edge memperbarui perubahan. Untuk perubahan saluran instan, gunakan setChannel() dari aplikasi code—ini melakukan validasi dengan backend, kemudian mengatur saluran secara lokal untuk efek segera.

3. Capacitor konfigurasi defaultChannel (bentuk uji default) – Jika ada di capacitor.config.* dan tidak ada force/override, aplikasi dimulai pada saluran ini (misalnya, ). Intended untuk TestFlight / build internal sehingga tester mendarat pada saluran pre-release secara otomatis. Build produksi biasanya meninggalkan ini tidak diatur. beta, qa, pr-123Note: Even if a channel becomes disallowed after being set locally, the backend will still validate the channel during update checks, so security is maintained.
4. Saluran Cloud Default (jalan utama ~99% pengguna) – Jika Anda menandai saluran default di dashboard, semua pengguna normal (tidak paksa, tidak override, tidak konfigurasi defaultChannel) akan terhubung di sini. Ubahnya untuk mengeluarkan atau mengembalikan secara instan—tidak ada binary baru. Jika Anda memiliki default platform khusus (misalnya, satu iOS-saja, satu Android-saja, satu Electron-saja), setiap perangkat akan mendarat di default yang sesuai dengan platformnya. Menghilangkan default cloud yang tidak terdefinisi diizinkan; dalam kasus itu, perangkat harus sesuai dengan langkah 1-3 untuk menerima pembaruan.

Praktik terbaik:

• Tangani 1-3 sebagai lapisan kecuali / lapisan 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 terhubung (biasanya melalui defaultChannel konfigurasi atau override per-device).
• Hanya konfigurasi defaultChannel di binary yang Anda kirim secara eksplisit kepada tester. Menghilangkannya menjaga logika produksi tetap terkonsentrasi di dashboard.
• Pakai setChannel() spari-spari di produksi—utamanya untuk QA atau diagnostik yang sasaran.

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

Ringkasan: Paksa > Override > Konfigurasi defaultChannel > Default Cloud.

Pengaturan Default Saluran

Mengatur default cloud adalah opsional, 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 pembaruan. Ketika Anda memilih untuk menandai default, ingatlah pola-pola berikut:

• Default tunggal (yang paling umum) – Jika saluran memiliki iOS, Android, dan Electron diaktifkan, maka menjadi default tunggal; perangkat tanpa penggantian akan menempel di sini.
• Default platform khusus – 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 setiap satu 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 cloud dan defaultChannel di capacitor.config.* kedua 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 kirimkan kepada tes atau QA ketika Anda ingin mereka memulai di saluran non-produksi meskipun 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 kali mereka memeriksa kembali.

Pengaturan Saluran

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

1. Kunjungi bagian “Saluran” di dashboard Capgo
2. Klik tombol “Saluran Baru”
3. Masukkan nama untuk saluran dan klik “Buat”

Nama saluran dapat apa saja yang Anda inginkan. Strategi umum adalah untuk memasangkan saluran dengan tahap pengembangan, seperti:

• Development - untuk tes pembaruan live pada perangkat lokal atau emulator
• QA - untuk tim QA Anda untuk memverifikasi pembaruan sebelum rilis yang lebih luas
• Staging - untuk tes akhir di lingkungan yang mirip produksi
• Production - untuk versi aplikasi yang diterima oleh pengguna akhir dari toko aplikasi

Mengonfigurasi Saluran di Aplikasi Anda

Setelah saluran Anda dibuat, Anda perlu mengonfigurasi aplikasi Anda untuk mendengar saluran yang tepat. Dalam contoh ini, kita akan menggunakan Development saluran.

Buka file capacitor.config.ts (atau capacitor.config.json) di editor Anda. Di bawah bagian plugins opsional defaultChannel untuk uji coba (internal / QA). Untuk pembangunan produksi, lebih baik mengabaikannya sehingga perangkat menggunakan Cloud Default kecuali secara eksplisit diubah.

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.
    },
  },
};

Selanjutnya, bangunlah 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 sebelumnya dikonfigurasi.

Peringatan

Urutan pilihan saluran: Force > Override (setChannel / dashboard) > Konfigurasi defaultChannel > Cloud Default.

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

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

Nama saluran 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 dapat mengonfigurasi opsi-opsi ini dari aplikasi web, CLI, atau Public API.

• Saluran default: Opsional untuk menandai saluran atau saluran khusus platform yang perangkat baru terhubung. Lihat “Pengaturan Saluran Default” untuk skenario routing.
• Pemfilter platform: Aktifkan atau nonaktifkan pengiriman ke iOS, Android perangkat per saluran. Electron Nonaktifkan penurunan otomatis di native: Menghambat pengiriman update ketika versi aplikasi native perangkat lebih baru daripada bundle saluran (misalnya, perangkat pada 1.2.3 sementara saluran memiliki 1.2.2).
• Izinkan pembangunan: Izinkan update ke pembangunan (bermanfaat untuk testing).
• Izinkan pembangunan: Izinkan update ke pembangunan (bermanfaat untuk testing).
• Izinkan perangkat simulator: Izinkan pembaruan ke perangkat simulator/emulator (bermanfaat untuk pengujian).
• Izinkan penugasan perangkat sendiri: Memungkinkan aplikasi beralih ke saluran ini pada waktu runtime menggunakan setChannel. Jika dinonaktifkan, setChannel akan gagal untuk saluran ini.

Nonaktifkan Strategi Auto Update

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

• utama: Blokir pembaruan lintas-utama (0.0.0 → 1.0.0). Pembaruan minor dan patch masih diizinkan.
• minor: Blokir pembaruan lintas-minor (misalnya, 1.1.0 → 1.2.0) dan utama. Pembaruan patch masih diizinkan. Perlu diingat: tidak blokir 0.1.0 → 1.1.0.
• patch: Sangat ketat. Hanya memungkinkan meningkatkan versi patch dalam versi utama dan minor yang sama. Contoh: 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
• metadata: Tuntukan versi pembaruan minimum metadata pada setiap bundle. Konfigurasi melalui CLI menggunakan --min-update-version atau --auto-min-update-version. Jika tidak ada, saluran tersebut akan ditandai sebagai tidak terkonfigurasi dan pembaruan akan ditolak sampai diatur.
• none: Izinkan semua pembaruan sesuai dengan semver kompatibilitas.

Pelajari lebih lanjut dan contoh di Disable updates strategy di /docs/cli/commands/#disable-updates-strategy.

Contoh (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

Menggunakan setChannel() dari Aplikasi Anda

The setChannel() metode memungkinkan aplikasi Anda untuk berganti saluran secara programatis pada waktu eksekusi. Hal ini sangat berguna untuk:

• Menu QA/debug di mana tester dapat berganti antara saluran
• Program beta opt-in aliran
• Implementasi flag fitur
• Skenario tes A/B

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
});

Bagaimana Cara setChannel() Berfungsi (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Ketika setChannel() dipanggil:

1. Validasi backend (hanya baca): Permintaan dikirim ke Capgo backend untuk memvalidasi saluran yang diizinkan (mengatur izin pengasasan sendiri)
2. Perbarui penyimpanan lokal: Jika validasi berhasil, saluran disimpan ke penyimpanan lokal perangkat sebagai defaultChannel
3. Efek instan: Pengecekan update berikutnya menggunakan saluran baru langsung (tidak menunggu replikasi)

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

Catatan keamanan: Meskipun hak akses saluran berubah setelah ditetapkan secara lokal (misalnya, pengaturan sendiri dinonaktifkan), backend akan masih melakukan validasi saluran selama pengecekan update, sehingga keamanan tetap terjaga.

Pembandingan metode perubahan saluran:

Metode	Waktu Efek	Ditahan di Mana	Kasus Pengguna
setChannel() dari plugin	Instan	Hanya Perangkat (local)	Pindah saluran pengguna di dalam aplikasi
Tetapkan perangkat di dashboard	Sampai dengan 2 menit	Database Backend	Perubahan admin untuk perangkat tertentu
Penugasan saluran API	Sampai dengan 2 menit	Database Backend	Integrasi Backend Otomatis

Untuk pengalaman pengguna yang terbaik saat membangun UI pengganti saluran, selalu gunakan metode plugin’s. setChannel() Metode.

Sistem Minimum untuk Penggantian Saluran Hanya 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.

Pengalihan Paket ke Saluran

Untuk mengaktifkan pembaruan hidup, 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

Ini akan mengunggah aset web yang dibangun dan mengatur bundle baru sebagai build aktif untuk Development saluran. Aplikasi-apliki yang dikonfigurasi untuk mendengarkan saluran tersebut akan menerima update pada saat mereka memeriksa update berikutnya.

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

Versi Paket dan Saluran

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

Saat mengatur versi paket, kami merekomendasikan menggunakan versi semantik dengan Capgo’s Semver Tester dan identifikasi pre-release untuk build spesifik saluran. Misalnya, rilis beta mungkin diatur versi sebagai 1.2.3-beta.1.

Dekripsi ini memiliki beberapa keuntungan:

• Mengkomunikasikan hubungan antara build dengan jelas. 1.2.3-beta.1 jelas merupakan rilis pra-terbitan dari 1.2.3.
• Mengizinkan penggunaan nomor versi yang sama di berbagai saluran, mengurangi kebingungan.
• Mengaktifkan jalur pengembalian yang jelas. Jika Anda perlu kembali dari 1.2.3, Anda tahu 1.2.2 adalah rilis stabil sebelumnya.

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

• Development saluran: 1.2.3-dev.1, 1.2.3-dev.2, dll.
• QA saluran: 1.2.3-qa.1, 1.2.3-qa.2, dll.
• Staging saluran: 1.2.3-rc.1, 1.2.3-rc.2, dll.
• Production channel: __CAPGO_KEEP_0__ 1.2.3, 1.2.4dan lain-lain

Menggunakan menggunakan semver dengan identifikasi pre-release adalah pendekatan yang disarankan, tetapi tidak sepenuhnya diperlukan. Kunci adalah menemukan skema versi yang dengan jelas menyampaikan hubungan antara build Anda dan sesuai dengan proses pengembangan tim Anda.

Mengembalikan Perbaruan Hidup

Jika Anda mengirimkan perbaruan hidup yang memperkenalkan bug atau perlu dibalik, Anda dapat dengan mudah mengembalikan ke build sebelumnya. Dari bagian “Saluran” di dashboard:

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

The build yang dipilih akan langsung menjadi build aktif untuk saluran tersebut lagi. Aplikasi akan menerima versi yang dibalikkan pada saat mereka memeriksa untuk memperbarui.

Aplikasi Otomatis

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

Cek tautan ini untuk mempelajari lebih lanjut tentang mengautomatisasi __CAPGO_KEEP_0__ update live. Mengirimkan ke Perangkat docs to learn more about automating Capgo live updates.

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

Konfigurasi aplikasi untuk mendengarkan saluran yang diinginkan

1. Install the Capgo SDK in your app
2. Section titled “Automating Deployments”
3. Upload sebuah build dan tandai untuk saluran tersebut
4. Luncurkan aplikasi dan tunggu pembaruan!

Untuk panduan 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
• Pengeluaran fitur secara bertahap
• Program uji coba beta

Pelajari cara mengimplementasikan kasus penggunaan yang lebih maju dalam panduan kami: Bagaimana cara Membagi Pengguna Berdasarkan Paket dan Saluran untuk Flag Fitur dan Uji Coba A/B.

Lanjutkan dari Saluran

Jika Anda menggunakan Saluran untuk merencanakan routing saluran dan peluncuran tahap demi tahap, hubungkan dengan Saluran untuk detail implementasi di Saluran, Saluran untuk detail implementasi di Saluran, Solusi Uji Coba Beta untuk alur produk dalam Solusi Pengujian Beta, Solusi Target Versi untuk alur produk dalam Solusi Target Versi, dan Capgo Praktik Terbaik Lingkungan: Pengujian Staging dengan Satu ID Aplikasi Mobile untuk konteks praktis dalam Capgo Praktik Terbaik Lingkungan: Pengujian Staging dengan Satu ID Aplikasi Mobile.