Workflow Native + Canal OTA

A common Capgo setup uses a développement et un canal production le canal. La CI télécharge chaque lot OTA à dev, puis promeut à production lorsque vous êtes prêt. Les équipes ajoutent souvent --fail-on-incompatible afin que la 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'est-ce que vous faites lorsque vous intentionnellement avez besoin d'un lot 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 en premier lieu 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 de magasin	Seuls les versions mises à jour 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 êtes en train de télécharger 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 la bannière)

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. --auto-min-update-version is obligatoire à chaque téléchargement dès que le canal utilise la metadata stratégie (recommandée ci-dessous). Si le canal n'est pas encore activé, vous pouvez omettre metadata jusqu'à ce que vous le changez. --auto-min-update-version Porte-voix CI facultatif avant téléchargement :

Fenêtre de terminal

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)

Sous-titre « Bump natif intentionnel (supprimez le flag une fois) »

context : fragment de texte HTML d'une chaîne de Capgo UI plus longue (clé parente `you_definition`). Page/zone : site Web de marketing Capgo. Rôle : paragraphe de marketing ou juridique long. Voir : page disclaimer.astro, page return.astro. Clé de message `you_definition` (Définition de vous). ne pouvez pas téléchargez un bundle qui nécessite un nouveau code natif tout en gardant --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 __CAPGO_KEEP_0__ correspondant binaire 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 le binaire ancien ne reçoivent pas le nouveau bundle avant qu'ils n'installent la nouvelle application.
4. Après cela, placez --fail-on-incompatible revenir à la CI OTA normale (et garder) --auto-min-update-version pendant que le canal reste activé 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. Téléchargez la base OTA correspondante (sans) --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 ce point de référence.

4. Reprendre 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 travail de CI dédié (ou une étape de libération manuelle), pas comme une exception que vous faites voler dans le travail d'OTA par défaut. Le travail par défaut doit toujours garder --fail-on-incompatible, et sur un metadata ce canal doit également conserver --auto-min-update-version.

FAQ

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

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

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

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

Je mets-je à jour vers dev tout 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 ligne sur le canal cible. Promouvez ou ré-uploadez vers production seulement après dev semble bien, et utilisez un téléchargement natif de base (sans --fail-on-incompatible) sur chaque canal qui nécessite les nouveaux paquets natifs enregistrés.

Qu'est-ce que je fais si je télécharge le nouveau paquet natif avec le flag toujours activé ?

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

Quel drapeau va sur quel emploi?

Chemin	Lorsque	Télécharger des drapeaux
OTA	Seulement JavaScript; les packages natifs correspondent au canal	--fail-on-incompatible + --auto-min-update-version Obligatoire si le canal est sur metadata)
Nouveau binôme natif + paquetage JS correspondant	Non	; garder --fail-on-incompatibleNative de base --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

Fil bundle releaseType en 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 ciblage de version de solutions). | Page/zone : Page de marketing de solutions Capgo. Rôle : Petit élément d'interface utilisateur ou élément de navigation. Vu dans : page solutions/version-targeting.astro. Clé de message `solutions_version_targeting` (Ciblage de version de 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 + Canal OTA pour garder les mises à jour en direct en sécurité à travers les versions natives, connectez-l’avec Compatibilité Native pour les règles de comparaison de package Auto OTA ou Native pour le branching CI 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/ciblage-de-version.astro. Message clé `solutions_ciblage_de_version_title` (Titre de ciblage de version de solutions). | Page/zone : page de marketing de solutions Capgo. Rôle : Étiquette de navigation ou élément UI court. Vu dans : page solutions/ciblage-de-version.astro. Message clé `solutions_ciblage_de_version` (Ciblage de version de solutions). Capgo CLI bundle reference __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ référentiel de bundle