Saluran

Saluran Pembaruan Hidup menunjuk ke sebuah bangunan JS tertentu dari aplikasi Anda yang akan dibagikan dengan perangkat apa pun yang 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 kapan saja dan juga dapat kembali ke bangunan sebelumnya jika perlu.

Saluran Tidak Menyediakan Rahasia

Saluran mengontrol kelayakan pembaruan, bukan rahasia paket. Bahkan jika saluran adalah privat atau pengasasan sendiri dinonaktifkan, setiap paket yang tidak dienkripsi yang diunggah ke Capgo masih harus dianggap sebagai aset publik yang disampaikan kepada klien. Enkripsi melindungi jalur pengiriman dan keaslian pembaruan, tetapi paket yang dikirim masih dapat direkayasa balik dari aplikasi yang didistribusikan dengan cukup usaha karena kunci publik adalah bagian dari klien. Lihat Pembaruan Hidup enkripsi untuk informasi lebih lanjut.

Bagaimana perangkat memilih saluran (prioritas)

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

1. Pemetaan perangkat paksa (Dashboard) – Menempelkan ID perangkat tertentu secara manual ke saluran. Gunakan untuk debugging darurat atau pengujian terkendali dengan pengguna asli tunggal. Ini selalu menang.
2. Tambahan 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 di perangkat tersebut, berlaku segera, dan tidak ditampilkan di UI Penggeser 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 utamamu), setChannel() berfungsi berbeda: menghubungi backend untuk memvalidasi apakah saluran diizinkan (mengatur apakah penugasan sendiri diaktifkan untuk saluran tersebut), kemudian menyimpan saluran secara lokal di perangkat sebagai defaultChannel. Ini berarti saluran baru berlaku segera untuk memeriksa pembaruan berikutnya—tidak perlu menunggu replikasi.

Sebelumnya, setChannel() menghemat pengaturan saluran ke database backend (seperti Dashboard atau API perubahan), dan perangkat harus menunggu replikasi data (hingga 2 menit) sebelum saluran baru diakui. perilaku baru hanya membaca dari backend (untuk validasi) dan menyimpan secara lokal, membuat perubahan saluran instan.

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

Penting: Meskipun saluran menjadi tidak diizinkan setelah diatur secara lokal, backend akan masih melakukan validasi saluran selama 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 menunjukkan perubahan. Untuk mengaktifkan perubahan saluran instan, gunakan setChannel() di aplikasi Anda code—ini melakukan validasi dengan backend, kemudian mengatur saluran secara lokal untuk efek segera.

4. Konfigurasi Capacitor defaultChannel (build uji coba default) – Jika ada di capacitor.config.* dan tidak ada paksa/override/local channel, aplikasi dimulai pada saluran ini (misalnya) beta, qa, pr-123. Bisa digunakan untuk build internal / uji coba sehingga tester langsung berada di saluran pre-release. Build produksi biasanya tidak mengatur ini.
5. Saluran Utama 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 menghubungkan ke sini. Perubahan akan langsung berlaku tanpa 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 saluran utama cloud diizinkan; 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 utama cloud, pengguna nyata harus mengalir ke dalamnya. Jika Anda tidak menetapkan satu, pastikan Anda sengaja bagaimana pengguna menghubungkan (biasanya melalui) defaultChannel konfigurasi atau pengaturan per-device.
• Hanya konfigurasi defaultChannel di binary yang Anda kirim secara eksplisit kepada tester. Mengosongkannya menjaga logika produksi tetap terkonsentrasi di dashboard.
• Gunakan setChannel() Gunakan dengan bijak di produksi—biasanya untuk QA atau diagnostik yang sasaran.

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

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

Behavior Saluran Bawaan

Mengatur default cloud tidak wajib, tetapi biasanya berfungsi sebagai jalur utama untuk perangkat baru. Tanpa satu, hanya perangkat yang sesuai dengan pemetaan paksa, override, atau konfigurasi __CAPGO_KEEP_0__ yang akan menerima update. Ketika Anda memilih untuk menandai default, perhatikan pola-pola berikut: defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

• – Jika sebuah saluran memiliki iOS, Android, dan Electron diaktifkan, maka menjadi default tunggal; perangkat tanpa override akan menempel di sini. Pilih
• Default Platform – Jika Anda membagi saluran berdasarkan platform (misalnya, hanya iOS diaktifkan, hanya Android diaktifkan, dan 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. ios-production Pahami bahwa default awan dan default lokal berada di lapisan keputusan yang sama. Jika Anda menetapkan default awan, Anda tidak perlu mengulang nilai di konfigurasi __CAPGO_KEEP_0__ Anda—biarkan kosong untuk build produksi. Simpan untuk biner yang Anda sengaja kirimkan kepada tester atau QA ketika Anda ingin mereka memulai pada saluran non-produksi bahkan jika default awan berbeda. android-production Saluran dapat diubah 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. electron-production Pengaturan Saluran

Pengaturan Saluran defaultChannel Pengaturan Saluran 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 Pengaturan Saluran defaultChannel Pengaturan Saluran

Pengaturan Saluran

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. Mengunjungi bagian “Saluran” dari Capgo dashboard
2. Mengklik tombol “Saluran Baru”
3. Memasukkan nama untuk saluran dan mengklik “Buat”

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

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

Mengatur Saluran di Aplikasi Anda

Setelah membuat saluran Anda, Anda perlu mengonfigurasi aplikasi Anda untuk mendengarkan saluran yang tepat. Dalam contoh ini, kami akan menggunakan Development saluran.

Buka file capacitor.config.ts (atau capacitor.config.json) di editor Anda. Di bawah bagian plugins opsional untuk mengatur defaultChannel untuk build 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, bangun aplikasi web Anda dan jalankan npx cap sync untuk menyalin file konfigurasi yang diperbarui ke proyek iOS, Android, dan Electron Anda. Jika Anda melewatkan langkah sinkronisasi ini, proyek native Anda akan terus menggunakan saluran yang sebelumnya dikonfigurasi.

Peringatan

Urutan pilihan saluran: Paksa > Pengaturan perangkat/API > Plugin setChannel() saluran lokal > Konfigurasi defaultChannel > Default Cloud.

Pakai defaultChannel hanya dalam build internal/test; tinggalkan untuk produksi agar pengguna mengikuti Default Cloud (ketika diatur) bukan mengulangi routing di konfigurasi native.

Anda masih bisa memaksa (menempel) perangkat atau menerapkan pengaturan override nanti—hal itu langsung menggantikan 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 paling penting ada di bawah. Anda dapat mengonfigurasi hal ini dari aplikasi web, CLI, atau API publik.

• Saluran default: Pilihlah saluran atau platform khusus yang perangkat baru akan terhubung. Lihat “Pengaturan Saluran Default” untuk skenario routing.
• Filter platform: Aktifkan atau nonaktifkan pengiriman ke iOS, Androidatau Electron perangkat per saluran.
• Matikan downgrade otomatis di bawah native: Mencegah 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 pengujian).
• Biarkan perangkat emulator: Izinkan update ke perangkat emulator/simulator (bermanfaat untuk pengujian).
• Biarkan perangkat menetapkan sendiri: Biarkan aplikasi berganti ke saluran ini secara waktu eksekusi menggunakan setChannelJika dinonaktifkan, setChannel akan gagal untuk saluran ini.

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 baseline native perangkat (version_buildContoh: 1.2.3 -> 2.0.0 terhalang; 1.2.3 -> 1.9.0 boleh.
• kecil: Menghalangi bundle target yang versi mayor atau minor berbeda dari version_buildContoh: 1.2.3 -> 1.3.0 terblokir; 1.2.3 -> 1.2.4 diizinkan.
• patch: Mode 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 diizinkan; 1.0.0+build.1 -> 1.0.0+build.2 diizinkan; 1.0.0 -> 1.0.1 terblokir.
• metadata: Tuntut 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 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 dan contoh lebih lanjut, lihat Disable updates strategy di /docs/cli/commands/#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

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

• Alur pilihan beta program
• Saluran
• 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() di panggil:

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

Mengapa ini penting: Pada versi lama, setChannel() menghemat saluran override 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.

Ketersediaan 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 administrator.

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

Pembandingan metode perubahan saluran:

Metode	Waktu Efek	Dimana Data Diperlakukan	Ditampilkan di Pengaturan Perangkat	Penggunaan
setChannel() context: 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
Pengguna Mengganti Saluran Dalam Aplikasi	Pengaturan Perangkat Dashboard	Sampai 2 menit	Database Server Sisi Belakang	Perubahan yang diinisiasi oleh administrator untuk perangkat tertentu
Penugasan API channel	Sampai dengan 2 menit	Database backend	Ya	Integrasi backend otomatis

Untuk pengalaman pengguna yang terbaik ketika membuat 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 mayor Anda). Setiap nomor versi minor mewakili set fitur yang sama di semua versi mayor (misalnya, X.34.0 termasuk fitur yang sama apapun X adalah 5, 6, 7, atau 8). Lihat instalasi plugin untuk tag versi.

Mengasignkan Paket ke Saluran

Untuk mengaktifkan pembaruan live, Anda perlu mengunggah build paket JS baru dan mengasignkannya 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 mengatur 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 mengasignkan build ke saluran dari bagian “Paket” di __CAPGO_KEEP_0__ dashboard. Klik ikon menu di samping build dan pilih “Asign 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 “Paket Versi dan Saluran”

Capgo

Ketika Anda mengatur versi bundle, kami merekomendasikan menggunakan versi semantik dengan Capgo’s Semver Tester dan identifikasi pre-release untuk build kanal tertentu. Misalnya, rilis beta mungkin versi sebagai 1.2.3-beta.1.

Dalam 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 kanal bundle terkait akan meningkatkan versi sampai nama gratis ditemukan. Dengan ai, AI Workers menduga tingkat dari manifest delta lokal vs sebelumnya (jatuh kembali ke patch jika tidak ada versi Capgo sebelumnya). Anda tidak dapat menggabungkannya dengan --bundle. Lihat dan dan Referensi CLI.

Metode ini memiliki beberapa keuntungan:

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

Berikut adalah contoh cara Anda mungkin mengatur versi bundle dengan setup saluran yang umum:

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

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

Mengembalikan Live Update

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

1. Klik nama saluran yang ingin Anda kembalikan
2. Temukan bangun yang ingin Anda kembalikan dan klik ikon mahkota
3. Konfirmasi Aksi

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

Automasi Pengiriman

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

Cek Dokumen untuk mengetahui lebih lanjut tentang mengautomasi __CAPGO_KEEP_0__ pembaruan hidup. Penglihatan PR yang Kurang Privilegi docs to learn more about automating Capgo live updates.

Pengiriman Otomatis

Menggunakan kunci Penglihatan Aplikasi API

1. Membuat kunci API yang aman dan terbatas hanya untuk aplikasi pratinjau dan memilih Penglihatan AplikasiLihat Kunci API.
2. Menggunakan saluran yang unik dan tidak umum seperti pr-123Tidak melewati --default, --self-assignopsi peluncuran, atau --delete-linked-bundle-on-upload.
3. Mengunggah dan mempromosikan paket PR dalam satu perintah, kemudian hapus saluran dan paket 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 paket, dan mempromosikannya dalam satu aliran. Pembersihan adalah atomik dan diperiksa kepemilikan: kunci dapat menghapus hanya saluran yang dibuatnya dan paket terkait yang tidak dibagikan. Ia tidak dapat mengubah, mempromosikan, atau menghapus saluran utama/default yang ada, saluran lain milik kunci tampilan, atau paket milik kunci lain.

Jika para reviewer membutuhkan QR code atau URL tampilan, administrator harus mengaktifkan tampilan 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 tampilan aplikasi tidak dapat mengaktifkan tampilan sendiri karena tidak memiliki izin pengaturan aplikasi. Dalam GitHub Actions, jalankan pekerjaan tampilan yang membawa rahasia di pull_request, bukan pull_request_target, dan batasi mereka hanya untuk PR repositori yang sama dengan github.event.pull_request.head.repo.full_name == github.repository.

Meluncurkan ke Perangkat

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

1. Pasang Capgo SDK di aplikasi Anda
2. Konfigurasi aplikasi untuk mendengarkan saluran yang diinginkan Anda
3. Unggah bangun dan menugaskan ke saluran tersebut
4. Rilis aplikasi dan tunggu update!

Untuk panduan yang lebih rinci, lihat Deploying Live Updates guide. 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:

• Bendera fitur untuk tingkat pengguna yang berbeda
• Pengujian A/B
• Pengeluaran fitur secara bertahap
• Program-program uji coba beta

Belajar cara mengimplementasikan kasus penggunaan yang lebih maju dalam panduan kami: Bagaimana cara Mengsegmentasi Pengguna berdasarkan Paket dan Saluran untuk Flag Fitur dan Uji A/B.

Teruskan dari Saluran

Jika Anda menggunakan Saluran context":"Saluran fitur nama 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 merencanakan routing saluran dan peluncuran tahap demi tahap, hubungkannya dengan Saluran context":"Saluran fitur nama 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, dan untuk detail implementasi di Saluran, Solusi Pengujian Beta untuk alur kerja produk di Solusi Pengujian Beta, Solusi Target Versi untuk alur kerja produk di Solusi Target Versi, dan Capgo Praktik Terbaik Lingkungan: Staging dengan Satu ID Aplikasi Mobile untuk konteks praktis di Capgo Praktik Terbaik Lingkungan: Staging dengan Satu ID Aplikasi Mobile.