Workflow Channel Native + OTA

Setup Capgo yang umum menggunakan dev channel dan produksi channel. CI mengunggah setiap OTA bundle ke dev, lalu dipromosikan ke production saat Anda siap. Tim sering menambahkan --fail-on-incompatible agar CI tidak tidak sengaja mengirim live update yang butuh code baru.

Halaman ini menjawab pertanyaan berikut: apa yang Anda lakukan saat intentionally butuh bundle yang tidak kompatibel dengan native packages channel saat ini?

Jika butuh latar belakang mengapa Capgo membandingkan native packages, mulai dari Kompatibilitas Native. Untuk CI branch lengkap yang memilih OTA vs Capgo Build secara otomatis, lihat Auto OTA atau Native.

Layout channel yang direkomendasikan

Panduan ini mengasumsikan dev dan production channel sudah ada. Buat dulu jika perlu:

npx @capgo/cli@latest channel add production com.example.app
npx @capgo/cli@latest channel add dev com.example.app

Channel	Who gets it	Upload umum
dev	Build Internal / QA	Setiap push JS di CI (dan baseline native yang disengaja)
production	User di Store	Dipromosikan atau di-upload hanya saat siap rilis

--fail-on-incompatible adalah default yang bagus di kedua channel untuk upload OTA harian. Ini membandingkan paket native dalam bundle yang Anda upload dengan bundle sedang aktif di channel tersebut. Jika berbeda, upload akan error dan tidak ada yang dikirim.

OTA harian (pertahankan flag)

Saat perubahan hanya pada JavaScript dan package native sesuai dengan channel:

npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --fail-on-incompatible \
  --auto-min-update-version

--fail-on-incompatible mencegah native drift yang tidak disengaja. --auto-min-update-version wajib ada di setiap upload setelah channel menggunakan metadata strategi (direkomendasikan di bawah). Jika channel belum menggunakan metadata , Anda bisa mengabaikan --auto-min-update-version sampai Anda melakukan switch.

Opsional: CI gate sebelum upload:

npx @capgo/cli@latest bundle releaseType com.example.app --channel production
# → OTA      safe to upload with --fail-on-incompatible
# → native   stop; ship a native binary first (see below)

Native bump yang disengaja (hapus flag sekali saja)

Anda tidak bisa upload bundle yang butuh code native baru sambil tetap --fail-on-incompatible. Flag tersebut ada untuk memblokir kasus itu. Saat plugin, versi Capacitor, atau dependensi native lainnya sengaja diubah:

1. Rilis versi yang sesuai binary native (App Store / Play Store, atau Build Capgo).
2. Upload JS bundle yang sesuai tanpa --fail-on-incompatible.
3. Utamakan --auto-min-update-version dengan channel pada metadata strategi agar perangkat yang masih menggunakan binary lama tidak menerima bundle baru sampai mereka menginstal aplikasi baru.
4. Setelah baseline upload tersebut, kembalikan --fail-on-incompatible ke alur CI OTA normal (dan tetap) --auto-min-update-version selama channel tetap pada metadata).

1. Sekali per channel: aktifkan metadata gating

   npx @capgo/cli@latest channel set production com.example.app --disable-auto-update metadata

   Ulangi untuk dev jika channel tersebut juga menerima native baseline secara sengaja. Setelah switch ini, setiap upload ke channel tersebut harus menyertakan --auto-min-update-version atau --min-update-version.

2. Rilis native binary

   Build dan submit aplikasi iOS/Android yang menyertakan plugin baru atau perubahan native. Sebelum user menginstal binary tersebut, mereka tidak bisa menjalankan bundle yang bergantung pada native package tersebut dengan aman.

3. Upload OTA baseline yang sesuai (tidak --fail-on-incompatible)

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --auto-min-update-version

   Ini mencatat native package baru pada channel. Nantinya, bundle releaseType / --fail-on-incompatible akan menggunakan baseline tersebut.

4. Lanjutkan upload OTA yang aman

   Rilis JS-only berikutnya akan menggunakan kedua flag lagi:

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --fail-on-incompatible \
     --auto-min-update-version

Tips

Anggap upload native-baseline sebagai job CI khusus (atau langkah rilis manual), bukan sebagai pengecualian yang disisipkan ke dalam job OTA default. Job default harus selalu menjaga --fail-on-incompatible, dan pada metadata channel juga harus menjaga --auto-min-update-version.

FAQ

Bisakah saya tetap --fail-on-incompatible dan tetap push bundle yang tidak kompatibel secara native?

Tidak. Jika native package pada upload berbeda dari live bundle di channel tersebut, flag ini sengaja akan menggagalkan command tersebut. Untuk melakukan native bump yang disengaja, hapus flag tersebut pada satu kali upload itu (dan gunakan --auto-min-update-version saat memungkinkan).

Apakah upload satu kali tanpa flag adalah pendekatan yang tepat?

Ya. Itu adalah cara resmi untuk memperbarui native baseline pada channel setelah Anda merilis binary baru. Tetap gunakan flag tersebut pada setiap upload OTA lainnya agar accidental native drift tetap menggagalkan CI.

Apakah saya upload ke dev pertama, kemudian production?

Ya, jika itu sesuai dengan workflow Anda. Jalankan aturan yang sama per channel: pengecekan kompatibilitas dilakukan terhadap apa pun yang sedang live di channel target. Promote atau upload ulang ke production hanya setelah dev terlihat oke, dan gunakan native-baseline upload (tanpa --fail-on-incompatible) di setiap channel yang paket native barunya perlu dicatat.

Bagaimana jika saya upload bundle native baru saat flag masih aktif?

CI gagal dan Capgo tidak mengirimkan upload tersebut. Itu adalah hasil yang diharapkan. Entah perubahannya tidak sengaja (perbaiki paket native dan coba lagi sebagai OTA), atau memang disengaja (gunakan jalur native di atas).

Flag mana yang dipakai untuk job mana?

Path	Saat	Flag upload
OTA	Hanya JS; paket native harus sesuai channel	--fail-on-incompatible + --auto-min-update-version (wajib jika channel berada di metadata)
Baseline Native	Binary native baru + JS bundle yang sesuai	Tidak --fail-on-incompatible; tetap --auto-min-update-version

Terkait

Kompatibilitas Native

Cara Capgo mendeteksi drift paket native dan arti ketidakcocokan bagi perangkat.

Auto OTA atau Native

Hubungkan bundle releaseType ke GitHub Actions atau GitLab agar CI memilih jalur yang tepat.

Targeting Versi

Channel, aturan semver, dan strategi metadata untuk delivery floors.

CLI: bundle

Referensi untuk upload, kompatibilitas, releaseType, dan flag terkait.

Lanjutkan dari Native + OTA Channel Workflow

Jika Anda menggunakan Alur Kerja Native + OTA Channel agar Live Update tetap aman di setiap native release, hubungkan dengan Kompatibilitas Native untuk aturan perbandingan package, Auto OTA atau Native untuk branching CI, Targeting Versi untuk metadata floors, dan referensi bundle Capgo CLI untuk flag upload.