Alur Kerja Saluran Native + OTA

Konfigurasi umum Capgo menggunakan sebuah dev saluran pengembang dan sebuah saluran produksi channel. CI mengunggah setiap bundle OTA ke devSetelah itu, mempromosikan ke production ketika Anda sudah siap. Tim sering menambahkan --fail-on-incompatible jadi CI tidak bisa mengirimkan live update yang memerlukan code native baru secara tidak sengaja.

Halaman ini menjawab pertanyaan lanjutan: apa yang harus Anda lakukan ketika Anda memiliki niat memerlukan bundle yang tidak kompatibel dengan paket native channel saat ini?

Jika Anda membutuhkan latar belakang mengapa Capgo membandingkan paket native, mulai dengan Pengkompatibilitas Native. Untuk cabang CI penuh yang memilih OTA vs Capgo Build secara otomatis, lihat Auto OTA atau Native.

Rancangan Channel yang Dianjurkan

Petunjuk ini mengasumsikan bahwa dev dan production saluran sudah ada. Buatlah terlebih dahulu jika diperlukan:

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

Saluran	Who gets it	Pengunggahan biasa
dev	Rilis internal / QA	Setiap push CI dari JS (dan dasar native sengaja)
production	Pengguna toko	Ditampilkan atau diunggah hanya ketika rilis siap

--fail-on-incompatible adalah pilihan default yang baik pada kedua saluran untuk setiap upload OTA sehari-hari. Ini membandingkan paket native di dalam bundle yang Anda unggah terhadap bundle yang sedang berjalan pada saluran tersebut. Jika mereka berbeda, upload keluar dengan kode keluaran non-nol dan tidak ada yang dikirim.

Setiap hari OTA (tahanlah flag)

Ketika perubahan hanya JavaScript dan paket native sesuai dengan saluran:

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

--fail-on-incompatible mencegah pergeseran native tidak sengaja. --auto-min-update-version adalah diperlukan pada setiap upload setelah saluran menggunakan metadata strategi (direkomendasikan di bawah). Jika saluran tidak berada di metadata belum ada, Anda dapat mengabaikan --auto-min-update-version belum ada, Anda dapat mengabaikan

Gate CI opsional sebelum unggah:

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)

Peningkatan native sengaja (angkat flag sekali)

Anda context mengunggah sebuah paket yang memerlukan native code yang baru sambil menjaga --fail-on-incompatibleKetika sebuah plugin, versi Capacitor, atau dependensi native lainnya berubah secara sengaja:

1. Kirimkan versi yang sesuai biner native (App Store / Play Store, atau Capgo Pembangunan).
2. Upload bundle JS yang sesuai without --fail-on-incompatible.
3. tanpa --auto-min-update-version dengan saluran di metadata dengan saluran pada strategi sehingga perangkat yang masih menggunakan versi lama tidak menerima bundle baru sampai mereka menginstal aplikasi baru.
4. Setelah itu unggah dasar, masukkan --fail-on-incompatible sedangkan saluran tetap pada --auto-min-update-version sambil saluran tetap berada metadata).

1. Satu kali per saluran: mengaktifkan pengaturan metadata

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

   Ulangi untuk dev jika saluran tersebut juga menerima native baseline yang disengaja. Setelah perubahan ini, setiap unggahan ke saluran harus termasuk --auto-min-update-version atau --min-update-version.

2. Kirimkan file biner asli

   Build and submit the iOS/Android app that includes the new plugins or native changes. Until users install that binary, they cannot safely run a bundle that depends on those native packages.

3. Uploadkan basis OTA yang sesuai (tidak --fail-on-incompatible)

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

   Unggah baseline OTA yang sesuai (tidak ada bundle releaseType / --fail-on-incompatible Periksa menggunakan dasar tersebut.

4. Mulai kembali unggahan OTA yang dilindungi.

   Rilis JS-only berikutnya menggunakan kedua flag lagi:

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

Trik

Tentukan unggahan native-baseline sebagai pekerjaan CI yang terpisah (atau langkah rilis manual), bukan sebagai pengecualian yang Anda taburkan ke dalam pekerjaan OTA default. Pekerjaan default harus selalu menjaga --fail-on-incompatibledan pada metadata channel harus tetap --auto-min-update-version.

FAQ

Bisa saya menjaga --fail-on-incompatible Apakah saya bisa tetap memasukkan bundle tidak kompatibel?

No. If the upload’s native packages differ from the channel’s live bundle, the flag fails the command on purpose. For an intentional native bump, omit the flag on that one upload (and use --auto-min-update-version Ketika Anda dapat melakukannya.

Apakah pendistribusian satu kali saja tanpa menggunakan flag yang tepat?

Yes. That is the supported way to advance the channel’s native baseline after you ship a new binary. Keep the flag on every other OTA upload so accidental native drift still fails CI.

Apakah saya harus mengunggah ke dev Pertama, kemudian production?

Ya, jika itu sesuai dengan proses Anda. Jalankan aturan yang sama per saluran: cek kompatibilitas melawan apa yang hidup di saluran target. Promosikan atau unggah ulang ke production setelah dev terlihat baik, dan gunakan unggahan dasar native (tanpa --fail-on-incompatible) pada setiap saluran yang membutuhkan paket native baru direkam.

Apa jika saya mengunggah bundle native baru dengan flag masih aktif?

CI gagal dan Capgo tidak mengirim unggahan tersebut. Itu adalah hasil yang diharapkan. Atau perubahan itu tidak sengaja (perbaiki paket native dan coba lagi sebagai OTA), atau itu sengaja (gunakan jalur native di atas).

Flag mana yang harus ditempatkan di mana job?

Rute	Ketika	Flag unggah
OTA	Hanya JS; paket native sesuai dengan saluran	--fail-on-incompatible + --auto-min-update-version (diperlukan jika saluran berada di metadata)
Native Baseline	Binary baru native + bundle JS yang sesuai	; simpan --fail-on-incompatibleTerhubung --auto-min-update-version

Related

Kompatibilitas Nama Domain

Bagaimana Capgo mendeteksi perubahan paket native dan apa yang berarti tidak kompatibel untuk perangkat.

Auto OTA atau Nama Domain

Wire bundle releaseType ke dalam GitHub Actions atau GitLab sehingga CI memilih jalur yang tepat.

Targeting Versi

Saluran, aturan semver, dan strategi metadata untuk lantai pengiriman.

CLI: paket

Referensi untuk unggah, kompatibilitas, tipe rilis, dan flag terkait.

Teruskan dari Alur Kerja Saluran Native + OTA

Jika Anda menggunakan Alur Kerja Saluran Native + OTA untuk menjaga pembaruan live aman di rilis native, hubungkannya dengan Kompatibilitas Native untuk aturan perbandingan paket, Auto OTA atau Native untuk cabang CI, Pencarian Versi untuk lantai metadata, dan Capgo CLI referensi bundle __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ referensi paket