Cómo configurar los intentos de auto-pausa de Capgo

Un umbral de intentos bajo puede pausar un despliegue OTA saludable. Uno alto puede dejar que un bundle defectuoso llegue a demasiados dispositivos. El Capgo intentos mínimos de pausa automática controla cuándo Capgo tiene suficientes datos de instalación y fallos para pausar un canal. Usa los pasos siguientes para configurarlo con cuidado, probarlo y conectarlo a tu flujo de release.

Tabla de contenidos

• Paso 1: Entiende qué controla el mínimo de intentos
• Paso 2: Encuentra el ajuste de Auto-Pause en Capgo
• Paso 3: Elige un valor seguro para el mínimo de intentos
• Paso 4: Prueba la pausa automática con un rollout por canal
• Paso 5: Monitoriza intentos, analytics y rollback automático
• Paso 6: Automatiza el ajuste en CI/CD
• FAQ
• Conclusión

Paso 1: Entiende qué controla el mínimo de intentos

El intentos mínimos de pausa automática el valor establece la muestra mínima de Capgo necesaria antes de que sus reglas de pausa puedan actuar. Es un umbral, no un límite de fallos. El ajuste le indica a Capgo que espere hasta que haya suficientes intentos de update antes de evaluar el rollout.

Un intento puede incluir un dispositivo que intenta instalar un bundle. El intento puede tener éxito o fallar. El resultado exacto depende de la ruta de update, el estado de la app y la configuración del updater. Por eso, el valor debe interpretarse teniendo en cuenta el tamaño de tu rollout.

La referencia de canal de Capgo describeauto-pause-min-attemptscomo el número mínimo de intentos de instalación más fallos antes de que la pausa automática pueda surtir efecto. El campo se representa como una cadena en la referencia de CLI, por lo que mantén el valor en el formato esperado por el comando o API que utilices. Puedes revisar el campos del canal Capgo CLI antes de modificar un canal en vivo.

Piensa en esta configuración como una regla de evidencia mínima. Un valor de 1 puede reaccionar tras el primer intento registrado. Eso puede ayudar durante una prueba interna muy pequeña, pero también puede reaccionar a una sola sesión de red deficiente. Un valor mayor le da al despliegue más tiempo para recopilar una muestra útil.

Separar los intentos de los usuarios

Los intentos no son lo mismo que personas únicas. Un dispositivo puede reintentar una actualización. Un solo usuario puede ejecutar la app en más de un dispositivo. Tu vista de analítica también puede agrupar eventos de una manera que difiere de tus propias métricas de producto.

Antes de elegir un número, anota qué quieres que el umbral proteja. Si el objetivo es detectar un bundle de JavaScript roto a tiempo, un canal controlado pequeño puede usar un valor más bajo. Si el objetivo es proteger un lanzamiento de producción amplio, necesitas suficientes intentos para evitar decisiones basadas en un solo dispositivo o una interrupción breve.

• Usa un umbral pequeño para un canal de prueba privado.
• Usa un umbral más grande cuando el canal tenga redes y tipos de dispositivos mixtos.
• Aumenta el umbral si las interrupciones breves han causado pausas falsas.
• Bájalo solo cuando el costo de una detección tardía sea mayor que el costo de una pausa falsa.

El auto-pause debe detener un rollout. No reemplaza la revisión del bundle, el testing en dispositivos o un plan de rollback claro. Trata el umbral como un control más en tu proceso de release.

Conclusión clave: Minimum attempts controla cuánta evidencia de rollout necesita Capgo antes de que su política de auto-pause entre en acción.

Paso 2: Encuentra el ajuste de Auto-Pause en Capgo

Para configurar el Capgo valor de auto pause minimum attempts, primero busca el channel que entrega el bundle. El auto-pause es parte del control de rollout, así que cambiar la config del updater global podría no afectar la política del channel como esperas.

Empieza en el dashboard de Capgo o usa el comando de channel y la ruta de API que ya usa tu equipo. Verifica el nombre del channel antes de editar nada. Un channel de test y uno de producción pueden tener nombres similares, y un valor correcto en el channel equivocado sigue siendo un incidente de release a punto de ocurrir.

Busca los campos de auto-pause en la configuración del channel. Los campos relacionados pueden incluir el valor de minimum attempts y un ajuste de confidence. Revisa esos campos juntos en tu revisión de cambios. El mínimo de muestras define cuándo Capgo puede juzgar el rollout. El valor de confidence afecta qué tan fuerte debe ser la señal antes de que se produzca una pausa.

Configura el valor mediante una ruta auditable

Usa el dashboard cuando necesites un cambio rápido y controlado y tu equipo registre los cambios en el dashboard. Usa el CLI cuando la configuración pertenezca a un script de release. Usa la API pública cuando un servicio gestione la política del canal como parte de un sistema de despliegue más amplio.

Sea cual sea la ruta que elijas, captura primero el valor anterior. Guarda el nombre del canal, la versión del bundle, el estado del rollout y el nuevo valor en el mismo registro de cambios. Eso te dará una respuesta clara si el canal se pausa más tarde.

Para flujos de trabajo impulsados por API, Capgo expone los recursos de canal a través de su API pública. El documentación del canal Capgo API es el lugar adecuado para verificar los nombres de los campos y la estructura de la solicitud, en lugar de adivinar desde un script local.

Al editar el valor, introduce un número entero, como espera el campo. No añadas un signo de porcentaje ni uses decimales. Si tu herramienta guarda la configuración como JSON, mantén exacta la ortografía de la clave y conserva el formato de cadena que se muestra en la referencia actual de Capgo.

Confirma el cambio

Vuelve a leer el canal después de guardarlo. No asumas que un comando exitoso significa que el campo previsto cambió. Verifica los datos devueltos del canal o el valor en el dashboard.

Luego, hazte tres preguntas:

• ¿El ajuste cambió en el canal previsto?
• ¿El canal sigue apuntando al bundle previsto?
• ¿El rollout está activo, en pausa o completado?

Si el valor no aparece, detente ahí. Revisa los permisos, la ortografía del campo y el identificador del canal. Un script de despliegue que reporta éxito sin verificar el estado guardado no es fiable.

Paso 3: Elige un valor seguro para el mínimo de intentos

Elige el valor de intentos mínimos de la pausa automática de Capgo según el tamaño y el riesgo del rollout. No hay un número seguro para todas las apps. El umbral adecuado le da a la política suficiente evidencia sin dejar de detectar a tiempo una actualización defectuosa.

Empieza con el grupo más pequeño que pueda darte información útil. Un canal privado puede contener dispositivos internos con versiones de app conocidas. Un canal de producción puede incluir dispositivos antiguos, conexiones débiles y usuarios que abren la app solo una vez cada pocos días. Esos grupos no deberían compartir el mismo umbral por defecto.

Usa una regla de decisión simple

Pregúntate cuántos intentos necesitas antes de que un patrón de fallos signifique algo. Si tu canal de pruebas tiene pocos dispositivos, puede que un umbral alto nunca se alcance durante la ventana de prueba. Si tu canal de producción recibe muchos intentos en minutos, un umbral muy bajo puede pausar el release tras un problema de red breve.

Configura un valor más bajo cuando:

• El canal es privado.
• El bundle modifica una función de alto riesgo.
• Necesitas feedback rápido durante una prueba escalonada.
• Tu equipo puede revisar cada fallo poco después del release.

Configura un valor más alto cuando:

• El canal cubre una amplia variedad de dispositivos.
• Los usuarios se conectan desde redes inestables.
• La app se abre con poca frecuencia al día.
• Una interrupción breve podría generar muchas falsas fallas.

No uses el umbral para ocultar un problema conocido. Si un bundle falla en un plugin nativo obligatorio, pausa la release tú mismo y corrige la causa. Una configuración de intentos mínimos no puede hacer seguro un bundle incompatible.

Combina el umbral con el tamaño del rollout

Supongamos que primero lanzas a un canal interno pequeño. Podrías elegir un umbral que permita al equipo ver varios resultados de instalación antes de que la pausa automática pueda actuar. Una vez que el bundle supera esa etapa, pásalo a un canal más amplio con un umbral que refleje una muestra más grande.

Este enfoque mantiene la primera señal rápida sin exigir que la política de producción reaccione a una muestra diminuta. También te da un lugar claro para ajustar la configuración. Cambia el umbral junto con el canal, no después de que el rollout ya haya fallado.

Registra el valor junto al registro de la release. Anota por qué lo elegiste, qué haría que lo cambiaras y quién puede aprobar ese cambio. Esto importa cuando un miembro del equipo ve un canal en pausa durante un incidente y necesita contexto rápidamente.

Consejo pro: Empieza con un canal controlado, registra su volumen de intentos y ajusta el umbral de producción según el comportamiento observado del despliegue, no a ciegas.

Paso 4: Prueba la pausa automática con un rollout por canal

Prueba el auto-pause en un canal antes de depender de él en producción. Un canal te da un límite para el test. Puedes enviar un bundle a un grupo conocido, ver cómo suben los intentos y confirmar qué pasa cuando la política alcanza su umbral.

Primero, crea un bundle de prueba que puedas identificar sin confundirlo con un release en vivo. Mantén seguro el cambio code. El test debe demostrar los controles de release, no crear un segundo problema en la app.

Luego, asigna un grupo pequeño de dispositivos de prueba al canal. Verifica que cada dispositivo tenga la versión nativa esperada de la app. Las actualizaciones OTA de code no pueden arreglar todos los desajustes nativos, así que un dispositivo con el binario equivocado puede hacer que el test sea difícil de interpretar.

Publica el bundle en el canal. Usa un comando de tu flujo de despliegue normal de Capgo cuando sea posible, pero guarda los IDs del bundle y del canal en el log del release. No dependas del buffer de scroll del terminal durante un incidente.

Prueba el flujo de pausa

Necesitas una forma segura de generar un intento fallido. Usa un bundle solo para pruebas o una condición de fallo controlada y aprobada por tu equipo. Nunca dañes un bundle de producción solo para ver si el auto-pause funciona.

Observa la siguiente secuencia:

1. El canal apunta al bundle de prueba.
2. Los dispositivos reciben la instrucción de actualización.
3. Los intentos aparecen en la vista de analytics.
4. Se alcanza el número mínimo de intentos.
5. La señal de error pausa el canal si se cumplen las condiciones de la política.

El quinto paso es importante. Alcanzar el valor de intentos mínimos puede hacer que la pausa automática sea elegible. No significa que cada despliegue se pause en esa cantidad exacta. Otros campos de la política y los resultados observados pueden afectar el resultado.

Prueba también la recuperación

Tras la pausa, confirma lo que reciben los usuarios. Verifica si el bundle fallido sigue seleccionado, si los nuevos dispositivos dejan de recibirlo y si el bundle seguro anterior está disponible para rollback. La respuesta depende de tu configuración de updater y canal, así que compruébalo con los logs de la app en lugar de asumir.

Luego, reanuda con un bundle conocido como bueno solo después de que alguien revise el fallo. Si el fallo provino de un build defectuoso, crea un nuevo bundle. No intentes simplemente subir el mismo artefacto de nuevo y esperar que el próximo intento se comporte diferente.

Documenta el resultado de la prueba. Incluye el umbral, el número de dispositivos, la condición de fallo, el tiempo de pausa y la acción de recuperación. Esto convierte una prueba puntual en una verificación de release repetible.

Paso 5: Monitoriza intentos, analytics y rollback automático

El monitoreo te indica si la regla de intentos mínimos para la pausa automática de Capgo está viendo un rollout saludable o uno roto. Observa el conteo de intentos junto al comportamiento de fallo. Un conteo sin contexto puede llevarte a pausar demasiado pronto o a pasar por alto un problema creciente.

Usa Capgo Observe para inspeccionar la actividad de actualizaciones y el estado del rollout. El documentación de Capgo Observe describe el área para ver la información de las actualizaciones y configurar el auto-pause. Mantén el dashboard abierto durante la primera fase de un release, especialmente si el bundle cambia el code de inicio o un flujo principal de la app.

Analiza las señales en conjunto

Primero mira el total de intentos. Luego revisa el conteo de fallos y el patrón temporal. Un flujo constante de instalaciones exitosas es distinto a una ráfaga de fallos tras activar un bundle.

Revisa los detalles del dispositivo y de la versión de la app cuando estén disponibles. Si los fallos se concentran en una versión nativa, el bundle OTA podría requerir un binario más reciente. Si los fallos aparecen en todas las versiones, inspecciona el bundle o la ruta del servicio de actualización.

Los fallos de red pueden generar ruido. Una caída breve puede causar intentos fallidos sin un defecto en code. Por eso, el umbral debe funcionar junto con una política de confianza y un proceso de revisión humana. El auto-pause puede frenar la exposición, pero no puede explicar cada fallo.

Entiende qué significa un rollback en tu flujo

Un rollback devuelve a los usuarios afectados a un release estable o evita que el release defectuoso llegue a más dispositivos. No repara un binario nativo que carece de una capacidad necesaria, ni puede deshacer una migración de datos ejecutada por un bundle OTA.

Antes de pasar a producción, confirma la ruta de rollback con un test channel. Verifica qué bundle se considera seguro. Comprueba qué ocurre si un dispositivo está offline durante la pausa. Luego, escribe los pasos de recuperación donde el ingeniero de guardia pueda encontrarlos.

de Capgo documentación de rollback puede ayudarte a asignar los controles de rollback disponibles a tu plan de canales. Usa el comportamiento documentado como referencia, ya que el resultado puede depender de la versión del updater y de la configuración del release.

Durante un incidente, pausa primero si el patrón de fallo está claro. Luego revisa los logs y los cambios en el bundle. Unos minutos dedicados a detener la exposición suelen ser más fáciles de gestionar que dejar que un release defectuoso siga propagándose.

Paso 6: Automatiza el ajuste en CI/CD

Incluye el valor de minimum attempts de auto pause de Capgo en tu workflow de release cuando el ajuste cambie según el canal. La automatización elimina el drift manual. También hace que el umbral elegido sea visible en la revisión de code.

Mantén la política de canales separada de los secrets. El nombre del canal, la etapa de rollout y el valor de minimum attempts pueden estar en una configuración versionada. Los tokens de API deben permanecer en tu secret store de CI/CD. Nunca hagas commit de un token en un repositorio solo porque el ajuste del canal ya esté ahí.

Un job de release debe seguir un orden claro:

1. Haz el build del web bundle.
2. Ejecuta los tests y comprueba la compatibilidad nativa.
3. Sube el bundle.
4. Establece o confirma el canal de destino.
5. Aplica el valor de intentos mínimos.
6. Verifica el estado del canal guardado.
7. Publica o avanza el rollout.

Usa un dry-run o una etapa de revisión si tu sistema de despliegue lo permite. La revisión debe mostrar el identificador del bundle, el canal, el umbral y la acción de rollout antes de que se ejecute el paso de producción.

Haz que la verificación sea parte del job

Cuando termine el comando API o CLI, vuelve a obtener el estado del canal. Falla el job si el valor devuelto no coincide con la configuración esperada. Así detectas IDs de canal incorrectos, campos rechazados y actualizaciones parciales.

Las variables de entorno son una forma habitual de pasar la configuración de la release a un job de CI. El job puede leer un nombre de canal o un umbral sin poner secretos en archivos de código fuente. Mantén los nombres de las variables claros y valídalos antes del despliegue.

Por ejemplo, tu workflow podría requerir:

• CAPGO_CHANNELpara el canal objetivo.
• CAPGO_MIN_ATTEMPTSpara el umbral aprobado.
• CAPGO_BUNDLE_IDpara el bundle subido.

Esos nombres son convenciones del workflow, no nombres de campos de Capgo. Mapea los campos exactos de CLI o API en un solo lugar. Eso facilita revisar cambios futuros.

Para una verificación de seguridad más profunda, revisa la guía de Capgo sobre cómo proteger las actualizaciones OTA en pipelines de CI/CD. El hábito importante es simple: limita el acceso al token, registra la decisión de release y verifica el resultado tras cada cambio.

Mantén un registro de cambios

Guarda el umbral junto con el commit o el ID de la release. Añade el motivo del cambio. Si un rollout se pausa inesperadamente, puedes comparar la política con el bundle y la hora del despliegue.

Capgo se factura como suscripción por organización, con 14 días de prueba gratis en vez de una compra única. Ese modelo encaja con equipos que quieren probar el flujo de release antes de integrarlo en su proceso de entrega habitual. Mantén la prueba enfocada: configura un canal, haz una prueba de pausa y verifica una ruta de rollback.

Un solo comando puede publicar la actualización. El flujo más seguro es el que también comprueba el canal, sigue la adopción y deja una ruta de rollback.

FAQ

¿Qué significa Capgo auto pause minimum attempts?

Capgo auto pause minimum attempts define el mínimo de intentos de instalación y de fallo necesarios para que la política de auto-pausa pueda actuar. Es un umbral de tamaño de muestra, no un porcentaje de instalaciones fallidas. Un valor bajo reacciona antes, pero puede basarse en menos evidencia. Un valor más alto da al canal más tiempo para recopilar resultados.

¿Dónde configuro auto pause minimum attempts en Capgo?

Configuras el valor en el canal que entrega el bundle OTA. Usa el dashboard de Capgo, CLI o la API pública, y luego vuelve a leer el canal para confirmar el campo guardado. Comprueba primero el nombre del canal. Editar un canal de prueba con producción activa no cambiará el despliegue de producción.

¿Cuál es un valor seguro para minimum attempts?

Un valor seguro depende del tamaño del canal, la variedad de dispositivos, la calidad de la red y el riesgo del release. Usa un umbral más bajo para un canal de prueba controlado. Usa un umbral más alto para un despliegue de producción amplio. Empieza con un grupo conocido, observa su volumen de intentos y ajusta según el comportamiento observado.

¿Alcanzar el valor mínimo de intentos siempre pausa una release?

No. Alcanzar el valor mínimo de intentos de Capgo hace que el rollout sea elegible para auto-pause, pero otras condiciones de la política siguen siendo relevantes. Las señales de fallo, la configuración de confianza, el estado del canal y el flujo del updater pueden afectar el resultado. Prueba la ruta completa de pausa con un bundle seguro antes de depender de ella en producción.

¿Puede el auto-pause reemplazar un plan de rollback?

No. El auto-pause detiene o limita la exposición adicional, mientras que el rollback dirige a los usuarios hacia un bundle conocido como estable cuando esa ruta está disponible. Prueba ambos controles. Recuerda también que un rollback OTA no puede añadir una capacidad nativa que la app instalada no tenga.

Conclusión

Configura el valor de intentos mínimos por canal, no por costumbre. Empieza con un despliegue de prueba pequeño, verifica las rutas de pausa y rollback, y luego automatiza la configuración aprobada en tu CI/CD. Si quieres probar el workflow, prueba Capgo con un canal y un bundle controlado antes de ampliar el despliegue.