Daftar checklist pengaturan sekali

Anda telah selesai onboarding. Sekarang konfigurasi Capgo sekali. Setelah itu, pekerjaan sehari-hari hanya unggah → tes → rilis.

Kirimkan sebuah build toko baru terlebih dahulu

Menginstal plugin Capgo di proyek Anda tidak cukup. Pembaruan OTA hanya berfungsi pada perangkat yang menjalankan aplikasi asli yang sudah termasuk plugin.

Setelah Anda menambahkan Capgo dan memanggil CapacitorUpdater.notifyAppReady():

1. Jalankan npx cap sync
2. Buat sebuah binary iOS / Android baru
3. Kirimkan ke App Store, Play Store, TestFlight, atau distribusi internal Anda

Pengguna di sebuah toko yang dibangun lebih lama tanpa plugin tidak akan pernah menerima pembaruan live. Mengunggah bundle ke Capgo hanya mempengaruhi perangkat pada sebuah Capgo-dijalankan biner.

Lihat juga penyelesaian masalah.

Aturan: saluran adalah jalur rilis (development, production), bukan tiket, fitur, atau nama pengembang.

---

Daftar checklist pengaturan satu kali

1. Buat saluran: pilih set terkecil yang sesuai (lihat di bawah).

2. Atur saluran unggah default di pengaturan aplikasi:

   • Solo app → production
   • Team → development

3. Saluran produksi: publik on, pengaturan perangkat sendiri off, blokir update di native on, pengaman auto-update on major.

4. Saluran uji (development / staging: publik off, pengaturan perangkat sendiri on untuk QA.

5. Unggah dari CI dengan --delta (checksum dan dependensi native otomatis):

   npx @capgo/cli@latest bundle upload \
     --channel development \
     --bundle "1.8.0-${BUILD_NUMBER}" \
     --comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \
     --delta

   The --bundle nilai harus sah versi semantik. Periksa di tester SemVer sebelum mengunggah.

6. Tayangkan ke produksi hanya setelah tes, dari Dashboard atau CLI.

7. Tim & Keamanan: undang sekali, hak akses minimal. 2FA untuk organisasi, satu API kunci di CI.

Kriptografi Keluaran, min_update_version, metadata, dan pratinjau mati kecuali Anda memiliki alasan yang jelas.

---

Pilih Ukuran Anda

Sederhana: 1 aplikasi, 1 saluran: production

Tim: development + production. Unggah ke dev, rilis ke prod.

Versi asli: tambahkan saluran hanya ketika diperlukan, misalnya production-9.0 + test-9.0. Tahan pengguna toko di saluran produksi utama.

Banyak aplikasi: model sederhana yang sama per aplikasi (biasanya satu production . Jangan membuat saluran tambahan hanya karena organisasi besar.

Relasi rilis (opsional): staging → rc → production. Template yang sama pada setiap aplikasi yang membutuhkannya.

Peringatan

Jangan gunakan saluran yang dinamai setelah tiket, orang, atau variabel CI seperti ${inputs_capgo_channel}.

---

Nama Paket vs Komentar

Nama paket harus diperlukan untuk mengikuti versi semantik. Capgo menggunakan semver untuk pengecekan kompatibilitas, aturan auto-update saluran, dan rollback. Validasi setiap nama dalam Pengujian SemVer sebelum diunggah.

• Nama = semver dari CI, misalnya 1.8.0, 1.8.0-beta.1, atau 1.8.0-20260629.42
• Komentar = teks bebas untuk manusia → commit abc1234 run 28059070270

Pakai semver versi pra-rilis label (bagian setelah -) ketika Anda mengirim banyak build di bawah versi yang sama. MAJOR.MINOR.PATCHContoh, simpan 1.8.0 dan tambahkan tanggal atau penomoran build di versi pra-rilis: 1.8.0-20260629.1, 1.8.0-beta.2. Tidaklah tepat menciptakan format semver sendiri, karena mereka tidak valid dan akan gagal atau berperilaku tidak terduga. fix-login-bug Masukkan catatan rilis di 2.5.2026062306, bukan di nama bundle.

Lihat juga --commentversi target

dan versi bundel Mengunggah Delta Judul bagian “Mengunggah Delta”.

---

mengunggah

--delta uploads manifest agar perangkat hanya mengunduh file yang berubah saja bukan bundle penuh setiap kali. Ceksum selalu dihitung secara otomatis.

Default: --delta (manifest + zip backup)

npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --delta

Rekomendasi default untuk aplikasi kebanyakan. Capgo menyimpan manifest dan menyimpan zip penuh sebagai cadangan. Baik ketika biaya penyimpanan bukanlah kekhawatiran utama.

Penghematan penyimpanan: --delta-only

npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \
  --delta-only

Gunakan --delta-only ketika Anda ingin mengurangi __CAPGO_KEEP_0__ penyimpanan. reduce Capgo storageKompromi: tanpa cadangan zip di server, Anda bergantung sepenuhnya pada jalur manifest. Lewatkan

kecuali Anda memang membutuhkan penghematan penyimpanan. --delta-only Tidak perlu konfigurasi plugin tambahan di perangkat. Pembarui membaca manifest dan mengambil file yang berubah hanya.

Tips

Lihat

Lihat Pembaruan delta untuk troubleshooting dan directUpdate perilaku.

---

Alur kerja harian

Upload to development (--delta)
  → test
  → deploy to production
  → don't touch channel settings again

---

Kesalahan umum

Kesalahan	Penyelesaian
Mengharapkan OTA sebelum rilis toko baru	Rebuild dan kirimkan aplikasi native setelah menambahkan plugin
Mengunggah sebuah bundle tetapi tidak menginstal ke sebuah saluran	Tetapkan bundle ke sebuah saluran (misalnya production)
Saluran per fitur, tiket, atau pengembang	Gunakan jalur rilis permanen hanya
Nama saluran CI dinamis	Nama-nama tetap: development, production
Terlalu banyak saluran untuk sebuah aplikasi sederhana	Mulai dengan 1-2 saluran
Perangkat menetapkan sendiri pada produksi	Mati untuk produksi, hidup untuk saluran uji
Mengabaikan --delta	Tambahkan --delta To unggah; gunakan --delta-only Hanya gunakan ketika Anda perlu menyimpan penyimpanan
Nama bundel non-semver	Ikuti versi semantik dan validasi di Pengujian SemVer
Mengubah skema versi secara waktu	Tetapkan semver; gunakan label pra-rilis untuk build tambahan (1.8.0-20260629.1)
Metadata / preview diaktifkan tanpa alasan	Biarkan default

---

Belajar lebih lanjut

Saluran Default, Prioritas, dan Pengaturan Jalur.

Pembaruan Delta Mengapa dan Bagaimana Menggunakan --delta.

CI/CD Automasi Unggah dan Deploy.

Bundel Checksum, Dependensi, dan Metadata.