Saluran

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 apa pun yang dikonfigurasi ke saluran tersebut akan memeriksa pembaruan yang tersedia setiap kali aplikasi diluncurkan. Anda dapat mengubah bangunan yang dipilih oleh saluran kapan saja dan juga dapat kembali ke bangunan sebelumnya jika diperlukan.

Saluran Tidak Menyediakan Rahasia

Saluran mengontrol kelayakan pembaruan, bukan rahasia paket. Bahkan jika saluran privat atau pengaturan pengasasan sendiri dinonaktifkan, paket tidak terenkripsi yang diunggah ke Capgo masih harus dianggap sebagai aset publik yang disampaikan ke klien. Pengaturan Saluran (Prioritas) Bagian berjudul “Pengaturan Saluran (Prioritas)”

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

– Pasang ID perangkat 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 penggantian.

1. Pengaturan Langganan di Cloud (per-perangkat) melalui Dashboard atau __CAPGO_KEEP_0__ – Dibuat ketika Anda mengubah saluran perangkat di dashboard atau melalui Capgo. Gunakan untuk pengguna QA yang beralih antara saluran fitur / PR atau untuk mereproduksi masalah pengguna. Menginstal ulang binary tidak menghapusnya; menghapus pengaturan perangkat menghapusnya. Retensi 90 hari yang sama berlaku. Console and API overrides expire after 90 days.
2. Cloud override (per-device) via Dashboard or API Console and API overrides expire after 90 days
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 di perangkat tersebut, berlaku segera, dan tidak ditampilkan di UI Pengaturan Perangkat.

Switching Saluran Instan dengan setChannel()

Mulai dari versi plugin 5.34.0, 6.34.0, 7.34.0, atau 8.0.0 (tergantung pada versi utama Anda), 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 hanya lokal, 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 dipertahankan.

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 memvalidasi dengan backend, kemudian mengatur saluran lokal untuk efek segera.

4. 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.
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 terhubung ke sini. Ubahnya 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 terhubung ke default yang sesuai dengan platformnya. Mengosongkan saluran default cloud memungkinkan; dalam hal ini perangkat harus sesuai dengan 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 pengguna terhubung dengan sengaja (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.
• Pilih setChannel() Pilih

secara berhati-hati di produksi—utamanya untuk QA atau diagnostik yang sasaran.

Summary: Force > Dashboard/API Override > Plugin setChannel() Ringkasan: Paksa > Dashboard/__CAPGO_KEEP_0__ Override > Plugin defaultChannel saluran lokal > Konfigurasi

Console and API overrides expire after 90 days

Forced mappings and Dashboard or Public API channel overrides are stored as per-device assignments in Capgo. A cleanup job deletes those assignments 90 hari setelah tulisan terakhir overrideMemeriksa update tidak akan mengatur ulang jam itu. Hanya menulis ulang override (atau menghapusnya sendiri) yang mengubah timestamp.

Ini bukan sama dengan Penghapusan inventori perangkat. Inventory removes devices that have not connected to Capgo for 90 days. Override cleanup removes the mapping even if the device is still active.

Untuk pengalihan yang tidak dihapus oleh penghapusan 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 Override hanya menampilkan konsol dan pengaturan publik API. Mereka tidak menampilkan setiap perangkat di saluran, dan mereka tidak menampilkan perangkat lokal setChannel() Pengaturan perangkat

Pengingat penyimpanan Override di tab perangkat Saluran

Behavior Saluran Bawaan

Pengaturan default di awan adalah opsional, tetapi biasanya berfungsi sebagai jalur default untuk perangkat baru. Tanpa satu, hanya perangkat yang sesuai dengan petaan paksa, pengaturan Override, atau yang ada di __CAPGO_KEEP_0__ konfigurasi yang 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 Override akan menempel di sana. 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

Kelola di Pengaturan Aplikasi Manage in App settingsyang membawa Anda ke Informasi Aplikasi. Default tidak lagi merupakan toggle pada halaman saluran. Ketika Anda mengganti default, perangkat baru mengikuti routing baru secara langsung 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 memberi nama saluran tersebut “Produksi”), tetapi tidak ada yang terkunci—Anda dapat mengubah nama atau menghapus saluran kapan saja. Untuk menambahkan saluran tambahan kemudian:

1. Kunjungi bagian “Saluran” dari Capgo dashboard
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 Anda, seperti:

• Development - untuk menguji pembaruan hidup pada perangkat lokal atau emulator
• QA - untuk tim QA Anda untuk memverifikasi pembaruan 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 mendengar saluran yang tepat. Dalam contoh ini, kita akan menggunakan saluran. Development Buka file

(atau capacitor.config.ts ) di bawah bagian capacitor.config.jsonopsionalnya atur plugins untuk defaultChannel build uji coba build uji coba (internal / QA). Untuk pembangunan produksi, prefer menghilangkan itu sehingga perangkat menggunakan Default Cloud kecuali secara eksplisit diaturnya.

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 telah dikonfigurasi sebelumnya.

Peringatan

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

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

Anda masih bisa memaksa (menempel) perangkat atau menerapkan pengaturan override kemudian—yang langsung mengalahkan nilai konfigurasi.

Nama saluran sangat sensitif terhadap huruf besar kecil.

Opsi dan Strategi Saluran

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

• Saluran bawaan: Opsional untuk menandai saluran atau saluran khusus platform yang perangkat baru terhubung ke. Di konsol ini hidup di Informasi Aplikasi (Kelola di Pengaturan Aplikasi dari halaman saluran). Lihat “Pengaturan Saluran Bawaan” untuk skenario routing.
• Filter platform: Aktifkan atau nonaktifkan pengiriman ke iOS, Androidatau Electron perangkat per saluran.
• Matikan auto downgrade di 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).
• Biarkan build pengembangan: Izinkan pembaruan 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 tes). 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 (" ). Lihat all, zip, delta, zip_from_builtin, delta_from_builtinPaket pembaruan untuk dropdown konsol dan ketika setiap mode berguna. Rollout progresif

Judul bagian "Rollout progresif"

A channel dapat menjaga bundle stabil sambil secara bertahap menampilkan target rollout terpisah ke kohort perangkat yang menempel. Anda dapat menghentikan, melanjutkan, mempromosikan, mengembalikan, dan mengkonfigurasi respons gagal otomatis tanpa mengganti channel untuk semua orang. Lihat Rollout Progresif untuk model pengiriman, alur kerja dashboard, API bidang, dan CLI perintah.

Nonaktifkan Strategi Perbarui Otomatis

Pakai ini untuk membatasi jenis-jenis perbarui yang channel akan mengirim secara otomatis. Pilihan:

• besar: Menghalangi bundle target yang versi mayor lebih tinggi dari basislinen perangkat asli (version_buildContoh: 1.2.3 -> 2.0.0 terhalang; 1.2.3 -> 1.9.0 boleh.
• kecil: Menghalangi bundle target yang versi mayor atau kecil berbeda dari version_buildContoh: 1.2.3 -> 1.3.0 diblokir; 1.2.3 -> 1.2.4 diperbolehkan.
• patch: Mode ketat. Blokir setiap perubahan pada nomor mayor, minor, atau patch. Hanya perubahan sufiks yang diperbolehkan saat MAJOR.MINOR.PATCH tetap sama. 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: Tuntut 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 update akan ditolak sampai diatur.
• semua: Izinkan semua update 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 memahami detail dan contoh lebih lanjut, 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
});

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

Kapan setChannel() dipanggil:

1. Validasi backend (hanya baca): Permintaan dikirim 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. Effek instan: Periksa update selanjutnya menggunakan saluran baru segera (tidak menunggu replikasi)

Kenapa ini penting: Dalam versi lama, setChannel() menghemat pengaturan saluran override ke database backend (sama seperti Dashboard atau API perubahan). 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 Public API yang terdaftar di sana. Gunakan dashboard atau API ketika Anda memerlukan 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 Diperlukan	Ditampilkan di Pengaturan Perangkat	Masa Berlaku	Penggunaan Kasus
setChannel() Konteks: Halaman/area: Halaman pemasaran solusi Capgo. Peran: Label UI singkat atau item navigasi. Dilihat di: halaman solusi/cordova-to-capacitor-ai.astro.	Dari Plugin	Instan	Hanya Perangkat (Local)	Tidak	Tidak (sampai Anda mengubahnya atau menginstal ulang)
Penggantian saluran pengguna di dalam aplikasi secara langsung di dashboard	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 terbaik saat 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 Pemasangan plugin untuk tag versi.

Pengaturan Saluran ke Paket

Untuk mengaktifkan pembaruan live, Anda perlu mengunggah bundle JS baru dan mengasosiasikannya dengan 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 saluran. Development saluran. Aplikasi-aplikasi yang telah 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 adalah 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 mengupdate dari paket saluran yang terkait hingga menemukan nama yang gratis. aiWorkers AI menentukan tingkat dari manifest lokal vs delta sebelumnya (jatuh kembali ke patch tanpa versi Capgo sebelumnya). Anda tidak dapat menggabungkannya dengan --bundle. Lihat Integrasi CI/CD context: Halaman/area: Capgo Builder / produk halaman pembangunan asli cloud. Peran: Label UI singkat atau item navigasi. Pesan kunci `native_build_feature_ci_cd` (Fitur Pembangunan Asli Ci Cd). dan referensi CLI.

Metode ini memiliki beberapa keuntungan:

• Memudahkan komunikasi hubungan antara bangun. 1.2.3-beta.1 jelas merupakan rilis pra sebelumnya dari 1.2.3.
• Mengizinkan penggunaan nomor versi ulang di kanal, mengurangi kebingungan.
• Mengaktifkan jalur rollback yang jelas. Jika Anda perlu kembali dari 1.2.3, Anda tahu 1.2.2 merupakan rilis stabil sebelumnya.

Contoh berikut menunjukkan cara mengatur 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 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 a Live Update

Klik nama saluran yang ingin Anda kembali ke

1. Cari build yang ingin Anda kembali ke dan klik ikon mahkota
2. Kembali ke build
3. Build yang dipilih akan langsung menjadi build aktif untuk saluran tersebut lagi. Aplikasi akan menerima versi yang dikembalikan pada saat mereka memeriksa pembaruan berikutnya.

Automating Deployments

Bagian berjudul “Automating Deployments”

For more advanced workflows, you can automate your live update deployments as part of your CI/CD pipeline. By integrating Capgo into your build process, you can automatically upload new bundles and assign them to channels whenever you push to certain branches or create new releases.

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

Pratinjau PR dengan hak istimewa terendah

Pakai Pratinjau Aplikasi API kunci ketika CI memerlukan satu saluran sementara per PR tetapi tidak boleh mengelola saluran utama/default yang ada. Kunci tetap terkait dengan organisasi dan aplikasi yang dipilih; hanya tidak memiliki peran organisasi. Setiap saluran pratinjau non-umum yang dibuat menerima hak hidup otomatis, berlaku pada saluran.

1. Miliki administrator organisasi untuk membuat kunci API yang aman dan terbatas hanya pada aplikasi pratinjau dan pilih Pratinjau Aplikasi. Lihat API Kunci.
2. Gunakan saluran unik, tidak publik seperti pr-123Tidak lakukan --default, --self-assign, opsi peluncuran, atau --delete-linked-bundle-on-upload.
3. 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 yang ada, saluran lain dari kunci pratinjau, atau bundle milik kunci lain.

Jika 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-repositori dengan github.event.pull_request.head.repo.full_name == github.repository.

Deploying ke Perangkat

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

1. Instal Capgo SDK di aplikasi Anda
2. Konfigurasi aplikasi untuk mendengarkan saluran yang diinginkan Anda
3. Unggah bangun dan tugaskan ke saluran yang diinginkan
4. Jalankan aplikasi dan tunggu pembaruan!

Untuk walkthrough yang lebih rinci, lihat Deploying Live Updates 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
• 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.

Lanjutkan dari Saluran

Jika Anda menggunakan Saluran untuk merencanakan routing saluran dan peluncuran tahap demi tahap, hubungkannya dengan Saluran context: Fitur nama saluran rilis Capgo. 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` (Nilai Sel Visual Putih Label Solusi). untuk detail implementasi di Saluran, Saluran context: Fitur nama saluran rilis Capgo. 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` (Nilai Sel Visual Putih Label Solusi). 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.