Un umbral de intentos bajo puede pausar un rollout OTA saludable. Uno alto puede permitir que un bundle defectuoso llegue a demasiados dispositivos. El Capgo intentos mínimos de auto-pausa controla cuándo Capgo tiene suficientes datos de instalación y fallos para pausar un canal. Sigue estos pasos para configurarlo con cuidado, probarlo e integrarlo en tu flujo de release.
Table of Contents
- Paso 1: Entender qué controla el mínimo de intentos
- Paso 2: Localizar el ajuste de Auto-Pause en Capgo
- Paso 3: Elige un valor seguro de intentos mínimos
- Paso 4: Prueba el Auto-Pause con un rollout por canal
- Paso 5: Monitoriza intentos, analytics y rollback automático
- Paso 6: Automatiza el ajuste en tu CI/CD
- FAQ
- Conclusión
Paso 1: Entiende qué controla el mínimo de intentos
El intentos mínimos de auto-pausa este valor define la muestra mínima que Capgo requiere antes de aplicar las reglas de pausa. Es un filtro, no un límite de fallos. El ajuste indica a Capgo que espere hasta que haya suficientes intentos de update antes de evaluar el rollout.
Un intento puede ser un dispositivo intentando instalar un bundle. El intento puede ser exitoso o fallido. El resultado exacto depende de la ruta de update, el estado de la app y la configuración del updater. Por eso, debes elegir el valor pensando en 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 fallidos antes de que el auto-pause surta efecto. El campo se representa como un string en la referencia de CLI, así que mantén el valor en el formato que espera el comando o API que utilices. Puedes revisar los campos de CLI del canal Capgo antes de cambiar un canal live.
Piensa en este ajuste como una regla de evidencia mínima. Un valor de 1 podría reaccionar tras el primer intento registrado. Esto sirve para pruebas internas muy pequeñas, pero también puede reaccionar ante una mala sesión de red. Un valor mayor da al rollout más tiempo para recolectar una muestra útil.
Diferencia 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 analytics también podría agrupar eventos de forma distinta a tus propias métricas de producto.
Antes de elegir un número, define qué quieres proteger con el threshold. Si el objetivo es detectar un bundle de JavaScript roto pronto, un canal controlado pequeño puede usar un valor bajo. Si buscas proteger un release de producción masivo, necesitas suficientes intentos para no decidir basándote en un solo dispositivo o un breve outage.
- Usa un threshold bajo para un canal de pruebas privado.
- Usa un threshold mayor cuando el canal tenga redes y tipos de dispositivos mixtos.
- Sube el threshold si los outages cortos han causado pausas falsas.
- Bájalo solo cuando el coste de una detección tardía sea mayor que el de una pausa falsa.
El auto-pause debe detener un rollout. No debe sustituir la revisión del bundle, las pruebas en dispositivos o un plan de rollback claro. Trata el umbral como un control dentro de 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 pueda actuar.
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 forma parte del control de rollout, por lo que cambiar la config global del updater podría no cambiar la política del channel que esperas.
Empieza en el dashboard de Capgo o usa el comando de channel y la ruta de API que tu equipo ya utiliza. 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 en potencia.
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 confianza. Mantén esos campos juntos en la revisión de cambios. Un mínimo de muestras indica cuándo Capgo puede juzgar el rollout. Un valor de confianza puede afectar a lo fuerte que debe ser la señal antes de que se active un auto-pause.
Configura el valor mediante una ruta que puedas auditar
Usa el dashboard cuando necesites un cambio rápido y controlado y tu equipo registre cambios allí. Usa CLI cuando el ajuste deba ir en 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.
Elijas el camino 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 cambio. Así tendrás una respuesta clara si el canal se pausa más tarde.
Para flujos de trabajo basados en API, Capgo expone los recursos del canal mediante su API público. La documentación de API del canal Capgo es el lugar ideal para verificar los nombres de los campos y la estructura de la petición en vez de adivinar con un script local.
Al editar el valor, introduce un número entero como espera el campo. No añadas un signo de porcentaje. No uses decimales. Si tu herramienta guarda la configuración como JSON, mantén la ortografía exacta de la clave y preserva el formato de string que muestra la referencia actual de Capgo.
Confirmar el cambio
Vuelve a leer el canal tras guardarlo. No asumas que un comando exitoso significa que el campo cambió. Verifica los datos del canal devueltos o el valor en el dashboard.
Luego, hazte tres preguntas:
- ¿Cambió el ajuste en el canal previsto?
- ¿El canal sigue apuntando al bundle correcto?
- ¿El rollout está activo, pausado o completado?
Si el valor no aparece, detente ahí. Revisa los permisos, la ortografía del campo y el identificador del canal. Es difícil confiar en un script de deployment que reporta éxito sin verificar el estado guardado.
Paso 3: Elige un valor seguro de intentos mínimos
Elige el valor de Capgo auto pause minimum attempts según el tamaño y riesgo del rollout. No existe un número seguro para todas las apps. El umbral correcto da evidencia suficiente a la política y detecta una mala actualización pronto.
Empieza con el grupo más pequeño que pueda darte información útil. Un canal privado puede tener dispositivos internos con versiones de la app conocidas. Un canal de producción puede incluir dispositivos antiguos, conexiones débiles y usuarios que abren la app solo 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 sea significativo. Si tu canal de test tiene pocos dispositivos, puede que nunca alcances un umbral alto durante la ventana de prueba. Si tu canal de producción recibe muchos intentos en minutos, un umbral muy bajo podría pausar el release tras un problema de red momentáneo.
Configura un valor más bajo cuando:
- El canal sea privado.
- El bundle cambie una funcionalidad de alto riesgo.
- Necesites feedback rápido durante un test escalonado.
- Tu equipo pueda inspeccionar cada fallo poco después del release.
Configura un valor más alto cuando:
- El canal sirve a una gran variedad de dispositivos.
- Los usuarios se conectan mediante redes inestables.
- La app tiene una baja frecuencia de apertura diaria.
- Una caída breve podría generar muchos fallos falsos.
No uses el umbral para ocultar un problema conocido. Si un bundle falla por un plugin nativo requerido, pausa el release tú mismo y corrige la causa. Un ajuste de intentos mínimos no hará seguro un bundle incompatible.
Combina el umbral con el tamaño del rollout
Supongamos que lanzas primero a un canal interno pequeño. Podrías elegir un umbral que permita al equipo ver varios resultados de instalación antes de que el auto-pause actúe. Una vez que el bundle supere esa etapa, pásalo a un canal más amplio con un umbral que refleje una muestra mayor.
Este enfoque mantiene la primera señal rápida sin exigir que la política de producción reaccione a una muestra mínima. También te da un lugar claro para ajustar el setting. Cambia el umbral según el canal, no después de que el rollout haya fallado.
Registra el valor junto al historial del release. Anota por qué lo elegiste, qué te haría cambiarlo y quién puede aprobar ese cambio. Esto es vital cuando un miembro del equipo ve un canal pausado durante un incidente y necesita contexto rápido.
Consejo pro: Empieza con un canal controlado, registra el volumen de intentos y ajusta el umbral de producción basándote en el comportamiento real del rollout en lugar de con conjeturas.
Paso 4: Prueba el Auto-Pause con un Rollout basado en canales
Prueba el auto-pause en un canal antes de confiar en é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 validar los controles del 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 de la app nativa esperada. El code OTA no puede arreglar cada desajuste nativo, así que un dispositivo con el binario incorrecto puede dificultar la lectura del test.
Publica el bundle en el canal. Usa un comando de tu flujo normal de deployment de Capgo cuando sea posible, pero guarda los IDs del bundle y del canal en el log del release. No dependas del scrollback de la terminal durante un incidente.
Prueba el flujo de pausa
Necesitas una forma segura de generar un intento fallido. Usa un bundle exclusivo para tests 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:
- El canal apunta al bundle de prueba.
- Los dispositivos reciben la instrucción de update.
- Los intentos aparecen en la vista de analytics.
- Se alcanza el conteo mínimo de intentos.
- La señal de fallo pausa el canal, si se cumplen las condiciones de la política.
El quinto paso es clave. Alcanzar el valor de intentos mínimos puede activar el auto-pause. No significa que cada rollout se detenga exactamente en ese número; otros campos de la política y los resultados observados pueden afectar el resultado.
Prueba también la recuperación
Tras la pausa, confirma qué 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 channel, así que verifícalo con los logs de la app en lugar de asumir.
Luego, reanuda con un bundle conocido como estable solo después de que alguien revise el fallo. Si el error fue por un build defectuoso, crea un nuevo bundle. No vuelvas a subir el mismo artefacto esperando que el siguiente intento funcione distinto.
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 única en un check de release repetible.
Paso 5: Monitorea intentos, analytics y rollback automático
El monitoreo te indica si la regla de Capgo auto pause minimum attempts está ante un rollout saludable o uno roto. Observa el conteo de intentos junto al comportamiento de los fallos. Un conteo sin contexto puede hacer que pauses demasiado pronto o ignores un problema creciente.
Usa Capgo Observe para inspeccionar la actividad de updates 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 de dispositivo y versión de la app si 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 fallan 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 trabajar con una política de confianza y revisión humana. El auto-pause puede frenar la exposición, pero no explica 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 usarlo en 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 la documentación de rollback puede ayudarte a mapear los controles de rollback disponibles con tu plan de canales. Usa el comportamiento documentado como referencia, ya que el resultado puede depender de la versión del updater y la configuración del release.
Durante un incidente, pausa primero si el patrón de fallo es claro. Luego inspecciona los logs y los cambios en el bundle. Dedicar unos minutos a detener la exposición suele ser más fácil de gestionar que dejar que un release defectuoso siga propagándose.
Paso 6: Automatiza el ajuste en CI/CD
Incluye el valor de auto pause minimum attempts de Capgo en tu workflow de release cuando el ajuste varíe según el canal. La automatización evita 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:
- Build del web bundle.
- Ejecuta tests y comprueba la compatibilidad nativa.
- Upload del bundle.
- Establece o confirma el canal de destino.
- Aplica el valor de intentos mínimos.
- Verifica el estado del canal guardado.
- Publica o avanza el rollout.
Usa un dry-run o etapa de revisión si tu sistema de deployment lo permite. La revisión debe mostrar el bundle identifier, el canal, el threshold y la acción de rollout antes de ejecutar el paso de producción.
Haz que la verificación sea parte del job
Tras completar el comando API o CLI, vuelve a consultar el estado del canal. Si el valor devuelto no coincide con la configuración esperada, falla el job. Esto detecta IDs de canal erróneos, campos rechazados y actualizaciones parciales.
Las variables de entorno son una forma común de pasar ajustes de release a un job de CI. El job puede leer un nombre de canal o un threshold sin exponer secrets en los archivos fuente. Mantén los nombres de las variables claros y valídalos antes del deployment.
Por ejemplo, tu workflow podría requerir:
CAPGO_CHANNELpara el canal de destino.CAPGO_MIN_ATTEMPTSpara el threshold aprobado.CAPGO_BUNDLE_IDpara el bundle subido.
Esos nombres son convenciones de workflow, no nombres de campos de Capgo. Mapéalos a los campos exactos de CLI o API en un solo lugar. Así será más fácil revisar los cambios futuros.
Para una revisión de seguridad más profunda, consulta la guía de Capgo sobre cómo proteger las actualizaciones OTA en pipelines de CI/CD. El hábito clave es simple: limita el acceso a tokens, registra la decisión de release y verifica el resultado tras cada cambio.
Mantén un registro de cambios
Guarda el umbral junto al commit o ID de release. Añade el motivo del cambio. Si un rollout se pausa inesperadamente, podrás comparar la política con el bundle y el momento del deployment.
Capgo se factura como una suscripción por organización, con una prueba gratuita de 14 días en lugar de una compra única. Ese modelo encaja con equipos que quieren probar su workflow de release antes de integrarlo en su proceso de entrega habitual. Céntrate en lo esencial durante la prueba: configura un channel, haz un test de pausa y verifica una ruta de rollback.
Un solo comando puede publicar la actualización. El workflow más seguro es el que también comprueba el channel, monitoriza la adopción y deja una ruta de rollback.
FAQ
¿Qué significa auto pause minimum attempts en Capgo?
El auto pause minimum attempts de Capgo establece el mínimo de intentos de instalación y fallos necesarios antes de que la política de auto-pause pueda actuar. Es un filtro de tamaño de muestra, no un porcentaje de instalaciones fallidas. Un valor bajo reacciona antes, pero puede depender de menos evidencia. Un valor más alto da al channel más tiempo para recopilar resultados.
¿Dónde configuro el auto pause minimum attempts en Capgo?
Configura 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. Verifica primero el nombre del canal. Editar un canal de prueba cuando producción está activa no cambiará el rollout de producción.
¿Cuál es un valor seguro para el mínimo de intentos?
Un valor seguro depende del tamaño del canal, la mezcla de dispositivos, la calidad de la red y el riesgo del release. Usa un umbral menor para un canal de prueba controlado. Usa un umbral mayor para un rollout 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 un release?
No. Alcanzar el valor mínimo de intentos de Capgo hace que el rollout sea elegible para la pausa automática, pero otras condiciones de la política siguen importando. Las señales de fallo, los ajustes de confianza, el estado del canal y el flujo del updater pueden afectar el resultado. Prueba el flujo completo de pausa con un bundle seguro antes de confiar en ella en producción.
¿Puede la pausa automática reemplazar un plan de rollback?
No. La pausa automática detiene o limita la exposición adicional, mientras que el rollback lleva a los usuarios hacia un bundle que se sabe que funciona cuando esa vía 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 rollout de prueba pequeño, verifica los flujos de pausa y rollback, y luego automatiza la configuración aprobada en tu CI/CD. Si quieres probar el workflow, intenta con Capgo en un solo canal y un bundle controlado antes de expandir el rollout.
