Saluran

Salin prompt pengaturan dengan langkah instalasi dan panduan markdown lengkap untuk plugin ini.

Saluran Live Update mengacu pada bangunan bundle JS tertentu dari aplikasi Anda yang akan dibagikan dengan perangkat apa pun yang dikonfigurasi untuk mendengarkan saluran tersebut untuk pembaruan. Ketika Anda menginstal Capgo Live Updates SDK dalam aplikasi Anda, perangkat biner native yang dikonfigurasi ke saluran tersebut akan memeriksa pembaruan yang tersedia setiap kali aplikasi diluncurkan. Anda dapat mengubah bangunan yang dipoint saluran pada saat apapun dan juga dapat kembali ke bangunan sebelumnya jika diperlukan.

Bagaimana perangkat memilih saluran (prioritas)

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

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. Capgo menghapus pengaturan 90 hari setelah tulisan terakhir override. Console and API overrides expire after 90 days.
Console dan API override kadaluarsa setelah 90 hari Pengaturan Cloud (per-perangkat) melalui Dashboard atau API
Plugin setChannel() Saluran Lokal – Dibuat ketika aplikasi memanggil setChannel() dan backend memvalidasi bahwa saluran target memungkinkan pengasasan sendiri. Saluran yang dipilih disimpan secara lokal di perangkat tersebut, berlaku segera, dan tidak ditampilkan di UI Penggeser Perangkat.

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 memvalidasi apakah saluran diizinkan (mengatur apakah pengasasan 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() menghemat saluran override 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 switch saluran instan.

Karena setChannel() adalah lokal-saja, maka tidak membuat entri Override Perangkat di Capgo dashboard. UI Override Perangkat hanya menampilkan override yang dibuat dari dashboard atau Public API.

Penting: Meskipun 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 mengaktifkan saluran secara instan, gunakan setChannel() saluran dari aplikasi code—ini akan diverifikasi dengan backend, kemudian mengatur saluran secara lokal untuk efek langsung.

Konfigurasi Capacitor defaultChannel (versi uji default) – Jika ada di capacitor.config.* dan tidak ada saluran paksa/override/local, aplikasi akan memulai pada saluran ini (misalnya beta, qa, pr-123. Bisa digunakan untuk versi uji / build internal sehingga tester langsung berada di saluran pre-release. Build produksi biasanya tidak mengatur ini.
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 terhubung ke sini. Ubahnya untuk mengeluarkan atau mengembalikan secara instan—tidak perlu binary baru. Jika Anda memiliki default platform khusus (misalnya satu untuk iOS, satu untuk Android, satu untuk Electron), setiap perangkat akan terhubung ke default yang sesuai dengan platformnya. Mengosongkan saluran default cloud memungkinkan; dalam hal ini perangkat harus menyesuaikan langkah 1–4 untuk menerima update.

Praktik terbaik:

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

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

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

Console dan API override akan berakhir setelah 90 hari

Pemetaan paksa dan pengaturan Dashboard atau saluran publik API disimpan sebagai penugasan per-perangkat di Capgo. Sebuah pekerjaan pembersihan menghapus penugasan tersebut 90 hari setelah tulisan terakhir overrideMemeriksa pembaruan tidak akan mengatur ulang jam tersebut. Hanya menulis ulang override (atau menghapusnya sendiri) yang mengubah timestamp.

Ini bukan sama dengan penyimpanan inventori perangkat. Inventori menghapus perangkat yang tidak terhubung ke Capgo selama 90 hari. Pembersihan override menghapus mapean bahkan jika perangkat masih aktif.

Untuk pengaturan yang tidak dihapus oleh pembersihan ini:

Set defaultChannel dalam capacitor.config.* (tetap setelah reinstall; memerlukan binary native baru untuk mengubahnya nanti).
Panggil setChannel() context setChannel() HTML text fragment from a longer Capgo UI string (parent key `appflow_migration_step2`). Page/area: Appflow comparison / migration marketing copy. Role: Website copy sentence. Seen in: page ionic-appflow.astro. Preserve Capgo product/brand and developer terms exactly. Message key `appflow_migration_step2` (Appflow Migration Step2).

Saluran Perangkat Tab perangkat dan pengaturan perangkat yang dapat diatasi hanya menampilkan konsol dan pengaturan publik API. Mereka tidak menampilkan setiap perangkat di saluran, dan mereka tidak menampilkan perangkat lokal setChannel() Pengaturan perangkat

Pengaturan perangkat Capgo tab saluran menampilkan popover penyimpanan pengaturan: pengaturan konsol akan berakhir setelah 90 hari — Pengingat penyimpanan pengaturan pada tab perangkat saluran

Behavior Saluran Bawaan

Pengaturan saluran awan adalah opsional, tetapi biasanya berfungsi sebagai jalur default untuk perangkat baru. Tanpa satu, hanya perangkat yang sesuai dengan petaan paksa, pengaturan pengganti, atau __CAPGO_KEEP_0__ konfigurasi akan menerima pembaruan. Ketika Anda memilih untuk menandai default, jangan lupa mempertimbangkan pola-pola berikut: defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

– Jika saluran memiliki iOS, Android, dan Electron diaktifkan, maka menjadi saluran default tunggal; perangkat tanpa pengaturan pengganti akan menempel di sini. Pengaturan default tunggal (yang paling umum)
Default 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.

Pahami bahwa default awan dan defaultChannel kedua berada di lapisan keputusan yang sama. Jika Anda menetapkan default awan, Anda tidak perlu mengulangi nilai di konfigurasi __CAPGO_KEEP_0__ Anda—biarkan capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel untuk biner yang Anda sengaja kirimkan kepada tester atau QA ketika Anda ingin mereka memulai pada saluran non-produksi bahkan jika default awan berbeda. defaultChannel Anda dapat mengubah default kapan saja di dashboard. Buka saluran, kemudian

Pengaturan Aplikasi Pengaturanyang membawa Anda ke Informasi Aplikasi. Default tidak lagi toggle pada halaman saluran. 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 kapan saja. Untuk menambahkan saluran tambahan kemudian:

Kunjungi bagian “Saluran” dari Capgo dashboard
Klik tombol “Saluran Baru”
Masukkan nama untuk saluran dan klik “Buat”

Nama saluran dapat apa saja yang Anda inginkan. Strategi umum adalah untuk menyesuaikan nama saluran dengan tahapan pengembangan Anda, seperti:

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

Konfigurasi Saluran di Aplikasi Anda

Dengan saluran Anda telah dibuat, Anda perlu mengonfigurasi aplikasi untuk mendengarkan saluran yang tepat. Dalam contoh ini, kita akan menggunakan saluran. Development Buka file

(atau capacitor.config.ts ) di editor Anda. Di bawah bagian capacitor.config.jsonopsionalnya atur plugins untuk defaultChannel builds uji coba Konfigurasi Saluran di Aplikasi Anda Untuk build produksi, lebih baik dihilangkan sehingga perangkat menggunakan Default Cloud 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.
    },
  },
};

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.

Opsi dan Strategi Saluran

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

Saluran default: Opsi untuk menandai saluran atau saluran khusus platform yang perangkat baru terhubung ke. Di konsol, ini berada di App Information (Konfigurasi di Pengaturan Aplikasi di halaman saluran). Lihat “Pengaturan Saluran Default” untuk skenario routing.
Pengatur filter platform: Aktifkan atau nonaktifkan pengiriman ke iOS, Androidatau Electron perangkat per saluran.
Matikan auto downgrade di native: Menghalangi pengiriman update ketika versi aplikasi native perangkat lebih baru dari bundle saluran (misalnya, perangkat pada 1.2.3 sementara saluran memiliki 1.2.2).
Biarkan build pengembangan: Izinkan update ke build pengembangan (bermanfaat untuk tes). CLI: --dev / --no-dev.
Biarkan bangun produksi: Izinkan pembaruan ke bangun produksi (toko) . Biarkan ini aktif untuk saluran yang melayani pengguna nyata. CLI: --prod / --no-prod.
Biarkan perangkat emulator: Izinkan pembaruan ke emulator/simulator (bermanfaat untuk pengujian). CLI: --emulator / --no-emulator.
Biarkan perangkat fisik: Izinkan pembaruan ke ponsel dan tablet nyata. Biarkan ini aktif untuk saluran produksi. CLI: --device / --no-device.
Biarkan perangkat menugaskan diri sendiri: Biarkan aplikasi berganti ke saluran ini pada waktu runtime menggunakan setChannelJika dinonaktifkan, setChannel akan gagal untuk saluran ini. CLI: --self-assign / --no-self-assign.
Paket pembaruan: Pilih apakah perangkat mengunduh zip penuh, delta file yang berubah, atau kedua-duanya (all, zip, delta, zip_from_builtin, delta_from_builtinLihat Paket pembaruan untuk dropdown konsol dan ketika setiap mode berguna.

Rollout progresif

Akan tetapi, saluran ini dapat menjaga bundle stabil sambil secara bertahap menampilkan target peluncuran yang terpisah kepada kelompok perangkat yang menempel. Anda dapat menghentikan, melanjutkan, mempromosikan, mengembalikan, dan mengkonfigurasi respons gagal otomatis tanpa mengganti saluran untuk semua orang. Lihat Rollout Progresif untuk model pengiriman, alur kerja dashboard, API bidang, dan CLI perintah.

Nonaktifkan Strategi Auto Update

Pilih untuk membatasi jenis update apa saja yang akan disampaikan oleh saluran secara otomatis. Pilihan:

besar: Menghalangi bundle target yang memiliki versi besar lebih tinggi dari dasar versi native perangkat (version_buildContoh: 1.2.3 -> 2.0.0 dihalangi; 1.2.3 -> 1.9.0 diizinkan.
kecil: Menghalangi bundle target yang memiliki versi besar atau kecil yang berbeda dari version_buildContoh: 1.2.3 -> 1.3.0 terblokir; 1.2.3 -> 1.2.4 diizinkan.
patch: Mode ketat. Menghalangi perubahan apa pun pada nomor mayor, minor, atau patch. Hanya perubahan sufiks yang diizinkan saat MAJOR.MINOR.PATCH tetap identik. Contoh: 1.0.0-beta.1 -> 1.0.0-beta.2 diizinkan; 1.0.0+build.1 -> 1.0.0+build.2 diizinkan; 1.0.0 -> 1.0.1 terblokir.
metadata: Memerlukan versi update minimum metadata pada setiap bundle. Konfigurasi melalui CLI menggunakan --min-update-version atau --auto-min-update-versionJika tidak ada, saluran tersebut akan ditandai sebagai tidak terkonfigurasi dan pembaruan akan ditolak sampai diatur.
semua pembaruan sesuai dengan kompatibilitas semver.

Strategi ini membandingkan bundle target saluran dengan basis native yang dikirimkan sebagai version_build, bukan bundle yang diunduh saat ini yang dikirimkan sebagai version_name.

Untuk mengetahui detail lebih lanjut dan contoh, lihat Disable updates strategy di /docs/cli/commands/#disable-updates-strategy.

Contoh (CLI). Saluran harus sudah ada (channel set tidak akan dibuat):

# 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

# Production channel: store builds on real devices, no emulators
npx @capgo/cli@latest channel set production com.example.app --prod --device --no-emulator

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

The
Alur pendaftaran beta
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
});

Kapan setChannel() dipanggil:

Validasi backend (hanya baca): Dikirim permintaan ke Capgo backend untuk memvalidasi apakah channel diizinkan (mengatur izin pengaturan sendiri)
Perbarui penyimpanan lokal: Jika validasi berhasil, channel disimpan ke penyimpanan lokal perangkat sebagai defaultChannel
Effek instan: Periksa update selanjutnya menggunakan saluran baru langsung (tidak menunggu replikasi)

Mengapa ini penting: Pada versi lama, setChannel() menghemat pengaturan saluran ke database backend (sama seperti Dashboard atau perubahan 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, membuat perubahan saluran instan.

Ketersediaan Dashboard: Pengaturan saluran yang ditetapkan dengan plugin tidak membuat perangkat muncul sebagai Pengaturan Perangkat di Capgo UI. Hanya pengaturan saluran yang dibuat dari dashboard atau API yang terdaftar di sana. Gunakan dashboard atau API ketika Anda membutuhkan pengaturan override yang dapat dilihat oleh administrator.

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

Pembandingan metode perubahan saluran:

Metode	Waktu Efek	Dimana Data Dijaga	Ditampilkan di Pengaturan Perangkat	Masa Berlaku	Penggunaan Kasus
`setChannel()` Ketika: Halaman/area: Halaman pemasaran solusi Capgo. Peran: Label UI singkat atau item navigasi. Dilihat di: halaman solusi/cordova-to-capacitor-ai.astro. Kunci pesan `solutions_cordova_to_capacitor_ai_table_use_case` (Solutions Cordova To Capacitor Ai Table Use Case).	Dari Plugin	Instan	Hanya Perangkat (Local)	Tidak	Tidak (sampai Anda mengubahnya atau menginstal ulang)
Pengguna mengganti saluran secara langsung dalam aplikasi ini	Maksimal 2 menit	Database backend	Ya	90 hari setelah tulisan override terakhir	Perubahan admin untuk perangkat tertentu
Penugasan API channel	Maksimal 2 menit	Database backend	Ya	90 hari setelah tulisan override terakhir	Integrasi backend otomatis

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

Versi minimum untuk mengaktifkan saluran lokal saja: 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 instalasi plugin untuk tag versi.

Menetapkan Paket ke Saluran

Untuk mengaktifkan pembaruan live, Anda perlu mengunggah bundle JS baru dan menetapkannya 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 menetapkan bundle baru sebagai build aktif untuk Development saluran. Aplikasi-aplikasi yang dikonfigurasi untuk mendengarkan saluran tersebut akan menerima pembaruan pada saat mereka memeriksa untuk mendapatkan pembaruan berikutnya.

Kamu 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 Paket dan Saluran

Penting untuk dicatat bahwa paket-paket di Capgo bersifat global untuk aplikasi kamu, 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 saluran. Misalnya, rilis beta mungkin diberi versi sebagai 1.2.3-beta.1.

Saat CI, jika versi lokal sudah diunggah, gunakan npx @capgo/cli@latest bundle upload --auto-bump (opsional) major, minor, patch/fix, metadata, atau ai) sehingga CLI mengganti dari saluran terkait paket sampai nama yang gratis ditemukan. Dengan aiWorkers AI mengestimasi tingkat dari manifest lokal vs delta sebelumnya (jatuh kembali ke patch dengan tidak ada versi Capgo sebelumnya). Anda tidak dapat menggabungkannya dengan --bundle. Lihat Integrasi CI/CD context: Halaman/area: Capgo Builder / produk halaman cloud native. Peran: Label UI singkat atau item navigasi. Kunci pesan `native_build_feature_ci_cd` (Native Build Feature Ci Cd). CLI reference.

__CAPGO_KEEP_0__

Metode ini memiliki beberapa keuntungan: 1.2.3-beta.1 Memungkinkan komunikasi yang jelas tentang hubungan antara build. 1.2.3.
jelas merupakan rilis pra-
Memungkinkan penggunaan nomor versi yang sama di beberapa saluran, mengurangi kebingungan. 1.2.3Mengaktifkan jalur rollback yang jelas. Jika Anda perlu kembali dari 1.2.2 adalah rilis stabil sebelumnya.

Contoh berikut menunjukkan cara mengatur versi bundle Anda dengan pengaturan kanal biasa:

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

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 berpadu dengan proses pengembangan tim Anda.

Rolling Back Update Hidup

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

Klik nama saluran yang ingin Anda kembali
Cari build yang ingin Anda kembali dan klik ikon mahkota
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 Pengiriman

Untuk alur kerja yang lebih maju, Anda dapat mengautomasi pengiriman update hidup sebagai bagian dari pipeline CI/CD Anda. Dengan mengintegrasikan Capgo ke dalam proses build Anda, Anda dapat secara otomatis mengunggah bundle baru dan menugaskan ke saluran pada saat Anda memasukkan perubahan ke branch tertentu atau membuat rilis baru.

Periksa informasi tentang Integrasi CI/CD docs untuk mempelajari lebih lanjut tentang otomatisasi pembaruan hidup Capgo.

Pratinjau PR dengan hak istimewa

Pakai Pratinjau Aplikasi Gunakan kunci __CAPGO_KEEP_0__ ketika CI memerlukan satu saluran sementara per pull request, tetapi tidak harus mengelola saluran utama/default yang ada. Kunci tetap terkait dengan organisasi dan aplikasi yang dimiliki; hanya saja tidak memiliki peran organisasi. Setiap saluran pratinjau non-umum yang dibuat menerima hak keamanan otomatis, yang berlaku pada tingkat saluran. Biarkan administrator organisasi membuat kunci API yang aman dan terbatas hanya pada aplikasi pratinjau. Pilih

Have an organization administrator create a secure API key limited to the preview app and select . LihatKunci __CAPGO_KEEP_0__ Kunci API.
Gunakan saluran unik, tidak publik seperti pr-123Tidak lakukan --default, --self-assign, opsi peluncuran, atau --delete-linked-bundle-on-upload.
Upload dan promosikan bundle PR dalam satu perintah, kemudian hapus saluran dan bundle yang dimiliki ketika PR ditutup:

APP_ID="com.example.app"
PREVIEW_CHANNEL="pr-123"
BUNDLE_VERSION="1.2.3-pr.123"

npx @capgo/cli@latest bundle upload "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "$PREVIEW_CHANNEL" \
  --bundle "$BUNDLE_VERSION"

npx @capgo/cli@latest channel delete "$PREVIEW_CHANNEL" "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found

bundle upload --channel Membuat saluran yang hilang, mengunggah bundle, dan mempromosikannya dalam satu aliran. Pembersihan atomik dan diperiksa kepemilikan: kunci dapat menghapus hanya saluran yang dibuatnya dan bundle yang terkait, tidak berbagi. Kunci tersebut tidak dapat mengubah, mempromosikan, atau menghapus saluran utama/default, saluran lainnya yang diprediksi kunci lain, atau bundle milik kunci lain.

Jika para reviewer membutuhkan QR code atau URL pratinjau, administrator harus mengaktifkan pratinjau sekali untuk aplikasi:

npx @capgo/cli@latest app set "$APP_ID" --preview
npx @capgo/cli@latest get-qr "$APP_ID" --channel "$PREVIEW_CHANNEL" --apikey "$CAPGO_PREVIEW_KEY" --url

Kunci Pratinjau Aplikasi tidak dapat mengaktifkan pratinjau sendiri karena tidak memiliki izin pengaturan aplikasi. Di GitHub Actions, jalankan pekerjaan pratinjau yang membawa rahasia pada pull_request, bukan pull_request_targetdan batasi mereka ke PR yang sama repository dengan github.event.pull_request.head.repo.full_name == github.repository.

Menjalankan ke Perangkat

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

Instal Capgo SDK di aplikasi Anda
Konfigurasi aplikasi untuk mendengarkan saluran yang diinginkan Anda
Unggah build dan alokasikan ke saluran tersebut
Jalankan aplikasi dan tunggu pembaruan!

Untuk walkthrough yang lebih rinci, lihatlah Pembaruan Hidup guide. Selamat membarui!

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
Rollout fitur secara bertahap
Program uji coba beta

Belajar cara menerapkan kasus penggunaan lanjutan ini dalam panduan kami: Bagaimana Membagi Pengguna Berdasarkan Paket dan Saluran untuk Flag-Fitur dan Pengujian A/B.

Teruskan dari Saluran

Jika Anda menggunakan Saluran Untuk merencanakan routing saluran dan peluncuran tahap demi tahap, hubungkannya dengan Saluran context":"Capgo fitur nama saluran rilis. Halaman/area: Halaman pemasaran solusi Capgo. Peran: Label UI singkat atau item navigasi. Dilihat di: halaman solusi/white-label.astro. Kunci pesan `solutions_white_label_visual_cell2_value` (Solutions White Label Visual Cell2 Value)." untuk detail implementasi di Saluran, Saluran context":"Capgo fitur nama saluran rilis. Halaman/area: Halaman pemasaran solusi Capgo. Peran: Label UI singkat atau item navigasi. Dilihat di: halaman solusi/white-label.astro. Kunci pesan `solutions_white_label_visual_cell2_value` (Solutions White Label Visual Cell2 Value)." untuk detail implementasi di Saluran, Solusi Pengujian Beta untuk alur kerja produk di Solusi Pengujian Beta, Capgo Environment Best Practices: Staging with One Mobile App ID for the practical context in Capgo Environment Best Practices: Staging with One Mobile App ID.