Flux de travail Native + OTA Channel Workflow

Un setup commun Capgo utilise un canal de développement canal de production canal de production le canal. Les CI téléchargent tous les bundles OTA à devpuis promeuvent à 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'est-ce que vous faites lorsque vous intentionnellement avez besoin d'un bundle 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 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	Téléversement à chaque push CI de JS (et de baselines natives intentionnelles)
production	Utilisateurs de magasin	Seuls les mises à jour prêtes à l'emploi sont promues ou chargées

--fail-on-incompatible est une bonne valeur par défaut sur les deux canaux pour tous les téléchargements OTA quotidiens. Il compare les packages natifs du bundle que vous êtes en train de télécharger avec le bundle actuellement en ligne sur ce canal. Si ils diffèrent, le téléchargement sort avec un code d'erreur et rien n'est envoyé.

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 drifte vers une version native par inadvertance. --auto-min-update-version est requis à chaque fois que vous téléchargez une mise à jour, 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 configuriez. metadata Porte de contrôle CI facultatif avant 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

est requis à chaque fois que vous téléchargez une mise à jour, une fois que le canal utilise la stratégie (recommandée ci-dessous). Si le canal n'est pas encore configuré, vous pouvez omettre jusqu'à ce que vous le configuriez. envoyer un bundle qui nécessite une nouvelle native code tout en gardant --fail-on-incompatibleCe drapeau existe pour bloquer exactement ce cas. Lorsqu'un plugin, Capacitor version, ou autre dépendance native a changé intentionnellement :

1. Envoyer le binôme correspondant binnaire natif (App Store / Play Store, ou Capgo Build).
2. Envoyer 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 toujours sur l'ancien binôme ne reçoivent pas le nouveau bundle jusqu'à ce qu'ils installent la nouvelle application.
4. Après cette mise en ligne de base, mettez --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

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

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 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 job de CI dédié (ou une étape de libération manuelle), pas comme une exception que vous faites voler dans le job OTA par défaut. Le job par défaut doit toujours garder --fail-on-incompatible, et sur ce 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 lorsque 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 de la plateforme 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érive accidentel de la plateforme native échoue toujours à la CI.

Est-ce que je télécharge 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é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.

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

La CI échoue et Capgo ne délivre 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 native ci-dessus).

Quel drapeau va sur quel emploi ?

Chemin	Lorsque	Télécharger des drapeaux
OTA	Seul JavaScript ; les packages natifs correspondent au canal	--fail-on-incompatible + --auto-min-update-version (obligatoire si le canal est sur metadata)
Base native	Un nouveau binaire natif + un 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

Fil d'actualité bundle releaseType vers GitHub Actions ou GitLab afin que CI prenne le bon chemin.

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 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 l'IU courte ou élément de navigation. 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