Cómo mantener actualizaciones de Capgo ligero y rápido

La mejor actualización en vivo es la que apenas nota el usuario.

Eso suele significar tres cosas:

1. La descarga es pequeña.
2. El despliegue está controlado.
3. La recuperación es instantánea si algo sale mal.

El mismo consejo de 'mantén OTA delgado' que funciona en el territorio de React Native también se aplica a Capgo. La diferencia es que Capgo da a los equipos de Capacitor un par de palancas adicionales: Actualizaciones delta, canales, rollback automático, objetivos de versióny cifrado de extremo a extremo opcional Si los utiliza juntos, obtiene paquetes más pequeños, instalaciones más rápidas y mucho menos desorden operativo..

Importa incluso cuando el MAU permanece igual

Un detalle útil específico de __CAPGO_KEEP_0__: el MAU de __CAPGO_KEEP_1__ es efectivamente el número de dispositivos activos mensuales que contactaron con el servicio de actualización en los últimos 30 días.

One useful Capgo-specific detail: Capgo MAU is effectively the number of monthly active devices that contacted the update service in the last 30 days.

__CAPGO_KEEP_1__ es el número de dispositivos activos mensuales que contactaron con el servicio de actualización en los últimos 30 días.

• Descargas más rápidas en celular o Wi-Fi débil
• Mejor experiencia con actualizaciones directas
• Menos ancho de banda desperdiciado en lanzamientos fallidos o rechazados
• Radio de explosión más pequeño al probar o estregar un lanzamiento

Actualizaciones ágiles son realmente sobre velocidad, seguridad y disciplina operativa.

1. Por defecto, utilizar actualizaciones Delta

Si haces solo una cosa, haz esto.

Capgo’s Actualizaciones Delta envían solo archivos que cambiaron entre versiones en lugar de descargar de nuevo el paquete web completo. Eso es el mayor beneficio único para el rendimiento de OTA rutinario.

bun run build
bunx @capgo/cli@latest bundle upload --channel staging --delta

Cuando tu paso de QA esté hecho:

bunx @capgo/cli@latest bundle upload --channel production --delta

If quieres que CI se mantenga estricto, utiliza --delta-only para que nadie accidentalmente regrese a las subidas de paquetes completos:

bunx @capgo/cli@latest bundle upload --channel production --delta-only

Sólo utiliza --delta-only cuando tu flota de producción admite actualizaciones Delta. En versiones de plugins mixtos, los dispositivos más antiguos que no admiten la entrega de deltas basada en manifestos no podrán descargar esa actualización.

Esto importa aún más si utilizas directUpdate, porque el tiempo entre “se encontró la actualización” y “se recargó la aplicación” se vuelve visible para el usuario.

2. Trata a los activos como activos, no como bagaje de JavaScript

Los activos grandes son donde los paquetes OTA se hinchan silenciosamente.

Algunas reglas prácticas:

• No incluyas imágenes grandes o medios dentro de JavaScript cuando un archivo de activo normal lo hará.
• Mantén el contenido que cambia con frecuencia en tu propio CDN o API si no necesita vivir dentro del paquete de la aplicación enviada.
• Cuida con las imágenes de marketing, los videos de onboarding y los activos de campaña que se reemplazan cada lanzamiento.
• Dejen que los activos estables permanezcan estables. Con actualizaciones de Delta, los archivos sin cambios se reutilizan en lugar de descargarse de nuevo.

Esta es una de las formas más fáciles de mantener Capgo rápido a medida que su aplicación crece. El peor patrón es una pequeña corrección de UI que obliga a los usuarios a descargar una pila de medios no relacionados.

3. Mantenga las versiones nativas para cambios reales nativos

Capgo actualiza la capa web: HTML, CSS, JavaScript y activos cargados en tiempo de ejecución.

No es el canal adecuado para:

• nuevos plugins nativos
• cambios de permisos
• capacitor.config.ts cambios
• cualquier cosa que modifique el estado del proyecto nativo de iOS o Android.

Esta línea importa para el rendimiento también. Si sigue metiendo cambios estructurales importantes en la vía de actualización OTA, su estrategia de actualización se vuelve más pesada y más riesgosa con el tiempo.

Utilice dos vías de lanzamiento con propósito:

Vía nativa

For cambios de plugins, cambios de permisos y configuración nativa:

bun run build
bunx cap sync

Luego envíe una versión de tienda normal.

Capgo vía

Para iteraciones de capa web seguras:

bun run build
bunx @capgo/cli@latest bundle upload --channel production --delta

También refresque su línea base nativa con regularidad si agregó recientemente muchos activos de larga duración. Una construcción de tienda fresca incorpora esa nueva línea base, lo que mantiene las diferencias futuras de Capgo más pequeñas.

4. Utilice canales para mantener el tamaño de la actualización pequeño

Una actualización 'delgada' no solo se trata de megabytes. También se trata de cuántos dispositivos reciben la actualización antes de saber que es buena.

Capgo's El sistema de canales es la forma más limpia de controlar eso:

• staging para QA
• beta para probadores invitados
• production para todos
• hotfix para la recuperación de emergencia

Un flujo simple se parece a esto:

1. Subir a staging.
2. Validar en dispositivos reales.
3. Desplegar gradualmente, ya sea a través de canales controlados o de un despliegue porcentual.
4. Revertir inmediatamente si la salud disminuye.

Si tu aplicación tiene varias bases nativas en el mundo, pair los canales con diseño de versiones. Eso mantiene los paquetes incompatibles o innecesariamente pesados alejados de los binarios más antiguos.

Para los equipos que quieren incluso más estrictos ciclos de revisión, Capgo también funciona bien para vistas de PR. Eso permite a product, QA y partes interesadas probar cambios de JS sin tener que esperar a nuevos builds internos de TestFlight o Play.

5. Si habilitas actualizaciones directas, optimiza el inicio duro

Cuanto más rápido quieras que se aplique una actualización, más disciplinado debe ser tu camino de inicio.

Capgo’s comportamiento de actualización los docs recomiendan explícitamente la combinación directUpdate con actualizaciones Delta. Eso es la configuración por defecto correcta.

La segunda barrera es notifyAppReady().

import { CapacitorUpdater } from '@capgo/capacitor-updater'

CapacitorUpdater.notifyAppReady()

Si tu aplicación no informa que está lista dentro de la ventana de 10 segundos por defecto, o dentro de lo que notifyAppReady() tú hayas configurado en tu __CAPGO_KEEP_0__ config, __CAPGO_KEEP_1__ puede marcar esa versión como inválida y restaurar la versión anterior buena. Ese comportamiento de rollback es lo que deseas en producción, pero también significa que debes mantener el inicio limpio: appReadyTimeout you set in your Capacitor config, Capgo can mark that bundle invalid and restore the previous good version. That rollback behavior is what you want in production, but it also means you should keep startup clean:

• Call notifyAppReady() In el lugar correcto
• Evite realizar trabajo de arranque lento en el camino crítico
• Guarde y restaure el estado de la aplicación con cuidado si se recarga inmediatamente
• Pruebe escenarios de red mala y dispositivos de bajo rendimiento antes de un lanzamiento amplio

Si no lo ha revisado recientemente, el notifyAppReady guide es recomendable re-leer.

6. Utilice canales de actualización internos en lugar de reconstrucciones nativas innecesarias

Muchos equipos de móviles desperdician tiempo construyendo binarios para cambios que claramente son solo web.

Si el cambio es:

• copiar
• polish de interfaz de usuario
• Onboarding flow,
• Logic de pantalla de precios,
• Conexión de análiticas,
• Banderas de características,
• Renderizado de respuesta o API de solicitud,

Entonces, una actualización de Capgo es a menudo el artefacto de revisión más rápido.

Por lo tanto, menos reconstrucciones nativas, menos cambios en TestFlight y un ciclo de retroalimentación más estrecho para el equipo. Es uno de los beneficios menos utilizados de Capgo: puede mover más trabajo de revisión y QA a la vía de actualizaciones OTA sin romper la frontera nativa/web.

Nuestra guía sobre estadío con un ID de aplicación móvil aborda una forma práctica de mantener esto limpio con el tiempo.

7. Mantén separado lo esbelto de lo secreto

Paquetes pequeños y paquetes seguros resuelven problemas diferentes.

Los canales controlan la elegibilidad. No hacen que un paquete sea confidencial por sí mismos.

Si necesita garantías de entrega más fuertes:

• habilitar Cifrado de actualización en vivo,
• usar almacenamiento personalizado o entrega autoalojada,
• mantener las llaves privadas solo en CI o flujos de trabajo de operador seguros.

Eso no hace que el tamaño de la actualización sea irrelevante. Solo significa que debe optimizar para ambas dimensiones:

• apuntar a la velocidad,
• cifrado para el control de entrega,
• canales para el control de lanzamiento,
• rollback para la recuperación.

Un flujo de trabajo práctico “lean Capgo”

Si desea un modelo de operación por defecto simple, utilice esto:

1. Mantenga separadas las rutas de lanzamiento nativo y OTA.
2. Subir cambios de JS con --delta por defecto.
3. Utilice staging y beta canales antes de production.
4. Mire actualice estadísticas y registros después del lanzamiento, no solo antes de él.
5. Convierta PRs en previsualizaciones instalables cuando un compilado nativo no sea necesario.
6. Mantenga grandes y cambiantes medios fuera de la paquete donde sea posible.
7. Refresque la base nativa después de un crecimiento significativo de activos o cambios nativos.
8. Tome notifyAppReady() y el comportamiento de rollback como parte de la ingeniería de lanzamiento, no como trivia de configuración.

Esta combinación permanece rápida durante mucho tiempo más que el enfoque común “suba lo que cambió”.

Pensamiento final

Para los equipos Capgo, “delgado y rápido” no es solo un problema de tamaño de paquete.

Es un problema de diseño de lanzamiento.

Use actualizaciones Delta para el tamaño de carga, canales para el tamaño de lanzamiento y rollback para el tamaño de falla. Una vez que piense en OTA de esa manera, sus actualizaciones permanecen rápidas incluso a medida que la aplicación, el equipo y la base de usuarios crecen.

Siga adelante desde Cómo mantener Capgo actualizaciones delgadas y rápidas

Si está utilizando Cómo mantener Capgo actualizaciones delgadas y rápidas para planificar la ruta de canal y la implementación escalonada, conecte con Canales para los detalles de implementación en Canales, Canales para los detalles de implementación en Canales, Canales para los detalles de implementación en Canales, Solución de Pruebas Beta para el flujo de trabajo del producto en Solución de Pruebas Beta, y Solución de Enfoque de Versión para el flujo de trabajo del producto en Solución de Enfoque de Versión.