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

El mejor live update es el que sus usuarios apenas notan.

Normalmente significa tres cosas:

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

El mismo consejo de mantener actualizaciones OTA ligueras que funciona en 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áticos, versión de destino, y opcional criptografía de extremo a extremo.

Si los utilizas juntos, obtienes paquetes más pequeños, instalaciones más rápidas y mucho menos desorden operativo.

Lean matters even when MAU stays the same

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

Por lo tanto, reducir un paquete no es principalmente una trampa para reducir el conteo de MAU. Importa porque mejora las partes que los usuarios y los equipos realmente sienten:

• Descargas más rápidas en redes móviles o Wi-Fi débiles
• Mejor experiencia con actualizaciones directas
• Menos ancho de banda desperdiciado en lanzamientos fallidos o revertidos
• Radio de explosión más pequeño al probar o estrenar una versión

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

1. Por defecto, utilice actualizaciones Delta.

Si haces solo una cosa, haz esto.

Capgo’s Actualizaciones Delta envía solo los archivos que cambiaron entre versiones en lugar de descargar de nuevo el paquete web completo. Eso es el mayor beneficio individual para el rendimiento de actualizaciones OTA rutinarias.

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

Cuando tu paso de QA esté completo:

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

Cuando se complete tu paso de QA: --delta-only Si deseas que CI se mantenga estricto, utilice

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

Solo utilice --delta-only when your production fleet supports Delta updates. On mixed plugin versions, older devices that do not support manifest-based delta delivery will not be able to download that update.

Este es especialmente importante si utilizas directUpdateporque el tiempo entre “actualización encontrada” y “aplicación recargada” se vuelve visible para el usuario.

2. Trata los activos como activos, no como carga de JavaScript

Large assets are where OTA bundles quietly get bloated.

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.
• Ten cuidado con las imágenes de marketing, los videos de onboarding y los activos de campaña que se reemplazan cada lanzamiento.
• Deja que los activos estables sigan estables. Con las actualizaciones Delta, los archivos inalterados se reutilizan en lugar de descargarse de nuevo.

Esto es una de las formas más fáciles de mantener Capgo rápido a medida que tu 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. Mantén los lanzamientos nativos 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 de proyecto nativo de iOS o Android.

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

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

Vía nativa

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

bun run build
bunx cap sync

Luego envíe un lanzamiento de tienda normal.

Capgo vía

Para iteraciones de capa web seguras:

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

Refresque también su línea base nativa con regularidad si recientemente agregó muchos activos de larga vida. Un nuevo paquete de tienda incorpora esa nueva línea base, lo que mantiene las diferencias de Capgo futuras más pequeñas.

4. Use channels to keep rollout size small

Una actualización 'ligera' 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 pruebas
• beta para probadores invitados
• production para todos
• hotfix para recuperación de emergencia

Un flujo simple se parece a esto:

1. Cargar a staging.
2. Validar en dispositivos reales.
3. Despliegue gradual, ya sea a través de canales controlados o por porcentaje de despliegue.
4. Revertir inmediatamente si la salud disminuye.

Si su aplicación tiene varias bases nativas en el mundo, pair los canales con la versión objetivo. Esto mantiene los paquetes incompatibles o innecesariamente pesados lejos de los binarios más antiguos.

Para los equipos que desean incluso más estrictos ciclos de revisión, Capgo también funciona bien para pruebas de revisión. Esto permite a los productores, QA y partes interesadas probar cambios de JavaScript sin tener que esperar a nuevos TestFlight o Play internos.

5. Si habilita actualizaciones directas, optimice el inicio duro

Cuanto más rápido desee una actualización aplicarse, más disciplinado debe ser su camino de inicio.

Capgo's comportamiento de actualización docs recomiendan explícitamente la combinación directUpdate with Delta updates. That is the right default.

La segunda barrera de seguridad es notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

Si su aplicación no informa estar lista dentro de los 10 segundos de espera por defecto notifyAppReady() ventana, o dentro de lo que 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() en el lugar correcto
• Evitar trabajo lento en el camino crítico
• Guarda y restaura el estado de la aplicación con cuidado si se recarga inmediatamente.
• Probar escenarios de red mala y dispositivos de bajo rendimiento antes de un lanzamiento amplio

Si no lo has revisado recientemente, el notificarGuíaDePreparación Es recomendable releerlo.

6. Utilice canales de actualizaciones internos en lugar de reconstrucciones nativas innecesarias

Muchas veces, los equipos de móviles desperdician tiempo construyendo binarios para cambios que claramente son solo web.

Si el cambio es:

• copiar
• Polish de UI
• flujo de onboarding
• lógica de pantalla de precios
• conexión de análisis
• banderas de características
• renderizado de respuesta o API

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

Eso significa 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 actualización OTA sin romper la frontera nativa/web.

Nuestra guía sobre el estacionamiento 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 delgado de lo secreto

Los pequeños paquetes y los 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:

• habilita la cifrado de Live Update,
• usa almacenamiento personalizado o entrega autoalojada,
• mantenga 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 deberías optimizar para ambas dimensiones:

• delgado para velocidad
• encriptado para control de entrega
• canales para control de lanzamiento
• desactivar para recuperación.

Un flujo de trabajo práctico ‘delgado Capgo’

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

1. Mantenga las rutas de lanzamiento nativo y OTA separadas.
2. Cargar cambios de JS con --delta por defecto.
3. Usar staging y beta canales antes production.
4. Ver estadísticas y registros de actualización después de la implementación, no solo antes.
5. Convertir PRs en vistas previas instalables cuando una compilación nativa no es necesaria.
6. Mantener grandes y cambiantes medios fuera de la paquete donde sea posible.
7. Refrescar la base nativa después de un crecimiento significativo de activos o cambios nativos.
8. Tratar notifyAppReady() y el comportamiento de rollback como parte de la ingeniería de lanzamiento, no trivia de configuración.

Esta combinación se mantiene rápida mucho más tiempo que el enfoque común de ‘subir solo lo que cambió’.

Reflexión final

Para equipos de Capgo, "agil y rápido" no es solo un problema de tamaño del paquete.

Es un problema de diseño de lanzamiento.

Utilice actualizaciones Delta para el tamaño del payload, canales para el tamaño de la implementación y reversiones para el tamaño de la 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 agiles y rápidas

Si está utilizando Cómo mantener Capgo actualizaciones agiles y rápidas para planificar la ruta de los canales y la implementación en etapas, conecte con Canal para los detalles de implementación en los Canales, Canal para los detalles de implementación en los 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 Alcance de Versión para el flujo de trabajo del producto en Solución de Alcance de Versión.