Channel

Saluran Live Update menunjuk ke build bundle JS tertentu dari aplikasi Anda yang akan dibagikan ke semua perangkat yang dikonfigurasi untuk mendengarkan pembaruan pada saluran tersebut. Ketika 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.

Jawaban singkat: untuk staging dan production di aplikasi Capacitor, buat sebuah staging dan production channel di Capgo, upload setiap bundle ke staging terlebih dahulu, uji coba, lalu promosikan bundle yang sama ke production.

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. Ini 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 menulis backend override sebagai gantinya; penetapan tersebut mengikuti aturan retensi override console dan API.

Tester mengaktifkan update beta 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 dissociate/associate sendiri 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 tersebut 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.

Unduh video override perangkat di konsol (MP4).

Gunakan override untuk testing atau support yang ditargetkan. Override ini diprioritaskan di atas channel lokal perangkat dan default cloud, kecuali ada forced mapping. Override Console dan API kedaluwarsa 90 hari setelah override terakhir ditulis.

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

Channel Tidak Menjamin Kerahasiaan

Channel mengatur 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 sudah dikirim tetap bisa di-reverse engineer dari aplikasi yang didistribusikan dengan usaha yang cukup, karena public key merupakan bagian dari client. Lihat enkripsi Live Update detailnya.

Cara perangkat memilih channel (urutan prioritas)

Saat perangkat memeriksa update, Capgo menentukan channel yang digunakan dengan urutan ketat berikut (prioritas tertinggi di awal):

1. Pemetaan perangkat dipaksa (Dashboard) – Pin ID perangkat tertentu ke channel secara manual. Gunakan untuk debugging mendesak atau pengujian terkontrol dengan satu pengguna nyata. Ini selalu menang. Capgo menghapus pemetaan 90 hari setelah penulisan override terakhir. Lihat Override dari Console dan API kedaluwarsa setelah 90 hari.
2. Override cloud (per-perangkat) via Dashboard atau API – Dibuat saat Anda mengubah channel perangkat di dashboard atau via API. Gunakan untuk pengguna QA yang berpindah antar channel feature / PR atau untuk mereproduksi masalah pengguna. Menginstal ulang binary tidak menghapusnya; menghapus override perangkat melakukannya. Retensi 90 hari yang sama berlaku.
3. Plugin setChannel() channel lokal – Dibuat saat aplikasi memanggil setChannel() dan backend memvalidasi bahwa channel target mengizinkan self-assignment. Channel yang dipilih disimpan secara lokal di perangkat tersebut, langsung berlaku, dan tidak ditampilkan di UI Device Override.

Pergantian channel instan dengan setChannel()

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

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

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

Catatan: Bahkan jika channel menjadi tidak diizinkan setelah disetel secara lokal, backend tetap akan memvalidasi channel selama pengecekan update, sehingga keamanan tetap terjaga.

Penting: Ketika perubahan channel dilakukan melalui Dashboard atau API, masih ada lag replikasi hingga 2 menit sebelum semua edge server mencerminkan perubahan tersebut. Untuk switching channel instan, gunakan setChannel() dari code aplikasi Anda—hal ini divalidasi dengan backend, lalu mengatur channel secara lokal untuk efek langsung.

4. config Capacitor defaultChannel (default untuk test build) – Jika ada di dalam capacitor.config.* dan tidak ada channel force/override/local, aplikasi akan mulai di channel ini (misal. beta, qa, pr-123). Ditujukan untuk TestFlight / internal build agar tester otomatis masuk ke channel pre-release. Production build biasanya membiarkan ini kosong.
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 binary baru. Jika Anda punya default spesifik platform (misal, satu khusus iOS, satu khusus Android, satu khusus Electron), setiap perangkat akan masuk ke default yang sesuai platformnya. Membiarkan cloud default kosong diperbolehkan; jika demikian, perangkat harus memenuhi langkah 1–4 untuk menerima update.

Praktik terbaik:

• Anggap 1–4 sebagai layer pengecualian / testing; saat Anda mengatur cloud default, pengguna nyata harus masuk ke sana. Jika Anda memilih untuk tidak mengaturnya, pikirkan matang cara pengguna terhubung (biasanya melalui defaultChannel di config atau per-device override).
• Hanya konfigurasikan defaultChannel pada binary yang Anda kirimkan secara eksplisit ke tester. Membiarkannya kosong menjaga logika production tetap terpusat di dashboard.
• Gunakan setChannel() secukupnya di produksi—terutama untuk QA atau diagnostik yang ditargetkan.

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

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

Override dari Console dan API kedaluwarsa setelah 90 hari

Pemetaan paksa dan override channel Dashboard atau Publik API disimpan sebagai penugasan per perangkat di Capgo. Job pembersihan menghapus penugasan tersebut 90 hari setelah penulisan override terakhir. Pengecekan update tidak mereset jam tersebut. Hanya penulisan ulang override (atau penghapusannya secara manual) yang 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 perangkat hanya menampilkan log konsol dan penugasan API Publik. Mereka tidak menampilkan semua perangkat di channel, dan tidak menampilkan lokal setChannel() penugasan.

Peringatan retensi Override di tab Perangkat channel.

Perilaku Channel Default

Menetapkan default cloud bersifat opsional, tetapi biasanya berfungsi sebagai jalur catch-all untuk perangkat baru. Tanpa default, hanya perangkat yang cocok dengan pemetaan paksa, override, atau defaultChannel di konfigurasi Capacitor yang akan menerima update. Saat Anda memilih untuk menandai default, perhatikan pola berikut:

• Default tunggal (paling umum) – Jika sebuah channel memiliki iOS, Android, dan Electron yang diaktifkan, channel tersebut menjadi default tunggal; perangkat apa pun tanpa override akan terhubung ke sini.
• Default spesifik platform – Jika Anda memisahkan channel berdasarkan platform (misalnya, ios-production dengan hanya iOS diaktifkan, android-production dengan hanya Android diaktifkan, dan electron-production dengan hanya Electron diaktifkan), tandai masing-masing sebagai default untuk platformnya. Perangkat iOS akan ke default iOS, perangkat Android ke default Android, dan aplikasi Electron ke default Electron.

Ingat bahwa default cloud dan defaultChannel di capacitor.config.* keduanya menempati lapisan keputusan yang sama. Jika Anda menetapkan default cloud, Anda tidak perlu menduplikasi nilai tersebut di konfigurasi Capacitor Anda—biarkan defaultChannel kosong untuk build produksi. Sisakan defaultChannel untuk binary yang sengaja Anda kirim ke tester atau QA agar mereka mulai di channel non-produksi, meskipun default cloud berbeda.

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

Menyiapkan Channel

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

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

Nama channel bisa bebas Anda tentukan. Strategi umum yang sering digunakan adalah menyesuaikan channel dengan tahapan pengembangan Anda, seperti:

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

Konfigurasi Channel di App Anda

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

Buka capacitor.config.ts (atau capacitor.config.json) file. Di bawah plugins section, secara opsional setel defaultChannel untuk build pengujian (internal / QA). Untuk production builds, lebih baik diabaikan agar perangkat menggunakan Cloud Default kecuali di-override 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 yang diperbarui ke proyek iOS, Android, dan Electron Anda. Jika Anda melewatkan langkah sync ini, proyek native Anda akan tetap menggunakan channel yang sebelumnya dikonfigurasi.

Peringatan

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

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

Anda tetap bisa memaksa (pin) perangkat atau menerapkan override nanti—keduanya langsung menggantikan nilai konfigurasi.

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 mengekspos target rollout terpisah ke cohort perangkat sticky. Anda bisa menjeda, melanjutkan, mempromosikan, melakukan rollback, dan mengatur respons kegagalan otomatis tanpa mengalihkan 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 yang akan dikirim 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 apa pun pada nomor major, minor, atau patch. Hanya perubahan suffix yang diizinkan selama 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: Meminta metadata versi update minimum pada setiap bundle. Konfigurasi melalui CLI menggunakan --min-update-version atau --auto-min-update-version. Jika tidak diisi, channel ditandai sebagai misconfigured dan update akan ditolak sampai diatur.
• none: Izinkan semua update sesuai dengan kompatibilitas semver.

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

Pelajari detail dan contoh lebih lanjut tentang Disable updates strategy di /docs/cli/commands/#disable-updates-strategy.

Contoh (CLI). Channel harus sudah ada (channel set tidak 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 beralih channel secara programatik saat runtime. Ini sangat berguna untuk:

• Menu QA/debug untuk tester berpindah 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 memvalidasi channel diizinkan (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	Waktu Efektif	Disimpan di	Tampil di UI Override Perangkat	Kedaluwarsa	Kasus Penggunaan
setChannel() dari plugin	Instan	Hanya perangkat (lokal)	Tidak	Tidak ada kedaluwarsa otomatis; hapus dengan unsetChannel() (reinstall mungkin menyimpannya)	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 pengalih channel, selalu gunakan plugin’s setChannel() metode.

Versi minimum untuk pengalih channel lokal saja: 5.34.0, 6.34.0, 7.34.0, atau 8.0.0 (tergantung pada versi mayor Anda). Setiap nomor versi minor sesuai dengan set fitur yang sama di semua versi mayor (misalnya, X.34.0 mencakup fitur yang sama apakah X adalah 5, 6, 7, atau 8). Lihat instalasi plugin untuk tag versi.

Menetapkan Bundle ke Channel

Untuk mendeploy live update, Anda perlu mengunggah build bundle JS baru dan menugaskannya ke channel. Anda dapat 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. Aplikasi apa pun yang dikonfigurasi untuk listen ke channel itu akan menerima update pada 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

Perlu dicatat bahwa bundle di Capgo bersifat global untuk aplikasi Anda, bukan spesifik per channel. Bundle yang sama bisa ditetapkan ke beberapa channel.

Saat melakukan versioning pada bundle Anda, kami menyarankan menggunakan semantic versioning dengan Semver Tester dari Capgo dan pre-release identifier untuk build khusus channel. Misalnya, rilis beta bisa diberi versi seperti 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 hingga nama bebas ditemukan. Dengan ai, Workers AI menyimpulkan level dari delta manifest lokal vs sebelumnya (fallback ke patch tanpa versi Capgo sebelumnya). Anda tidak dapat menggabungkannya dengan --bundle. Lihat Integrasi CI/CD dan referensi CLI.

Pendekatan ini memiliki beberapa keuntungan:

• Ini dengan jelas menunjukkan hubungan antar build. 1.2.3-beta.1 jelas merupakan pre-release dari 1.2.3.
• Memungkinkan penggunaan ulang nomor versi lintas channel, mengurangi kebingungan.
• 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 bagaimana Anda dapat menyelaraskan versi bundle Anda dengan setup channel yang umum:

• 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.

Check out the 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

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

Deploy ke Perangkat

Sekarang setelah Anda memahami channel, Anda siap mulai mendeploy live update ke perangkat nyata. Proses dasarnya adalah:

1. Pasang Capgo SDK di aplikasi Anda
2. Konfigurasi aplikasi untuk mendengarkan channel yang Anda inginkan
3. Upload build dan assign ke channel tersebut
4. Jalankan app dan tunggu update!

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

Penggunaan Channel Lanjutan: Segmentasi Pengguna

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

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

Pelajari cara mengimplementasikan 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 workflow produk di Beta Testing Solution, Solusi Version Targeting untuk workflow produk di Version Targeting Solution, dan Praktik Terbaik Environment Capgo: Staging dengan Satu Mobile App ID untuk konteks praktis dalam Capgo Environment Best Practices: Staging dengan Satu Mobile App ID.