Flux de travail Native + OTA Channel

Un setup commun Capgo utilise un dev canal de production production CI télécharge chaque bundle OTA vers devpuis promeut vers production Lorsque vous êtes prêt. Les équipes ajoutent souvent --fail-on-incompatible Le CI ne peut pas envoyer un live update qui nécessite de nouvelles code natives par erreur.

Cette page répond à la question suivante : Qu'avez-vous à faire lorsque vous avez l'intention de nécessiter un bundle incompatible avec les packages natives actuels du canal ?

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

Disposition de canal recommandée

Ce guide suppose que les dev et production canaux 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	Tous les CI push de JS (et les baselines natives intentionnelles)
production	Store users	Seulement promu ou téléchargé lorsque prêt à la publication.

--fail-on-incompatible est une bonne valeur par défaut pour les deux canaux. tous les téléchargements OTA quotidiens.. Il compare les packages natifs dans le bundle que vous téléchargez avec le bundle actuellement disponible sur ce canal.Si elles diffèrent, l'upload se termine avec un code non nul et rien n'est envoyé.

Téléchargement OTA quotidien (conservez 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 empêche les dérives natives accidentelles. --auto-min-update-version est requis pour chaque téléchargement une fois que le canal utilise le metadata stratégie (recommandée ci-dessous). Si le canal n'est pas sur metadata encore, vous pouvez omettre --auto-min-update-version jusqu'à ce que vous le changez.

Porte-voix CI facultatif avant téléchargement :

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)

Augmentation native intentionnelle (supprimez le flag une fois)

Vous cannot télécharger un bundle qui nécessite de nouvelles code natives tout en conservant --fail-on-incompatibleLorsqu'un plugin, la version Capacitor, ou d'autres dépendances natives ont été modifiées intentionnellement :

1. Expédiez le binôme correspondant binaire natif (App Store / Play Store, ou Capgo Build).
2. Téléchargez le bundle JS correspondant without --fail-on-incompatible.
3. sans --auto-min-update-version avec le canal sur le metadata Les appareils qui utilisent encore la version binaire ancienne ne recevront pas le nouveau bundle avant d'avoir installé la nouvelle application.
4. Après cela, téléchargez --fail-on-incompatible Après cette mise à niveau initiale, remettez --auto-min-update-version sur le CI OTA normal (et maintenez-le 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 téléchargement vers le canal doit inclure --auto-min-update-version ou --min-update-version.

2. Déployez le binaire natif

   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. Téléchargez la ligne de 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 Utilisez cette base de référence.

4. Résumé des téléchargements OTAs 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é (n'oubliez pas de le faire, ni comme exception, que vous ajoutez à la tâche OTA par défaut. La tâche par défaut doit toujours garder) --fail-on-incompatibleet sur une metadata channel il devrait également conserver --auto-min-update-version.

FAQ

Peut-on conserver --fail-on-incompatible Et pouvons-nous toujours envoyer un bundle non compatible ?

Non. Si les packages natifs de l'upload diffèrent de la mise à jour live du canal, la flag fait échouer la commande intentionnellement. --auto-min-update-version lorsque vous le pouvez).

Est-ce que l'upload unique sans le flag est la bonne approche ?

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.

Do I upload to dev d'abord, ensuite production?

Oui, si cela correspond à votre processus. Exécutez les mêmes règles par canal: la vérification de compatibilité est effectuée contre ce qui est en ligne sur le canal cible. Promouvez ou rétéléchargez 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 paquets natives enregistrés.

Quoi si je télécharge le nouveau bundle natif avec le drapeau toujours activé ?

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

Lequel des drapeaux est appliqué à quel job ?

Chemin	Lorsque	Drapeaux d'upload
OTA	JS uniquement ; 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

Relié

Compatibilité native

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

Auto OTA ou natif

Fil bundle releaseType vers GitHub Actions ou GitLab afin que CI sélectionne la bonne voie.

Ciblage de version

Canaux, règles de semver et stratégie de métadonnées pour les étages de livraison.

CLI: paquet

Référence pour l'upload, la compatibilité, le type de version et les drapeaux associés.

Continuez de la workflow de canal Native + OTA

Si vous utilisez Flux de travail Native + OTA Pour garder les mises à jour en direct en sécurité lors des sorties natives, connectez-l’avec Compatibilité Native pour les règles de comparaison de package, Auto OTA ou Native pour la branche de CI, Ciblage de version pour les métadonnées des étages Capgo CLI référence de bundle __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ référentiel de bundle