Saluran

Saluran Pembaruan Hidup menunjuk ke bangunan kode JS tertentu dari aplikasi Anda yang akan dibagikan dengan perangkat apa pun yang telah dikonfigurasi untuk mendengarkan saluran tersebut untuk pembaruan. Ketika Anda menginstal Capgo Pembaruan Hidup SDK dalam aplikasi Anda, setiap biner native yang dikonfigurasi ke saluran tersebut akan memeriksa pembaruan yang tersedia setiap kali aplikasi diluncurkan. Anda dapat mengubah bangunan yang ditunjuk oleh saluran pada saat apapun dan juga dapat kembali ke bangunan sebelumnya jika perlu.

Saluran Tidak Menyediakan Rahasia

Saluran mengontrol kelayakan pembaruan, bukan rahasia paket. Bahkan jika saluran privat atau pengaturan pengasosiasi sendiri dinonaktifkan, paket apa pun yang tidak dienkripsi yang diunggah ke Capgo masih harus dianggap sebagai aset publik yang disampaikan ke klien. Pengenkripsi melindungi jalur pengiriman dan keaslian pembaruan, tetapi paket yang dikirimkan masih dapat direkayasa balik dari aplikasi yang didistribusikan dengan usaha yang cukup karena kunci publik adalah bagian dari klien. Lihat Pengenkripsi Pembaruan Hidup Untuk informasi lebih lanjut.

Bagaimana perangkat memilih saluran (prioritas)

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

1. Peta perangkat paksa (Dashboard) – Menempatkan ID perangkat tertentu secara manual ke dalam saluran. Gunakan untuk debugging darurat atau pengujian terkendali dengan pengguna asli tunggal. Ini selalu menang.
2. Tetapkan ulang di awan (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 mengulangi masalah pengguna. Menginstal ulang binary tidak menghapusnya; menghapus entri perangkat melakukan.
3. Plugin setChannel() saluran lokal – Dibuat ketika aplikasi memanggil setChannel() dan backend memvalidasi bahwa saluran target memungkinkan penugasan sendiri. Saluran yang dipilih disimpan secara lokal pada perangkat, berlaku segera, dan tidak ditampilkan di UI Penggantian Perangkat.

Switch Channel 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 memvalidasi apakah channel tersebut diizinkan (mengatur apakah pengaturan self assignment diaktifkan untuk channel tersebut), kemudian menyimpan channel secara lokal di perangkat sebagai defaultChannel. Ini berarti channel baru akan efektif langsung untuk cek update berikutnya—tidak perlu menunggu replikasi.

Sebelumnya, setChannel() menghematkan pengaturan saluran ke database backend (seperti Dashboard atau perubahan API), 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, sehingga perubahan saluran instan.

Karena setChannel() hanya lokal, itu tidak membuat entri Pengaturan Perangkat di Capgo dashboard. UI Pengaturan Perangkat hanya menampilkan pengaturan yang dibuat dari dashboard atau Public API.

Perhatian: Meskipun saluran menjadi tidak diizinkan setelah diatur secara lokal, backend akan masih melakukan validasi saluran selama cek pembaruan, sehingga keamanan tetap terjaga.

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

4. Capacitor config defaultChannel (test build default) – Jika ada di capacitor.config.* dan tidak ada force/override/local channel yang ada, aplikasi dimulai pada channel ini (misalnya) beta, qa, pr-123. Bisa digunakan untuk TestFlight / build internal sehingga tester langsung berada di channel pre-release. Build produksi biasanya tidak mengatur ini.
5. Channel Utama Cloud (jalan utama ~99% pengguna) – Jika Anda menandai channel default di dashboard, semua pengguna normal (tidak ada force, tidak ada Dashboard/API override, tidak ada plugin local channel, tidak ada konfigurasi defaultChannel) akan menghubungkan ke sini. Ubahnya untuk mengeluarkan atau mengembalikan secara instan—tidak ada binary baru. Jika Anda memiliki default platform khusus (misalnya, satu untuk iOS, satu untuk Android, satu untuk Electron), setiap perangkat akan menghubungkan ke default yang sesuai dengan platformnya. Mengosongkan default cloud tidak diizinkan; dalam hal itu, perangkat harus sesuai dengan langkah-langkah 1–4 untuk menerima update.

Praktik terbaik:

• Tangani 1–4 sebagai lapisan kecuali / pengujian; ketika Anda menetapkan default cloud, pengguna nyata harus mengalir ke dalamnya. Jika Anda tidak menetapkan satu, pastikan Anda sengaja tentang bagaimana pengguna menghubungkan (biasanya melalui) defaultChannel Hanya konfigurasi
• di binary yang Anda kirim secara eksplisit kepada tester. Mengosongkannya menjaga logika produksi tetap terkonsentrasi di dashboard. defaultChannel Gunakan
• – Jika tidak ada force/override/local channel yang ada, aplikasi dimulai pada channel ini (misalnya) setChannel() secara terbatas dalam produksi—utamanya untuk QA atau diagnostik yang sasaran.

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

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

Behavior Saluran Bawaan

Mengatur default cloud adalah opsional, tetapi biasanya berfungsi sebagai jalur utama untuk perangkat baru. Tanpa salah satu, hanya perangkat yang sesuai dengan pemetaan paksa, override, atau defaultChannel di konfigurasi Capacitor yang akan menerima update. Ketika Anda memilih untuk menandai default, jangan lupa mempertimbangkan pola-pola berikut:

• Default tunggal (yang paling umum) – Jika sebuah saluran memiliki iOS, Android, dan Electron diaktifkan, maka menjadi default tunggal; perangkat apa pun tanpa 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 pergi ke default iOS, perangkat Android pergi ke default Android, dan aplikasi Electron 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 menggandakan 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. Ketika Anda mengganti default, perangkat baru mengikuti routing baru segera dan perangkat yang ada mengikuti aturan keutamaan normal ketika mereka memeriksa kembali.

Pengaturan Saluran

Pengaturan Saluran

Selama proses onboarding Anda membuat saluran pertama (banyak tim menyebutnya “Produksi”), tetapi tidak ada yang terkunci—Anda dapat menamai atau menghapus saluran kapan saja. Untuk menambahkan saluran tambahan kemudian:

1. Pergi ke 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 mencocokkan 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 rilis yang lebih luas
• Staging - untuk pengujian akhir di lingkungan produksi yang mirip
• Production - untuk versi aplikasi yang diterima oleh pengguna akhir dari toko aplikasi

Mengonfigurasi Saluran di Aplikasi Anda

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

Buka aplikasi Anda capacitor.config.ts atau capacitor.config.json) file. Di bawah bagian plugins section, Anda dapat memilih untuk mengatur defaultChannel untuk uji coba (internal / QA). Untuk build produksi, lebih baik tidak mengatur ini agar perangkat menggunakan Default Cloudflare 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 telah diatur sebelumnya.

Peringatan

Pilih urutan saluran: Paksa > Dashboard/API pengaturan perangkat > Plugin setChannel() saluran lokal > Konfigurasi defaultChannel > Default Cloud.

Pilih defaultChannel Hanya gunakan dalam build internal/test; tinggalkan untuk produksi agar pengguna mengikuti Default Cloud (jika sudah ditetapkan) bukan mengulangi routing di konfigurasi native.

Anda masih bisa memaksa (menempel) perangkat atau menerapkan pengaturan pengganti kemudian—keduanya langsung mengalahkan 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. Yang paling penting adalah di bawah ini. Anda dapat mengonfigurasi hal ini dari aplikasi web, CLI, atau API publik.

• Saluran default: Opsionalnya tandai saluran atau saluran khusus platform yang perangkat baru terhubung ke. Lihat “Pengaturan Saluran Default” untuk skenario routing.
• Filter platform: Aktifkan atau nonaktifkan pengiriman ke iOS, Android, atau Electron perangkat per saluran.
• Matikan auto downgrade di native: Mencegah pengiriman pembaruan ketika versi aplikasi native perangkat lebih baru daripada 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).
• Biarkan perangkat emulator: Izinkan pembaruan ke perangkat emulator/simulator (bermanfaat untuk tes).
• Biarkan perangkat self-assignment: Biarkan aplikasi berganti ke saluran ini secara waktu nyata menggunakan setChannel. Jika dinonaktifkan, setChannel akan gagal untuk saluran ini.

Rollout Progresif

Saluran dapat menjaga bundle stabil sementara secara bertahap menampilkan target rollout terpisah ke kohort perangkat yang menempel. Anda dapat mematikan, melanjutkan, mempromosikan, mengembalikan, dan mengonfigurasi respons gagal otomatis tanpa mengganti saluran untuk semua orang. Lihat Pengiriman progresif untuk model pengiriman, alur kerja dashboard, API bidang, dan CLI perintah.

Nonaktifkan Strategi Perbarui Otomatis

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

• besar: Menghalangi paket target yang versi mayor lebih tinggi dari dasar native perangkat (version_buildContoh: 1.2.3 -> 2.0.0 ditolak; 1.2.3 -> 1.9.0 diizinkan.
• kecil: Menghalangi paket target yang versi mayor atau minor berbeda dari version_buildContoh: 1.2.3 -> 1.3.0 ditolak; 1.2.3 -> 1.2.4 diperbolehkan.
• patch: Mode yang paling 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 diperbolehkan. 1.0.0+build.1 -> 1.0.0+build.2 diperbolehkan. 1.0.0 -> 1.0.1 diblokir.
• 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 dianggap tidak terkonfigurasi dan pembaruan akan ditolak sampai diatur.
• semua: Izinkan semua pembaruan sesuai dengan kompatibilitas semver.

Strategi ini membandingkan bundle target saluran dengan dasar native yang dikirim sebagai version_buildJanganlah bundle yang telah diunduh saat ini, version_name.

Pelajari lebih lanjut dan contoh di Strategi Non-Update pada /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 penerimaan program beta
• Pengimplementasian flag fitur
• Saluran
• Skenario percobaan 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 saluran tersebut diizinkan (mengatur izin pengasasan sendiri)
2. Perbarui penyimpanan lokal: Jika validasi berhasil, saluran disimpan ke penyimpanan lokal perangkat sebagai defaultChannel
3. Efek instan: Periksa update selanjutnya menggunakan saluran baru segera (tidak menunggu replikasi)

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

Keterlihatan Dashboard: 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 admin.

Catatan keamanan: Meskipun hak akses saluran berubah setelah ditetapkan secara lokal (misalnya, pengaturan self-assignment dihapus), backend akan masih melakukan validasi saluran selama cek pembaruan, memastikan keamanan tetap terjaga.

Perbandingan metode perubahan saluran:

Metode	Waktu Efek	Ditahan Dimana	Ditampilkan di UI Pengaturan Perangkat	Penggunaan Kasus
setChannel() Kasus Penggunaan	dari plugin	Instan	Hanya Perangkat (local)	Tidak
Perubahan saluran pengguna di dalam aplikasi	Dashboard pengaturan perangkat	Sampai 2 menit	Database Backend	Ya
Penugasan API channel	Sampai dengan 2 menit	Database Backend	Iya	Integrasi Backend Otomatis

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

Versi minimum untuk penggantian channel lokal hanya: 5.34.0, 6.34.0, 7.34.0atau 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 termasuk fitur yang sama apapun X adalah 5, 6, 7, atau 8). Lihat instalasi plugin untuk tag versi.

Menugaskan Paket ke Saluran

Untuk mengaktifkan pembaruan live, Anda perlu mengunggah build paket JS baru dan menugaskannya ke saluran. Anda bisa melakukannya dalam satu langkah dengan Capgo CLI:

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

Langkah ini akan mengunggah aset web yang dibangun dan menetapkan build paket 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 menugaskan build ke saluran dari bagian “Paket” di __CAPGO_KEEP_0__ dashboard. Klik ikon menu di samping build dan pilih “Tugaskan 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.

Judul Bagian “Pengaturan Versi Paket dan Saluran”

It’s important to note that bundles in Capgo are global to your app, not specific to individual channels. The same bundle can be assigned to multiple channels.

__CAPGO_KEEP_0__ Pengaturan Versi Semantik dengan Capgo’s Tester Semver dan identifikasi pra-rilis untuk bangunan khusus saluran. Misalnya, rilis beta mungkin diberi versi sebagai 1.2.3-beta.1.

Pada 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 dari saluran terkait bundle meningkatkan hingga nama gratis ditemukan. Dengan ai, AI Workers menerka tingkat dari delta manifest lokal vs sebelumnya (jatuh kembali ke patch dengan tidak ada versi Capgo sebelumnya). Anda tidak dapat menggabungkannya dengan --bundle. Lihat Pengintegrasian CI/CD context: Halaman/area: Halaman Pembangun Capgo / produk halaman bangunan asli awan. Peran: Label UI pendek atau item navigasi. Kunci pesan `native_build_feature_ci_cd` (Fitur Bangunan Asli Ci Cd). dan referensi CLI.

Berikut beberapa kelebihan dari pendekatan ini:

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

Contoh berikut menunjukkan cara Anda mungkin mengatur versi bundle dengan setup saluran yang umum:

• 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.2, dan lain-lain.
• Production saluran: 1.2.3, 1.2.4, dan lain-lain.

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

Mengembalikan Live Update

Jika Anda mengunduh live update yang memperkenalkan bug atau perlu diubah, 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

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

Automasi Pengiriman

Untuk alur kerja yang lebih canggih, Anda dapat mengautomasi pengiriman pembaruan live update sebagai bagian dari pipeline CI/CD Anda. Dengan mengintegrasikan Capgo ke dalam proses build Anda, Anda dapat mengunggah bundle baru secara otomatis dan menugaskan saluran untuk setiap kali Anda push ke cabang tertentu atau membuat rilis baru.

Cari tahu lebih lanjut tentang Integrasi CI/CD docs to learn more about automating Capgo live updates.

baca dokumentasi untuk mengetahui lebih lanjut tentang mengautomasi pembaruan __CAPGO_KEEP_0__ live.

Bab yang berjudul “Penglihatan PR yang paling tidak berkekuatan” Penglihatan Aplikasi API digunakan ketika CI memerlukan satu saluran sementara per permintaan pull tetapi tidak harus mengelola saluran utama/default yang ada. Kunci ini tetap terikat pada organisasi pemilik dan aplikasi yang dipilih; hanya saja tidak memiliki peran organisasi yang luas. Setiap saluran pratinjau non-umum yang dibuat menerima izin kehidupan siklus otomatis, yang berlaku pada tingkat saluran.

1. Buatlah administrator organisasi membuat kunci API yang aman dan terbatas hanya pada aplikasi pratinjau dan pilih Penglihatan AplikasiLihat API Keys.
2. Gunakan saluran unik yang tidak umum seperti pr-123Jangan melewatkan --default, --self-assignopsi peluncuran, atau --delete-linked-bundle-on-upload.
3. Muat 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 adalah atomik dan diperiksa kepemilikan: kunci dapat menghapus hanya saluran yang dibuatnya dan bundle terkait yang tidak dibagikan. Ia tidak dapat mengubah, mempromosikan, atau menghapus saluran utama/default yang ada, saluran lain dari kunci pemeriksa, 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_target, dan keterbatasinya hanya pada PR yang sama-repositori dengan github.event.pull_request.head.repo.full_name == github.repository.

Mengirim 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 mendengarkan saluran yang diinginkan
3. Upload sebuah build dan alokasikan ke saluran tersebut
4. Luncurkan aplikasi dan tunggu pembaruan!

Untuk panduan yang lebih rinci, lihat Deploying Live Updates guide. Selamat berpembaruan!

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 menerapkan kasus penggunaan yang lebih maju dalam panduan kami: Bagaimana cara membagi pengguna berdasarkan rencana dan saluran untuk fitur flag fitur dan tes A/B.

Lanjutkan dari Saluran

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