Saluran

menginstal __CAPGO_KEEP_0__ Perbarui Langsung __CAPGO_KEEP_1__ install the Capgo Live Updates SDK Saluran Perbarui Langsung

Saluran Tidak Menyediakan Rahasia

Saluran mengontrol kelayakan pembaruan, bukan rahasia paket. Bahkan jika saluran privat atau pengaturan self-assignment 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 Pengamanan Pembaruan Langsung untuk detail.

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. Overset Cloud (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 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 mengvalidasi bahwa saluran tersebut diizinkan (mengatur apakah pengasasan sendiri diizinkan untuk saluran tersebut), kemudian menyimpan saluran secara lokal di perangkat sebagai defaultChannelHal 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 cek pembaruan, sehingga keamanan tetap terjaga.

Perlu diingat: 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. Konfigurasi Capacitor defaultChannel (versi uji default) – Jika ada di capacitor.config.* dan tidak ada kekuatan/override, aplikasi dimulai pada saluran ini (misalnya, ). Ditujukan untuk versi uji / build internal sehingga tester langsung mendarat pada saluran pre-release secara otomatis. Build produksi biasanya meninggalkan ini tidak diatur. beta, qa, pr-123__CAPGO_KEEP_0__ config
4. Saluran Default Cloud (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 menjadi peluncuran atau mundur 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. Mengbiarkan default cloud tidak terdefinisi diizinkan; dalam kasus itu, perangkat harus cocok dengan langkah 1-3 untuk menerima update.

Praktik terbaik:

• Tangani 1-3 sebagai lapisan kecuali / tes; ketika Anda menetapkan default cloud, pengguna nyata harus mengalir ke dalamnya. Jika Anda memilih tidak menetapkan satu, berikan perhatian khusus bagaimana pengguna terhubung (biasanya melalui defaultChannel konfigurasi atau override per-device).
• Hanya konfigurasi defaultChannel di binary yang Anda kirim secara eksplisit kepada tester. Mengbiarkannya tidak terdefinisi menjaga logika produksi tetap sentral di dashboard.
• Pakai setChannel() sangat jarang di produksi—utamanya untuk QA atau diagnostik target.

Jika saluran tertentu dinonaktifkan untuk platform (iOS/Android/Electron toggle) ketika akan dipilih lain kali, 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 akan menerima pembaruan. Ketika Anda memilih untuk menandai default, jangan lupa pola-pola berikut:

• Default tunggal (yang paling umum) – Jika saluran memiliki iOS, Android, dan Electron diaktifkan, maka menjadi default tunggal; perangkat apa pun tanpa penggantian akan menempel di sini.
• 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 setiap satu sebagai default untuk platformnya. Perangkat iOS akan pergi ke default iOS, perangkat Android akan pergi ke default Android, dan aplikasi Electron akan pergi ke default Electron.

Ingatlah bahwa default cloud dan defaultChannel di capacitor.config.* keduanya mengisi lapisan keputusan yang sama. Jika Anda menetapkan nilai awal cloud, Anda tidak perlu mengulang nilai tersebut di konfigurasi Capacitor Anda—biarkan kosong untuk pembangunan produksi. Simpan defaultChannel untuk file biner yang Anda sengaja kirimkan kepada tester atau QA ketika Anda ingin mereka memulai di saluran non-produksi meskipun nilai awal cloud berbeda. defaultChannel Anda dapat mengubah nilai default kapan saja di dashboard. Ketika Anda mengganti nilai default, perangkat baru mengikuti aturan routing baru segera dan perangkat yang sudah ada mengikuti aturan keutamaan normal saat mereka memeriksa kembali.

Pengaturan Saluran

Pengaturan Saluran

Kunjungi bagian “Saluran” di dashboard __CAPGO_KEEP_0__

1. Go to the “Channels” section of the Capgo dashboard
2. Masukkan nama saluran dan klik “Buat”
3. Nama saluran dapat apa saja yang Anda inginkan. Strategi umum adalah mencocokkan saluran dengan tahap pengembangan Anda, seperti:

__CAPGO_KEEP_0__

• 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 pembangunan tes (internal / QA). Untuk pembangunan produksi, lebih baik mengabaikannya sehingga perangkat menggunakan Cloud Default kecuali secara eksplisit diatur.

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, bangun 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 Cloud Default (ketika diatur) daripada mengulangi routing di konfigurasi native.

Kamu 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 bisa menerima update dan bagaimana update disampaikan. Yang paling penting adalah di bawah. Kamu bisa mengonfigurasi hal ini dari aplikasi web, CLI, atau Public API.

• Saluran default: Opsional untuk menandai saluran atau saluran platform khusus yang perangkat baru terhubung ke. Lihat “Pengaturan Saluran Default” untuk skenario routing.
• Pengatur filter platform: Aktifkan atau nonaktifkan pengiriman ke iOS, Android, atau Electron perangkat per saluran.
• Nonaktifkan penurunan otomatis di native: Menghalangi 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 build: Izinkan update ke build pembangunan (bermanfaat untuk tes).
• Biarkan perangkat emulator: Izinkan pembaruan ke perangkat/simulator (bermanfaat untuk tes).
• Biarkan penugasan diri perangkat: Biarkan aplikasi beralih ke saluran ini pada waktu runtime menggunakan setChannelJika dinonaktifkan, setChannel akan gagal untuk saluran ini.

Matikan Strategi Pembaruan Otomatis

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

• besar: Blokir pembaruan lintas-besar (0.0.0 → 1.0.0). Pembaruan minor dan patch masih diizinkan.
• kecil: Blokir pembaruan lintas-kecil (misalnya, 1.1.0 → 1.2.0) dan besar. Pembaruan patch masih diizinkan. Perlu diingat: tidak blokir 0.1.0 → 1.1.0.
• patch: Sangat ketat. Hanya memungkinkan meningkatkan versi patch dalam versi besar dan kecil yang sama. Contoh: 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
• metadata: Tuntut 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 kompatibilitas semver.

Pelajari lebih lanjut dan contoh-contoh di Strategi Nonaktifkan Pembaruan di /docs/cli/perintah/#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

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

• Alur pilihan program beta
• The
• Implementasi flag fitur
• Skenario uji coba 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 Mengatur setChannel() (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Kapan setChannel() dipanggil:

1. Validasi backend (hanya baca): Dikirim permintaan ke backend Capgo untuk memvalidasi apakah channel diizinkan (mengatur izin pengaturan sendiri)
2. Perbarui penyimpanan lokal: Jika validasi berhasil, channel disimpan ke penyimpanan lokal perangkat sebagai defaultChannel
3. Efek instan: The next update check uses the new channel immediately (no waiting for replication)

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

Catatan keamanan: Meskipun hak akses saluran berubah setelah diatur secara lokal (misalnya, pengalihan diri dihapus), backend akan masih melakukan validasi saluran selama periksa update, memastikan keamanan tetap terjaga.

Perbandingan metode perubahan saluran:

Metode	Waktu Efek	Ditahan Dimana	Penggunaan
setChannel() dari plugin	Instan	Hanya perangkat (local)	Penggantian kanal pengguna di dalam aplikasi
Dashboard pengaturan perangkat	Hingga 2 menit	Database backend	Perubahan admin yang ditujukan untuk perangkat tertentu
API pengaturan kanal	Hingga 2 menit	Database backend	Integrasi backend otomatis

Untuk pengalaman pengguna yang terbaik ketika membuat UI penggantian saluran, selalu gunakan plugin’s setChannel() metode.

Versi minimum untuk penggantian saluran lokal hanya: 5.34.0, 6.34.0, 7.34.0, atau 8.0.0 (tergantung pada versi utama Anda). Setiap nomor versi minor berarti setelan fitur yang sama di semua versi utama (misalnya, X.34.0 termasuk fitur yang sama apapun X adalah 5, 6, 7, atau 8). Lihat instalasi plugin untuk tag versi.

Mengasosiasi Paket dengan Saluran

To deploy a live update, you need to upload a new JS bundle build and assign it to a channel. You can do this in one step with the Capgo CLI:

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

Ini akan mengunggah aset web yang dibangun dan menetapkan 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.

Pengaturan Versi Bundle dan Saluran

Perlu diingat bahwa bundle di Capgo adalah global untuk aplikasi Anda, bukan spesifik untuk saluran individu. Bundle yang sama dapat ditugaskan ke saluran-saluran yang berbeda.

Ketika Anda mengatur versi bundle, kami merekomendasikan menggunakan pengaturan versi semantik semver dengan identifikasi pre-release untuk build saluran khusus. Misalnya, rilis beta mungkin diberi versi sebagai 1.2.3-beta.1.

Menggunakan pendekatan ini memiliki beberapa keuntungan:

• Mengkomunikasikan hubungan antara build dengan jelas. 1.2.3-beta.1 adalah jelas merupakan pre-release 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.3Anda tahu 1.2.2 adalah rilis stabil sebelumnya.

Berikut adalah contoh cara Anda mungkin menyesuaikan versi bundel dengan pengaturan saluran yang biasa:

• Development saluran: 1.2.3-dev.1, 1.2.3-dev.2saluran:
• QA saluran: 1.2.3-qa.1, 1.2.3-qa.2saluran:
• Staging saluran: 1.2.3-rc.1, 1.2.3-rc.2saluran:
• Production channel: 1.2.3, 1.2.4menggunakan semver dengan identifikator 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 sejalan dengan proses pengembangan tim Anda.

Mengembalikan Perbaruan Hidup

Judul bagian “Mengembalikan Perbaruan Hidup”

Pilih nama saluran yang ingin Anda kembalikan

1. Cari build yang ingin Anda kembalikan dan klik ikon mahkota
2. Mengembalikan Build
3. 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 Pengembangan

Judul bagian “Mengautomasi Pengembangan”

Untuk alur kerja yang lebih canggih, Anda dapat mengotomatisasi proses update live 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 Integrasi CI/CD dokumen untuk mengetahui lebih lanjut tentang mengotomatisasi Capgo update live.

Mengirimkan ke Perangkat

Sekarang Anda sudah memahami saluran, Anda siap untuk memulai mengirimkan update live 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 Mengaktifkan Perbaruan Hidup guide. Selamat mengupdate!

Penggunaan Saluran Lanjutan: Penggolongan Pengguna

Saluran dapat digunakan tidak hanya untuk tahap pengembangan. Mereka adalah alat yang kuat untuk penggolongan pengguna, memungkinkan fitur seperti:

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

Pelajari cara menerapkan kasus penggunaan lanjutan ini dalam panduan kami: Cara Menggolongkan Pengguna Berdasarkan Paket dan Saluran untuk Flag Fitur dan Pengujian A/B.