Flux de travail Native + OTA Channel

Une configuration Capgo courante utilise un canal de développement canal de production canal de production le canal. Les CI téléchargent chaque paquet OTA à dev, puis promeut à production lorsque vous êtes prêt. Les équipes ajoutent souvent --fail-on-incompatible afin que CI ne puisse pas envoyer une mise à jour en direct qui nécessite de nouveaux code natifs par accident.

Cette page répond à la question suivante : qu'avez-vous à faire lorsque vous intentionnellement avez besoin d'un paquet incompatible avec les packages natifs actuels du canal ?

Si vous avez besoin du contexte sur pourquoi Capgo compare les packages natifs, commencez par Compatibilité native. Pour une branche CI complète qui choisit automatiquement OTA vs Capgo Build, voir Auto OTA ou Native.

Disposition de canal recommandée

Cette guide suppose que les dev et production channels existent déjà. Créez-les d'abord si nécessaire :

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

Canal	Qui le reçoit	Téléversement typique
dev	Constructions internes / QA	Chaque push CI de JS (et les baselines natives intentionnelles)
production	Utilisateurs du magasin	Seuls les mises à jour prêtes à l'emploi sont promues ou chargées

--fail-on-incompatible est une bonne valeur par défaut pour les deux canaux pour tous les téléchargements OTA quotidiensIl compare les packages natifs du bundle que vous chargez avec le bundle actuellement en ligne sur ce canalSi ils diffèrent, l'upload sort avec un code d'erreur et rien n'est envoyé

Téléchargement OTA quotidien (garder le drapeau)

Lorsque la modification est uniquement en JavaScript et que les packages natifs correspondent au canal :

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

--fail-on-incompatible évite les dérives natives involontaires. --auto-min-update-version est requis à chaque téléchargement une fois que le canal utilise la stratégie (recommandée ci-dessous). Si le canal n'est pas encore configuré, vous pouvez omettre metadata jusqu'à ce que vous le changez. metadata Porte-à-porte obligatoire avant le téléchargement : --auto-min-update-version Fenêtre de terminal

Copier dans le presse-papier

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)

Vous

ne pouvez pas ne pouvez pas téléchargez un bundle qui nécessite un nouveau code natif tout en conservant --fail-on-incompatibleCela existe pour bloquer exactement ce cas. Lorsqu'un plugin, la version Capacitor du Capacitor, ou d'autres dépendances natives ont changé intentionnellement :

1. Envoyez le binôme correspondant binnaire natif (App Store / Play Store, ou Capgo Build).
2. Téléchargez le bundle JS correspondant sans --fail-on-incompatible.
3. Préférez --auto-min-update-version avec le canal sur la metadata stratégie afin que les appareils qui sont toujours sur l'ancien binôme ne reçoivent pas le nouveau bundle jusqu'à ce qu'ils installent la nouvelle application.
4. Après cela, téléchargez --fail-on-incompatible revenir à la CI OTA normale (et garder) --auto-min-update-version pendant que le canal reste actif metadata).

1. Une fois par canal : activer la gestion des métadonnées

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

   Répéter pour dev Si ce canal reçoit également des baselines natives intentionnelles. Après ce basculement, chaque mise à jour vers le canal doit inclure --auto-min-update-version ou --min-update-version.

2. Envoyer le binaire natif

   Construirez et soumettons l'application iOS/Android qui inclut les nouveaux plugins ou les modifications natives. Jusqu'à ce que les utilisateurs installent ce binôme, ils ne peuvent pas exécuter en toute sécurité un bundle qui dépend de ces packages natives.

3. Charger la ligne de base OTA correspondante (sans mise à jour) --fail-on-incompatible)

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

   Cela enregistre les nouveaux packages natifs sur le canal. Plus tard bundle releaseType / --fail-on-incompatible les vérifications utilisent cette base de référence.

4. Rétablir les téléchargements OTA protégés

   Les sorties JS uniquement utilisent à nouveau les deux drapeaux :

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

Conseil

Traitez l'envoi de la base native comme un job CI dédié (ou une étape de publication manuelle), et non comme une exception que vous ajoutez à l'emploi du temps par défaut. L'emploi du temps par défaut doit toujours conserver --fail-on-incompatible, et sur un metadata il doit également conserver --auto-min-update-version.

FAQ

Peut-on conserver --fail-on-incompatible et pousser quand même un bundle incompatible avec la plateforme native ?

Non. Si les packages natifs de l'upload diffèrent du bundle live du canal, le flag fait fail le commandement intentionnellement. Pour une mise à niveau native intentionnelle, omittez le flag sur cet upload (et utilisez --auto-min-update-version Quand vous le pouvez).

Est-ce que l'upload sans le flag une seule fois est la bonne approche ?

Oui. C'est la méthode supportée pour faire avancer la base native du canal après que vous ayez expédié un nouveau binaire. Conservez le flag sur chaque autre OTA upload afin que le dérive accidentel de la plateforme native faille toujours la CI.

Je mets-je à jour vers dev d'abord, puis production?

Oui, si cela correspond à votre processus. Exécutez les mêmes règles par canal : la vérification de compatibilité est effectuée par rapport à ce qui est en direct sur le canal cible. Promouvez ou ré-uploadez vers production seulement après dev semble bien, et utilisez une mise à jour native de base (sans --fail-on-incompatible) sur chaque canal qui nécessite les nouveaux packages natives enregistrés.

Qu'est-ce si je mets-je à jour le nouveau bundle natif avec le flag toujours activé ?

La CI faille et Capgo ne démarre pas cette mise à jour. C'est l'issue attendue. Soit la modification était accidentelle (corrigez les packages natifs et réessayez en tant qu'OTA), soit elle était intentionnelle (utilisez la voie native ci-dessus).

Quel drapeau va sur quel travail?

Chemin	Lorsque	Télécharger les drapeaux
OTA	Seulement JavaScript; les packages natifs correspondent au canal	--fail-on-incompatible + --auto-min-update-version (obligatoire si le canal est sur metadata)
Niveau natif de base	Nouveau binaire natif + bundle JS correspondant	Non --fail-on-incompatible; garder --auto-min-update-version

Liés

Compatibilité native

Comment Capgo détecte les dérives de packages natifs et ce que cela signifie pour les appareils incompatibles.

Auto OTA ou Native

Wire bundle releaseType vers GitHub Actions ou GitLab afin que CI prenne la bonne voie.

Ciblage de version

context : Page/zone : Page de marketing de solutions Capgo. Rôle : En-tête de section ou de page. Vu dans : page solutions/version-targeting.astro. Clé de message `solutions_version_targeting_title` (Titre de la cible de version des solutions). | Page/zone : Page de marketing de solutions Capgo. Rôle : Étiquette de navigation ou élément de menu court. Vu dans : page solutions/version-targeting.astro. Clé de message `solutions_version_targeting` (Ciblage de version des solutions).

CLI: bundle

__CAPGO_KEEP_0__: bundle

Référence pour l'upload, la compatibilité, releaseType et les drapeaux liés ; 

Si vous utilisez Native + OTA Channel Workflow pour garder les mises à jour en direct en sécurité à travers les versions natives, connectez-l’avec Native Compatibility pour les règles de comparaison de package Auto OTA ou Native pour le branching CI Version Targeting context : Page/zone : Page de marketing de solutions Capgo. Rôle : En-tête de section ou de page. Vu dans : page solutions/version-targeting.astro. Message clé `solutions_version_targeting_title` (Titre de la version ciblée des solutions). | Page/zone : Page de marketing de solutions Capgo. Rôle : Étiquette de navigation ou élément UI court. Vu dans : page solutions/version-targeting.astro. Message clé `solutions_version_targeting` (Version ciblée des solutions). Capgo CLI bundle reference __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ référentiel de bundle