Saluran

Saluran Pembaruan Langsung menunjuk ke sebuah build bundle JS aplikasi Anda yang akan dibagikan dengan perangkat apa pun yang telah dikonfigurasi untuk mendengarkan saluran tersebut untuk pembaruan. Ketika Anda menginstal Capgo Saluran Pembaruan Langsung SDK dalam aplikasi Anda, setiap biner 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 privat atau pengaturan pengasas sendiri dinonaktifkan, setiap 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 detailnya.

Bagaimana perangkat memilih saluran (prioritas)

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

1. Pemetaan perangkat paksa (Dashboard) – Menempelkan ID perangkat spesifik ke saluran. Gunakan untuk debugging darurat atau pengujian terkendali dengan pengguna asli tunggal.
2. Override 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 akan menghapusnya.

Pindah Saluran Instan dengan setChannel()

Mulai dari versi plugin 5.34.0, 6.34.0, 7.34.0, atau 8.0.0 (tergantung pada versi mayor Anda), setChannel() berfungsi berbeda: menghubungi backend untuk mengvalidasi apakah saluran tersebut diizinkan (mengatur apakah pengaturan sendiri diaktifkan 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() mengsimpan pengaturan saluran override ke database backend (seperti Dashboard atau API perubahan), dan perangkat harus menunggu replikasi data (hingga 2 menit) sebelum saluran baru diakui.

Siklus saluran baru hanya membaca dari backend (untuk validasi) dan menyimpan secara lokal, sehingga pengaturan saluran menjadi instan. Catatan: Bahkan jika saluran menjadi tidak diizinkan setelah diatur secara lokal, backend akan masih melakukan validasi saluran selama periksa update, sehingga keamanan tetap terjaga.

Perlu diingat: Mengubah saluran melalui Dashboard atau API masih akan ada keterlambatan replikasi hingga 2 menit sebelum semua server edge menampilkan perubahan. Untuk mengganti saluran secara instan, gunakan setChannel() melalui aplikasi code Anda—ini memvalidasi 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 force/override yang ada, aplikasi dimulai pada saluran ini (misalnya, ). beta, qa, pr-123Dedikasi untuk versi uji / aplikasi internal sehingga tester langsung mendarat pada saluran pre-release secara otomatis. Versi produksi biasanya tidak mengatur ini.
4. Saluran Default Cloud (jalan utama ~99% pengguna) – Jika Anda menandai saluran default di dashboard, semua pengguna normal (tidak ada force, tidak ada override, tidak ada konfigurasi defaultChannel) akan terhubung ke sini. Ubahlah untuk mengeluarkan atau mengembalikan secara instan—tidak perlu binary baru. Jika Anda memiliki default platform khusus (misalnya, satu iOS-only, satu Android-only, satu Electron-only), setiap perangkat akan mendarat pada default yang sesuai dengan platformnya. Mengosongkan saluran default cloud diizinkan; dalam hal ini perangkat harus sesuai dengan langkah 1-3 untuk menerima pembaruan.

Praktik terbaik:

• Tangani 1-3 sebagai lapisan kecuali / pengujian; ketika Anda mengatur default cloud, pengguna nyata harus mengalir ke dalamnya. Jika Anda tidak mengatur satu, pastikan Anda sengaja tentang bagaimana pengguna terhubung (biasanya melalui defaultChannel di konfigurasi atau pengaturan per-device).
• Hanya konfigurasi defaultChannel di biner yang Anda kirim secara eksplisit kepada tester. Mengosongkannya menjaga logika produksi tetap terkonsentrasi di dashboard.
• Gunakan setChannel() secara berhati-hati di produksi—utamanya untuk QA atau diagnostik yang sasaran.

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

Ringkasan: Paksa > Atur Ulang > Konfigurasi defaultChannel > Default Cloud.

Pengaturan Default Saluran

Mengatur default cloud adalah opsional, tetapi biasanya berfungsi sebagai jalur utama untuk perangkat baru. Tanpa satu, hanya perangkat yang sesuai dengan petaan paksa, aturan ulang, atau defaultChannel di konfigurasi Capacitor akan menerima update. Ketika Anda memilih untuk menandai default, perhatikan pola-pola berikut:

• Satu default (yang paling umum) – Jika sebuah saluran memiliki iOS, Android, dan Electron diaktifkan, maka menjadi default tunggal; perangkat mana pun tanpa pengaturan override 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 menuju ke default iOS, perangkat Android akan menuju ke default Android, dan aplikasi Electron akan menuju ke default Electron. defaultChannel Ingatlah bahwa default awan dan capacitor.config.* keduanya berada di lapisan keputusan yang sama. Jika Anda menetapkan default awan, Anda tidak perlu mengulang nilai di konfigurasi Capacitor Anda—biarkan defaultChannel kosong untuk build produksi. Simpan defaultChannel untuk biner yang Anda sengaja kirimkan kepada tester atau QA ketika Anda ingin mereka memulai di saluran non-produksi bahkan jika default awan berbeda.

You 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 ketika 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 kapan saja. Untuk menambahkan saluran tambahan kemudian:

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

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

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

Mengatur Saluran di Aplikasi Anda

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

Buka file capacitor.config.ts (atau capacitor.config.json) di editor Anda. Di bawah bagian plugins opsional, atur defaultChannel untuk builds pengujian (internal / QA). Untuk build produksi, lebih baik mengabaikannya agar perangkat menggunakan Default Cloud 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 mana pun yang telah dikonfigurasi sebelumnya.

Peringatan

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

Gunakan defaultChannel hanya dalam pembangunan uji/internal; tinggalkanlah untuk produksi agar pengguna mengikuti Default Cloud (ketika diatur) bukan mengulangi routing di konfigurasi native.

Anda masih dapat memaksa (menempel) perangkat atau menerapkan override kemudian—keduanya langsung menggantikan nilai konfigurasi.

Nama saluran sangat sensitif terhadap huruf besar/kecil.

Pilihan dan Strategi Saluran

Saluran memiliki beberapa pilihan yang mengontrol siapa yang dapat menerima pembaruan dan bagaimana pembaruan disampaikan. Pilihan-pilihan yang paling penting ada di bawah. Anda dapat mengonfigurasi hal ini dari aplikasi web, CLI, atau Publik 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 perangkat iOS, Android, atau Electron per perangkat per saluran.
• Nonaktifkan penurunan otomatis di bawah native: Menghalangi pengiriman pembaruan ketika versi aplikasi native perangkat lebih baru dari bundle saluran (misalnya, perangkat pada 1.2.3 sementara saluran memiliki 1.2.2).
• Permitir build pengembangan: Izinkan pembaruan ke build pengembangan (bermanfaat untuk tes).
• Permitir perangkat emulator: Izinkan pembaruan ke emulator/simulator (bermanfaat untuk tes).
• Permitir perangkat self-assignment: Izinkan aplikasi berganti ke saluran ini pada waktu runtime menggunakan setChannel. Jika dinonaktifkan, setChannel akan gagal untuk saluran ini.

Nonaktifkan Strategi Perbarui Otomatis

Pilih untuk membatasi jenis perbarui mana yang akan dihantarkan secara otomatis. Pilihan:

• besar: Blokir perbarui antar-versi besar (0.0.0 → 1.0.0). Perbarui minor dan patch masih diizinkan.
• kecil: Blokir perbarui antar-versi kecil (misalnya, 1.1.0 → 1.2.0) dan besar. Perbarui patch masih diizinkan. Perlu diingat: tidak akan memblokir 0.1.0 → 1.1.0.
• patch: Paling 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 perbarui minimum metadata pada setiap bundle. Konfigurasi melalui CLI menggunakan --min-update-version atau --auto-min-update-version. Jika tidak ada, saluran akan ditandai sebagai salah dan perbarui akan ditolak sampai diatur.
• tidak ada: Izinkan semua perbarui sesuai dengan kompatibilitas semver.

Pelajari lebih lanjut dan contoh di Nonaktifkan perbarui strategi di /docs/cli/perintah/#nonaktifkan-perbarui-strategi.

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 penerimaan program beta
• Implementasi flag fitur
• Skenario tes 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
});

How Cara Kerja setChannel() (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Ketika setChannel() di panggil:

1. Validasi backend (saja baca): Permintaan dikirim ke Capgo backend untuk memvalidasi apakah channel diizinkan (mengatur izin pengaturan sendiri)
2. Pembaruan penyimpanan lokal: Jika validasi berhasil, channel disimpan ke penyimpanan lokal perangkat sebagai defaultChannel
3. Pengaruh instan: Periksa update selanjutnya menggunakan channel baru segera (tidak menunggu replikasi)

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

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

Perbandingan metode perubahan saluran:

Metode	Waktu Efektif	Ditahan di	Penggunaan
setChannel() dari plugin	Instan	Hanya perangkat (lokal)	Perubahan saluran yang diinisiasi pengguna dalam aplikasi
Dashboard pengaturan perangkat	Hingga 2 menit	Database backend	Perubahan admin yang ditentukan untuk perangkat tertentu
API pengaturan saluran	Hingga 2 menit	Database backend	Integrasi backend otomatis

Untuk pengalaman pengguna yang terbaik saat membangun UI penggantian saluran, selalu gunakan metode plugin. setChannel() Versi minimum untuk penggantian saluran hanya lokal:

, atau 5.34.0, 6.34.0, 7.34.0atau 8.0.0 (tergantung pada versi utama Anda). Setiap nomor versi minor yang sesuai dengan set 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.

Pengalihan 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 menetapkan 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 Anda juga bisa mengalokasikan build ke saluran dari bagian “Paket” di __CAPGO_KEEP_0__ dashboard. Klik ikon menu di samping build dan pilih “Alokasikan ke Saluran” untuk memilih saluran untuk build tersebut.

You can also assign builds to channels from the “Bundles” section of the Capgo dashboard. Click the menu icon next to a build and select “Assign to Channel” to choose the channel for that build.

Pengalihan Versi Paket dan Saluran

Penting untuk dicatat bahwa paket dalam Capgo bersifat global untuk aplikasi Anda, bukan spesifik untuk saluran individu. Paket yang sama dapat diberikan pada beberapa saluran.

Ketika Anda melakukan versi paket, kami merekomendasikan menggunakan versi semantik semver dengan identifikasi pre-release untuk konstruksi saluran khusus. Misalnya, rilis beta mungkin diberi versi sebagai 1.2.3-beta.1.

Metode ini memiliki beberapa keuntungan:

• Memungkinkan komunikasi yang jelas tentang hubungan antara konstruksi. 1.2.3-beta.1 jelas merupakan pre-release dari 1.2.3.
• Mengizinkan penggunaan nomor versi yang sama di beberapa saluran, mengurangi kebingungan.
• Mengaktifkan jalur rollback yang jelas. Jika Anda perlu kembali dari 1.2.3Anda tahu 1.2.2 adalah rilis stabil sebelumnya.

Contoh berikut menunjukkan cara mengatur versi bundle Anda dengan konfigurasi saluran yang biasa digunakan:

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

Menggunakan semver dengan identifikasi pre-release adalah pendekatan yang disarankan, 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 Langsung

Jika Anda mengaktifkan pembaruan live yang memperkenalkan bug atau perlu dibalik, Anda dapat dengan mudah kembali ke versi sebelumnya. Dari bagian “Saluran” di dashboard:

1. Klik nama saluran yang ingin Anda kembali
2. Cari versi yang ingin Anda balik dan klik ikon mahkota
3. Konfirmasi aksi

Versi yang dipilih akan langsung menjadi versi aktif untuk saluran tersebut lagi. Aplikasi akan menerima versi yang dibalik pada saat mereka memeriksa pembaruan berikutnya.

Mengautomasi Pembaruan

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

Cek tautan Integrasi CI/CD docs untuk mengetahui lebih lanjut tentang mengautomasi pembaruan live Capgo.

Mengirimkan ke Perangkat

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

1. Pasang Capgo SDK di aplikasi Anda
2. Konfigurasi aplikasi untuk mendengar saluran yang diinginkan Anda
3. Unggah bangun dan tentukan saluran tersebut
4. Luncurkan aplikasi dan tunggu pembaruan!

Untuk panduan yang lebih rinci, lihat Mengirimkan Pembaruan Hidup panduan. 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:

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

Pelajari cara menerapkan kasus penggunaan maju dalam panduan kami: Bagaimana Membagi Pengguna Berdasarkan Paket dan Saluran untuk Flag Fitur dan Pengujian A/B.