Channel

Channel Live Update mengarah ke build JS bundle spesifik dari aplikasi Anda yang akan dibagikan ke perangkat mana pun yang dikonfigurasi untuk mendengarkan channel tersebut guna mendapatkan update. Saat Anda pasang Capgo Live Updates SDK di aplikasi Anda, setiap native binary yang dikonfigurasi ke channel tersebut akan mengecek update yang tersedia setiap kali aplikasi dijalankan. Anda bisa mengubah build yang dituju oleh channel kapan saja dan juga bisa rollback ke build sebelumnya jika diperlukan.

Channel dalam praktik

Anggaplah channel sebagai pointer bernama ke sebuah update: production bisa melayani aplikasi yang sudah rilis sementara beta melayani tester. Ketiga video pendek ini menunjukkan bagaimana sebuah device masuk ke dalam channel. Masing-masing memiliki musik latar opsional tanpa narasi; penjelasan di bawah ini mencakup langkah-langkah yang sama.

1. Gunakan channel default

Device yang menjalankan v1.1.0 meminta update ke Capgo. Tanpa device assignment atau channel yang dikonfigurasi di aplikasi, Capgo akan mengecek default di cloud, production, dan mengembalikan v1.2.0 bundle. dev dan staging Channel menyimpan bundle masing-masing tanpa memengaruhi perangkat ini.

Download video channel default (MP4).

Atur default production Anda di Informasi Aplikasi. Build production normal dapat dibiarkan defaultChannel kosong agar Anda bisa mengelola routing tersebut dari Capgo.

2. Biarkan perangkat memilih channel

Panduan ini menggunakan setChannel() dan unsetChannel() dari @capgo/capacitor-updater di Android dan iOS; metode ini tidak didukung di browser. Menggunakan perilaku local-channel yang tersedia di updater 5.34.0+, 6.34.0+, 7.34.0+, atau 8.0.0+ untuk versi major plugin Anda. Versi lama menggunakan backend override; penugasan tersebut mengikuti aturan retensi override console dan API.

Seorang tester mengaktifkan beta update di dalam aplikasi Anda. Aplikasi Anda memanggil CapacitorUpdater.setChannel({ channel: 'beta', triggerAutoUpdate: true }). Capgo memeriksa bahwa beta mengizinkan device self-assignment, lalu plugin menyimpan pilihan tersebut secara lokal untuk pengecekan update mendatang. Perangkat lain tetap menggunakan routing yang ada.

Unduh video self-assignment perangkat (MP4).

Aktifkan Izinkan perangkat untuk self dissociate/associate pada channel target sebelum digunakan setChannel(). Pilihan lokal ini tidak membuat override di console. Pada Android dan iOS dengan updater 8.51.0 ke atas, persistDefaultChannelOnReinstall defaultnya adalah true, sehingga pilihan hanya bisa bertahan setelah reinstall jika OS memulihkan data aplikasi dan persistDefaultChannelOnReinstall tetap true. Panggil unsetChannel() untuk menghapus pilihan lokal; override console dan API tetap mengikuti urutan prioritas di bawah ini.

3. Tetapkan satu perangkat dari console

Di konsol Capgo, buka Aplikasi, pilih aplikasi Anda, buka Perangkat, lalu pilih perangkat. Ubah Override channel ke dev. Capgo now routes that device to dev, sementara default cloud aplikasi tetap production.

Download video console device override (MP4).

Gunakan override untuk pengujian terarah atau dukungan. Ini lebih diprioritaskan daripada channel lokal perangkat dan default cloud, kecuali ada forced mapping. Override Console dan API kedaluwarsa 90 hari setelah penulisan override terakhir.

Siap mencobanya? Buat channel di console, lalu upload bundle untuk disajikan.

Channel Tidak Memberikan Kerahasiaan

Channel mengontrol kelayakan update, bukan kerahasiaan bundle. Meskipun channel bersifat privat atau self-assignment dinonaktifkan, bundle tanpa enkripsi yang di-upload ke Capgo tetap harus dianggap sebagai aset publik yang dikirim ke client. Enkripsi melindungi jalur pengiriman dan autentisitas update, tetapi bundle yang dikirim tetap bisa di-reverse engineer dari aplikasi yang didistribusikan dengan upaya yang cukup karena public key adalah bagian dari client. Lihat enkripsi Live Update detailnya.

Cara perangkat memilih channel (urutan prioritas)

Saat perangkat mengecek update, Capgo menentukan channel mana yang digunakan dengan urutan ketat berikut (prioritas tertinggi pertama):

1. Pemetaan perangkat paksa (Dashboard) – Pin ID perangkat tertentu ke sebuah channel secara manual. Gunakan untuk debugging mendesak atau testing terkontrol dengan satu user asli. Ini selalu menang. Capgo akan menghapus mapping ini 90 hari setelah penulisan override terakhir. Lihat Override dari Console dan API kedaluwarsa setelah 90 hari.
2. Cloud override (per-device) via Dashboard atau API – Dibuat saat Anda mengubah channel perangkat di dashboard atau via API. Gunakan untuk user QA yang berpindah antar channel feature / PR atau untuk mereproduksi issue user. Reinstall binary tidak akan menghapusnya; menghapus device override akan menghapusnya. Aturan retensi 90 hari yang sama juga berlaku.
3. Plugin setChannel() channel lokal – Dibuat saat app memanggil setChannel() dan backend memvalidasi bahwa target channel mengizinkan self-assignment. Channel yang dipilih disimpan secara lokal di perangkat tersebut, langsung aktif, dan tidak muncul di UI Device Override.

Ganti Channel Secara Instan dengan setChannel()

Mulai dari versi plugin 5.34.0, 6.34.0, 7.34.0, atau 8.0.0 (tergantung versi major Anda), setChannel() bekerja secara berbeda: ia menghubungi backend untuk memvalidasi bahwa channel tersebut diizinkan (mengecek apakah self-assignment aktif untuk channel tersebut), lalu menyimpan channel secara lokal di perangkat sebagai defaultChannel. Ini berarti channel baru akan langsung aktif seketika pada pengecekan update berikutnya—tanpa perlu menunggu replikasi.

Sebelumnya, setChannel() simpanan channel override masuk ke database backend (seperti perubahan Dashboard atau API), dan perangkat harus menunggu replikasi data (hingga 2 menit) sebelum channel baru dikenali. Perilaku baru ini hanya membaca dari backend (untuk validasi) dan menyimpannya secara lokal, sehingga perpindahan channel menjadi instan.

Karena setChannel() hanya bersifat lokal, ini tidak tidak buat entri Device Override di dashboard Capgo. UI Device Override hanya menampilkan override yang dibuat dari dashboard atau Public API.

Catatan: Meskipun sebuah channel menjadi tidak diizinkan setelah diatur secara lokal, backend akan tetap memvalidasi channel tersebut saat pengecekan update, sehingga keamanan tetap terjaga.

Penting: Saat perubahan channel dilakukan melalui Dashboard atau API, masih ada jeda replikasi hingga 2 menit sebelum semua edge server mencerminkan perubahan tersebut. Untuk perpindahan channel instan, gunakan setChannel() dari code aplikasi Anda—ini akan memvalidasi ke backend, lalu mengatur channel secara lokal agar langsung berpengaruh.

4. konfigurasi Capacitor defaultChannel (build test default) – Jika ada di dalam capacitor.config.* dan tidak ada channel force/override/local, aplikasi akan mulai di channel ini (misalnya beta, qa, pr-123). Ditujukan untuk TestFlight / internal build agar tester otomatis masuk ke channel pre-release. Production build biasanya membiarkan ini tidak diatur.
5. Cloud Default Channel (jalur utama ~99% pengguna) – Jika Anda menandai default channel di dashboard, semua end-user normal (tanpa force, tanpa override Dashboard/API, tanpa plugin local channel, tanpa config defaultChannel) akan terhubung ke sini. Ubah ini untuk rollout atau rollback secara instan—tanpa perlu binary baru. Jika Anda memiliki default spesifik platform (misalnya, satu khusus iOS, satu khusus Android, satu khusus Electron), setiap perangkat akan masuk ke default yang sesuai dengan platformnya. Membiarkan cloud default tidak diatur diperbolehkan; jika demikian, perangkat harus memenuhi langkah 1–4 untuk menerima update.

Praktik terbaik:

• Anggap 1–4 sebagai lapisan pengecualian / testing; saat Anda mengatur cloud default, pengguna asli harus mengalir ke sana. Jika Anda memilih untuk tidak mengaturnya, pertimbangkan matang-matang bagaimana pengguna terhubung (biasanya melalui defaultChannel di config atau per-device override).
• Hanya konfigurasi defaultChannel pada binary yang Anda kirimkan secara eksplisit ke tester. Membiarkannya tidak diatur akan menjaga logika production tetap terpusat di dashboard.
• Gunakan setChannel() gunakan secara terbatas di production—terutama untuk QA atau diagnostik terarah.

Jika sebuah channel dinonaktifkan untuk platform tertentu (toggle iOS/Android/Electron) saat seharusnya dipilih, proses seleksi akan melompatinya dan lanjut ke daftar berikutnya.

Ringkasan: Force > Dashboard/API Override > Plugin setChannel() channel lokal > Config defaultChannel > Default Cloud.

Override dari Console dan API kedaluwarsa setelah 90 hari

Mapping paksaan dan override channel Dashboard atau Public API disimpan sebagai penugasan per-perangkat di Capgo. Job pembersihan akan menghapus penugasan tersebut 90 hari setelah penulisan override terakhir. Melakukan check-in untuk update tidak akan mereset timer tersebut. Hanya dengan menulis ulang override (atau menghapusnya secara manual) yang akan mengubah timestamp.

Ini tidak sama dengan retensi inventory perangkat. Inventory menghapus perangkat yang tidak terhubung ke Capgo selama 90 hari. Override cleanup menghapus mapping meskipun perangkat masih aktif.

Untuk assignment yang tidak dihapus oleh cleanup ini:

• Atur defaultChannel di capacitor.config.* (bertahan saat reinstall; butuh native binary baru untuk mengubahnya nanti).
• Panggil setChannel() dari aplikasi. Pada plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 ke atas, assignment tersebut bersifat lokal dan tidak dihapus oleh cleanup ini. Pada Android dan iOS dengan updater 8.51.0 ke atas, persistDefaultChannelOnReinstall defaultnya adalah true, sehingga assignment hanya bisa bertahan saat reinstall jika sistem operasi memulihkan data aplikasi dan persistDefaultChannelOnReinstall tetap true. Gunakan unsetChannel() untuk menghapusnya secara eksplisit.

Channel Perangkat tab dan UI Override device hanya menampilkan daftar console dan penugasan Public API. Ini tidak menampilkan semua device di channel tersebut, dan tidak menampilkan penugasan setChannel() assignments.

Pemberitahuan retensi Override pada tab Devices di channel.

Perilaku Channel Default

Menentukan cloud default bersifat opsional, namun biasanya berfungsi sebagai jalur catch-all untuk device baru. Tanpa itu, hanya device yang cocok pada forced mappings, overrides, atau defaultChannel di konfigurasi Capacitor yang akan menerima update. Saat Anda memilih untuk menandai default, perhatikan pola berikut:

• Single default (paling umum) – Jika sebuah channel mengaktifkan iOS, Android, dan Electron, maka ia menjadi satu-satunya default; semua device tanpa overrides akan terhubung ke sini.
• Default spesifik platform – Jika Anda membagi channel berdasarkan platform (misalnya, ios-production hanya iOS yang aktif, android-production hanya Android yang aktif, dan electron-production hanya Electron yang aktif), tandai masing-masing sebagai default untuk platformnya. Perangkat iOS akan masuk ke default iOS, perangkat Android ke default Android, dan aplikasi Electron ke default Electron.

Ingat bahwa default cloud dan defaultChannel di capacitor.config.* keduanya berada di lapisan keputusan yang sama. Jika Anda mengatur default cloud, Anda tidak perlu menduplikasi nilainya di konfigurasi Capacitor Anda—biarkan defaultChannel kosong untuk production build. Gunakan defaultChannel untuk binary yang sengaja dikirim ke tester atau QA saat Anda ingin mereka mulai di channel non-production meskipun default cloud berbeda.

Anda dapat mengubah default kapan saja di dashboard. Buka channel, lalu Kelola di pengaturan aplikasi, yang akan mengarahkan Anda ke Informasi Aplikasi. Default tidak lagi berupa toggle di halaman channel. Saat Anda mengganti default, perangkat baru akan langsung mengikuti routing baru, dan perangkat lama akan mengikuti aturan presedensi normal saat melakukan check-in berikutnya.

Menyiapkan Channel

Saat onboarding, Anda akan membuat channel pertama (biasanya tim menamainya “Production”), tetapi tidak ada yang terkunci—Anda bisa mengubah nama atau menghapus channel kapan saja. Untuk menambah channel lain nanti:

1. Buka bagian “Channels” di dashboard Capgo
2. Klik tombol “New Channel”
3. Masukkan nama channel dan klik “Create”

Nama channel bebas sesuai keinginan Anda. Strategi umum yang digunakan adalah mencocokkan channel dengan tahapan development Anda, seperti:

• Development - untuk testing live updates di perangkat lokal atau emulator
• QA - untuk tim QA memverifikasi update sebelum rilis lebih luas
• Staging - untuk pengujian akhir di lingkungan mirip produksi
• Production - untuk versi aplikasi Anda yang diterima pengguna akhir dari app store

Konfigurasi Channel di App Anda

Setelah channel dibuat, Anda perlu mengonfigurasi aplikasi untuk mendengarkan channel yang sesuai. Dalam contoh ini, kita akan menggunakan Development channel.

Buka file capacitor.config.ts (atau capacitor.config.json) file. Di bawah plugins section, Anda bisa mengatur defaultChannel untuk build uji coba (internal / QA). Untuk build produksi, sebaiknya dikosongkan agar perangkat menggunakan Cloud Default kecuali jika diatur secara eksplisit.

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, build web app Anda dan jalankan npx cap sync untuk menyalin file config terbaru ke proyek iOS, Android, dan Electron Anda. Jika langkah sinkronisasi ini dilewati, proyek native Anda akan tetap menggunakan channel yang sudah dikonfigurasi sebelumnya.

Peringatan

Urutan pemilihan channel: Force > Dashboard/API device override > Plugin setChannel() channel lokal > Konfigurasi defaultChannel > Default Cloud.

Gunakan defaultChannel hanya untuk build test/internal; jangan gunakan untuk produksi agar pengguna mengikuti Cloud Default (jika diatur) alih-alih menduplikasi routing di native config.

Anda tetap bisa melakukan force (pin) pada perangkat atau menerapkan override nanti—keduanya akan langsung menggantikan nilai config.

Nama channel bersifat case-sensitive.

Opsi dan Strategi Channel

Channel punya beberapa opsi yang mengatur siapa yang bisa menerima update dan bagaimana update dikirimkan. Opsi terpenting ada di bawah ini. Anda bisa mengonfigurasinya dari web app, CLI, atau Public API.

• Default channel: Secara opsional, tandai channel atau channel khusus platform yang akan diikuti perangkat baru. Di console, ini ada di App Information (Kelola di pengaturan aplikasi dari halaman channel). Lihat “Default Channel Behavior” untuk skenario routing.
• Platform filters: Aktifkan atau nonaktifkan pengiriman ke iOS, Android, atau Electron perangkat per channel.
• Disable auto downgrade under native: Mencegah pengiriman update saat versi native app di perangkat lebih baru daripada bundle channel (misalnya, perangkat di 1.2.3 sementara channel di 1.2.2).
• Allow development builds: Izinkan update ke development builds (berguna untuk testing). CLI: --dev / --no-dev.
• Izinkan build produksi: Izinkan update ke build produksi (store). Biarkan aktif untuk channel yang melayani pengguna nyata. CLI: --prod / --no-prod.
• Izinkan perangkat emulator: Izinkan update ke emulator/simulator (berguna untuk testing). CLI: --emulator / --no-emulator.
• Izinkan perangkat fisik: Izinkan update ke ponsel dan tablet nyata. Biarkan aktif untuk channel produksi. CLI: --device / --no-device.
• Izinkan penetapan mandiri perangkat: Memungkinkan aplikasi beralih ke channel ini saat runtime menggunakan setChannel. Jika dinonaktifkan, setChannel akan gagal untuk channel ini. CLI: --self-assign / --no-self-assign.
• Format download: Pilih apakah perangkat mendownload zip penuh, hanya file delta yang berubah, atau kombinasi terbaik dari keduanya (all, zip, delta, zip_from_builtin, delta_from_builtin). Lihat Format download untuk dropdown di console dan kapan tiap mode berguna.

Rollout bertahap

Channel dapat menjaga bundle tetap stabil sambil secara bertahap merilis target rollout terpisah ke kelompok perangkat tertentu. Anda bisa menjeda, melanjutkan, mempromosikan, melakukan rollback, dan mengatur respons kegagalan otomatis tanpa harus mengganti channel untuk semua orang. Lihat Rollout bertahap untuk model pengiriman, alur kerja dashboard, field API, dan perintah CLI.

Nonaktifkan strategi Auto Update

Gunakan ini untuk membatasi jenis update apa saja yang akan dikirimkan channel secara otomatis. Opsi:

• major: Memblokir target bundle yang versi major-nya lebih tinggi dari baseline native perangkat (version_build). Contoh: 1.2.3 -> 2.0.0 diblokir; 1.2.3 -> 1.9.0 diizinkan.
• minor: Memblokir target bundle yang versi major atau minor-nya berbeda dari version_build. Contoh: 1.2.3 -> 1.3.0 diblokir; 1.2.3 -> 1.2.4 diizinkan.
• patch: Mode paling ketat. Memblokir perubahan pada nomor major, minor, atau patch. Hanya perubahan suffix yang diizinkan sementara 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 diblokir.
• metadata: Wajibkan metadata versi update minimum pada setiap bundle. Konfigurasi via CLI menggunakan --min-update-version atau --auto-min-update-version. Jika tidak ada, channel akan ditandai salah konfigurasi dan update akan ditolak sampai diatur.
• none: Izinkan semua update sesuai kompatibilitas semver.

Strategi ini membandingkan target bundle channel dengan native baseline yang dikirim sebagai version_build, bukan bundle yang sedang diunduh yang dikirim sebagai version_name.

Pelajari detail dan contoh selengkapnya di Disable updates strategy pada /docs/cli/commands/#disable-updates-strategy.

Contoh (CLI). Channel harus sudah ada (channel set tidak akan membuatnya):

# 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 App Anda

Panduan @capgo/capacitor-updater metode setChannel() memungkinkan aplikasi Android atau iOS Anda untuk berpindah channel secara terprogram saat runtime. Ini sangat berguna untuk:

• Menu QA/debug untuk tester pindah antar channel
• Flow opt-in program Beta
• Implementasi feature flag
• Skenario A/B testing

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
});

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

Saat setChannel() dipanggil:

1. Validasi Backend (read-only): Request dikirim ke backend Capgo untuk validasi channel (cek izin self-assignment)
2. Update local storage: Jika validasi berhasil, channel disimpan ke local storage perangkat sebagai defaultChannel
3. Efek instan: Pengecekan update berikutnya langsung memakai channel baru (tanpa menunggu replikasi)

Mengapa ini penting: Pada versi lama, setChannel() menyimpan channel override ke database backend (sama seperti perubahan lewat Dashboard atau API). Perangkat harus menunggu replikasi backend (hingga 2 menit) sebelum perubahan channel berlaku. Sekarang, setChannel() hanya membaca dari backend (untuk validasi) lalu menyimpannya secara lokal, sehingga perpindahan channel jadi instan.

Visibilitas di Dashboard: Channel yang diatur lewat plugin tidak membuat perangkat muncul sebagai Device Override di UI Capgo. Hanya penugasan channel yang dibuat dari dashboard atau Public API yang terdaftar di sana. Gunakan dashboard atau API kalau Anda butuh override yang terlihat oleh admin.

Catatan keamanan: Meskipun izin channel berubah setelah diatur secara lokal (misalnya self-assignment dinonaktifkan), backend tetap memvalidasi channel saat pengecekan update, sehingga keamanan tetap terjaga.

Perbandingan metode perubahan channel:

Metode	Durasi Efek	Disimpan Di	Muncul di UI Device Override	Kedaluwarsa	Kasus Penggunaan
setChannel() dari plugin	Instan	Hanya Perangkat (lokal)	Tidak	Tanpa kedaluwarsa otomatis; hapus dengan unsetChannel() (instal ulang mungkin tetap ada)	Pergantian channel in-app oleh user
Override perangkat via dashboard	Hingga 2 menit	Database backend	Ya	90 hari setelah penulisan override terakhir	Perubahan oleh admin untuk perangkat tertentu
Penetapan channel API	Hingga 2 menit	Database backend	Ya	90 hari setelah penulisan override terakhir	Integrasi backend otomatis

Untuk pengalaman pengguna terbaik saat membangun UI perpindahan channel, selalu gunakan setChannel() method plugin.

Versi minimum untuk perpindahan channel lokal saja: 5.34.0, 6.34.0, 7.34.0, atau 8.0.0 (tergantung versi major Anda). Setiap nomor versi minor memiliki fitur yang sama di semua versi major (misalnya, X.34.0 memiliki fitur yang sama baik X adalah 5, 6, 7, atau 8). Lihat instalasi plugin untuk tag versi.

Menetapkan Bundle ke Channel

Untuk men-deploy live update, Anda perlu meng-upload build JS bundle baru dan menetapkannya ke sebuah channel. Anda bisa melakukannya dalam satu langkah dengan Capgo CLI:

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

Ini akan mengunggah aset web hasil build Anda dan menetapkan bundle baru sebagai build aktif untuk Development channel tersebut. Semua aplikasi yang dikonfigurasi untuk mendengarkan channel itu akan menerima update saat melakukan pengecekan berikutnya.

Anda juga bisa menetapkan build ke channel dari bagian “Bundles” di dashboard Capgo. Klik ikon menu di samping build dan pilih “Assign to Channel” untuk memilih channel bagi build tersebut.

Versioning Bundle dan Channel

Penting untuk dicatat bahwa bundle di Capgo bersifat global untuk aplikasi Anda, bukan spesifik untuk channel tertentu. Bundle yang sama dapat ditetapkan ke beberapa channel.

Saat melakukan versioning pada bundle Anda, kami menyarankan penggunaan semantic versioning dengan Semver Tester dari Capgo dan pre-release identifier untuk build spesifik channel. Sebagai contoh, rilis beta mungkin di-versioning sebagai 1.2.3-beta.1.

Di 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 naik dari bundle yang terhubung ke channel sampai nama yang tersedia ditemukan. Dengan ai, Workers AI menyimpulkan levelnya dari delta manifest lokal vs sebelumnya (kembali ke patch tanpa versi Capgo sebelumnya). Anda tidak bisa menggabungkannya dengan --bundle. Lihat Integrasi CI/CD dan referensi CLI.

Pendekatan ini memiliki beberapa keuntungan:

• Menjelaskan hubungan antar build secara jelas. 1.2.3-beta.1 jelas merupakan pre-release dari 1.2.3.
• Memungkinkan penggunaan ulang nomor versi di berbagai channel, mengurangi kebingungan.
• Ini memungkinkan jalur rollback yang jelas. Jika Anda perlu rollback dari 1.2.3, Anda tahu 1.2.2 adalah rilis stabil sebelumnya.

Berikut adalah contoh cara menyelaraskan versi bundle Anda dengan pengaturan channel pada umumnya:

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

Menggunakan semver dengan identifier pre-release adalah pendekatan yang direkomendasikan, meski tidak wajib. Kuncinya adalah menemukan skema versioning yang menjelaskan hubungan antar build Anda dengan jelas dan selaras dengan proses development tim.

Rollback Live Update

Jika Anda men-deploy live update yang menyebabkan bug atau perlu dibatalkan, Anda bisa melakukan rollback ke build sebelumnya dengan mudah. Dari bagian “Channels” di dashboard:

1. Klik nama channel yang ingin di-rollback
2. Cari build yang ingin Anda kembalikan, lalu klik ikon mahkota
3. Konfirmasi tindakan

Build yang dipilih akan segera menjadi build aktif untuk channel tersebut. Aplikasi akan menerima versi hasil rollback saat melakukan pengecekan update berikutnya.

Otomatisasi Deployment

Untuk workflow yang lebih canggih, Anda bisa mengotomatiskan deployment live update sebagai bagian dari pipeline CI/CD Anda. Dengan mengintegrasikan Capgo ke dalam proses build, Anda dapat mengunggah bundle baru secara otomatis dan menetapkannya ke channel setiap kali Anda melakukan push ke branch tertentu atau membuat release baru.

Lihat juga Integrasi CI/CD dokumentasi untuk mempelajari lebih lanjut tentang otomatisasi Capgo live updates.

PR preview dengan least privilege

Gunakan Pratinjau Aplikasi Gunakan key API saat CI membutuhkan satu channel sementara per pull request tetapi tidak boleh mengelola channel main/default yang sudah ada. Key tersebut tetap terikat pada organisasi pemilik dan aplikasi yang dipilih; hanya saja tidak memiliki role di tingkat organisasi. Setiap channel preview non-publik yang dibuatnya akan mendapat izin lifecycle otomatisnya sendiri yang dibatasi per channel.

1. Minta administrator organisasi membuat key API yang aman, dibatasi untuk aplikasi preview, lalu pilih Pratinjau Aplikasi. Lihat Kunci API.
2. Gunakan channel unik yang non-publik seperti pr-123. Jangan berikan --default, --self-assign, opsi rollout, atau --delete-linked-bundle-on-upload.
3. Upload dan promosikan bundle PR dalam satu perintah, lalu hapus channel dan bundle yang dimiliki saat 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 channel yang belum ada, mengunggah bundle, dan mempromosikannya dalam satu alur. Cleanup bersifat atomik dan memeriksa kepemilikan: key hanya bisa menghapus channel yang dibuatnya dan bundle terkait yang tidak dibagikan. Key tidak bisa mengubah, mempromosikan, atau menghapus channel utama/default yang sudah ada, channel milik key preview lain, atau bundle milik key lain.

Jika reviewer membutuhkan QR code atau URL preview, administrator harus mengaktifkan preview satu kali untuk aplikasi tersebut:

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

App Preview key tidak bisa mengaktifkan preview secara mandiri karena tidak memiliki izin app-settings. Di GitHub Actions, jalankan job preview yang berisi secret pada pull_request, bukan pull_request_target, dan batasi hanya untuk PR di repositori yang sama dengan github.event.pull_request.head.repo.full_name == github.repository.

Deploy ke Perangkat

Setelah memahami channel, Anda siap mulai melakukan deploy Live Update ke perangkat asli. Proses dasarnya adalah:

1. Install Capgo SDK di aplikasi Anda
2. Konfigurasi aplikasi untuk mendengarkan channel yang diinginkan
3. Upload build dan assign ke channel tersebut
4. Jalankan aplikasi dan tunggu updatenya!

Untuk panduan yang lebih detail, lihat Deploy Live Updates panduan. Selamat melakukan update!

Penggunaan Channel Lanjutan: Segmentasi Pengguna

Channel bisa digunakan lebih dari sekadar tahap pengembangan. Ini adalah alat yang ampuh untuk segmentasi pengguna, memungkinkan fitur seperti:

• Feature flags untuk berbagai tier pengguna
• A/B testing
• Rollout fitur secara bertahap
• Program beta testing

Pelajari cara implementasi use case lanjutan ini di panduan kami: Cara Segmentasi Pengguna berdasarkan Plan dan Channel untuk Feature Flags dan A/B Testing.

Lanjutkan dari Channels

Jika Anda menggunakan Channel untuk merencanakan routing channel dan staged rollout, hubungkan dengan Channel untuk detail implementasi di Channels, Channel untuk detail implementasi di Channels, Solusi Beta Testing untuk alur kerja produk di Beta Testing Solution, Solusi Version Targeting untuk alur kerja produk di Version Targeting Solution, dan Praktik Terbaik Environment Capgo: Staging dengan Satu Mobile App ID untuk konteks praktis di Capgo Environment Best Practices: Staging dengan Satu Mobile App ID.