Una pausa detiene el rollout para que no llegue a más dispositivos. Un rollback devuelve los dispositivos afectados a una versión estable. Capgo soporta ambos, para que primero puedas contener el problema y luego decidir qué hacer.
Sigue estos pasos para elegir la acción correcta, verificar su efecto y reducir la probabilidad de que el incidente se repita.
Analizamos 6 guías públicas sobre staged rollouts y rollback publicadas por Google Play, Amazon Appstore, CodePush de Microsoft, Bitrise, Nearform y Digia. Cuatro de las 6 distinguen entre pausar y hacer rollback como acciones distintas, mientras que 2 omiten el rollback o tratan la pausa como la única opción. Ninguna de las 6 explica cómo verificar la recuperación mediante analytics o comprobaciones en el dispositivo, y ninguna describe un flujo de trabajo para prevenir incidentes recurrentes. Elegir correctamente entre pause y rollback, y luego confirmar que funcionó, cierra una brecha que dejan abierta las guías de lanzamiento públicas.
Table of Contents
- Paso 1: Configura los controles en Capgo
- Paso 2: Elige entre pausar o hacer rollback
- Paso 3: Pausa la exposición para investigar
- Paso 4: Haz rollback para dar estabilidad
- Paso 5: Verifica la recuperación con analytics
- Paso 6: Evita incidentes con mejores workflows
- FAQ
- Conclusión
Paso 1: Configura los controles en Capgo
Antes de un incidente, asegúrate de que tu equipo sepa qué channel está entregando el release y qué bundle es estable. Un channel es una vía con nombre que dirige los dispositivos a una actualización. Un bundle es el code web actualizable enviado por esa vía.
En Capgo, un progressive rollout permite mantener un bundle estable mientras se envía un target de rollout separado a un grupo seleccionado. Esto te da un punto de control antes de que el nuevo bundle llegue a toda la base de usuarios. Revisa los controles de progressive rollout antes de habilitar uno en producción.
Define quién es el responsable del release y qué señales deben detener la expansión. Por ejemplo, decide qué hará tu equipo si aumentan los fallos de actualización, si una pantalla clave deja de funcionar o si soporte reporta que los usuarios no pueden completar una tarea. Establece límites basados en el comportamiento normal de tu app en lugar de elegir un umbral solo por ser estricto.
Una actualización OTA cambia el code actualizable de la app de forma remota. No reemplaza el binario nativo instalado desde una app store. El término over-the-air describe este método de entrega. Ten clara esta distinción: si un fix requiere un nuevo plugin nativo o un cambio en la configuración nativa de la app, un rollback de bundle no lo solucionará.
Antes del release, confirma que el bundle estable sea el que esperas. Revisa el nombre del channel, el target bundle y el estado del rollout. Un error tipográfico en el nombre de un channel o un target desactualizado puede hacer que pierdas tiempo valioso buscando el control correcto.
A estas alturas ya deberías tener un responsable de release, un bundle estable y una condición de parada definida. Esa preparación convierte la siguiente decisión en una elección operativa, no en una carrera desesperada por el dashboard.
Conclusión clave: Una pausa limita la nueva exposición. Un rollback cambia la versión que se les asigna a los usuarios.
Paso 2: Elige entre pausar o hacer rollback
Para decidir entre Capgo pause rollout vs rollback, hazte una pregunta primero: ¿intentas evitar que más dispositivos reciban el target, o quieres retirar a los dispositivos de un target que ya está causando daños? Un pause limita la nueva exposición. Un rollback elimina el target y devuelve los dispositivos al fallback estable en su próxima comprobación de actualización.
Elige pause cuando la evidencia sea incompleta o el problema parezca limitado. Puede que tengas unos pocos reportes pero no sepas si el bug afecta a un tipo de dispositivo, a un flujo de usuario concreto o a todos los dispositivos actualizados. Pausar le da al equipo margen para inspeccionar la señal sin añadir nuevos dispositivos al grupo de rollout.
Elige rollback cuando el target sea claramente inseguro para los usuarios, o cuando el equipo tenga evidencia suficiente de que el bundle conocido como estable es más seguro. Un pause por sí solo no elimina el target defectuoso de los dispositivos que ya están en la cohorte de rollout. Si esos usuarios necesitan volver a la versión estable, el rollback es la acción que cambia su ruta de actualización.
El canal Capgo referencia CLI lista controles de pause y rollback por separado. Trátalos como acciones distintas, no como dos nombres para la misma parada de emergencia.
| Lo que ves | Primera acción | Qué revisar después |
|---|---|---|
| Errores tempranos, alcance incierto | Pausar el rollout | Comparar dispositivos afectados y no afectados |
| Bug conocido que afecta al grupo objetivo | Hacer rollback del objetivo | Confirmar que el bundle estable está activo |
| Problema ligado a code nativo o a un servicio | Pausar o contener el cambio de la app y arreglar la capa afectada | Verificar si se requiere un Native Build o reparar un servicio |
| Solo un grupo pequeño tiene el target, sin impacto confirmado | Pausar mientras se investiga | Reanudar solo tras la aprobación del responsable del release |
Un rollback no arreglará una caída del backend ni añadirá una capacidad nativa faltante. Primero identifica qué capa falló. Si el error es del web bundle, elige entre pausar o revertir según cuántos usuarios necesiten la solución.
Paso 3: Pausar la exposición mientras investigas
Pausa cuando necesites evitar que nuevos dispositivos entren al grupo de rollout, pero aún no estés listo para revertir el target de los que ya están dentro. Es un paso de contención que te da tiempo para verificar los hechos sin que el problema se propague a más usuarios.
Abre el canal de producción y verifica que estás actuando sobre el rollout afectado. Paúsalo desde el dashboard, CLI o el control de API que use tu equipo. Luego, verifica el estado del canal. No te fíes solo de que un comando termine con éxito; confirma que el rollout aparezca como pausado.
En el modelo de progressive rollout de Capgo, los dispositivos que ya están en la cohorte pueden permanecer en el target del rollout tras una pausa. Los nuevos dispositivos elegibles recibirán el fallback estable en su siguiente comprobación. Esa distinción es clave: la pausa detiene la entrada de nuevos usuarios, pero no mueve automáticamente a la cohorte existente de vuelta a la versión estable.
A continuación, captura los detalles del release antes de realizar otro cambio. Registra el bundle de destino, el canal, la hora de la pausa y el primer reporte conocido. Guarda los detalles de dispositivos o sesiones que tu equipo tenga permitido recolectar. Una línea de tiempo clara te ayudará a comparar la cohorte del rollout con los dispositivos que siguen en el bundle estable.
Verifica el problema mediante un flujo repetible. Si los usuarios reportan un fallo al iniciar sesión, prueba ese mismo flujo en un dispositivo afectado. Si la app se cierra al abrirse, comprueba si el crash coincide con el nuevo bundle y la versión de la native app. Evita tratar cada reporte de soporte como una prueba definitiva de que la actualización causó el problema.
Asigna un responsable y un tiempo límite para la investigación. Un rollout pausado puede quedar en el limbo si nadie gestiona el siguiente paso. El responsable debe reanudarlo tras verificar la versión o elegir el rollback si el target sigue siendo inseguro.
Consejo: Informa a soporte y al equipo de release que el rollout está pausado. De lo contrario, un grupo podría seguir escalando reportes mientras otro asume que el rollout ya se revirtió.
A estas alturas, los nuevos dispositivos ya no deberían entrar en el cohort del rollout. Revisa el estado del channel y el comportamiento de un dispositivo que no estaba en el cohort antes de decidir entre rollback o reanudar.
Paso 4: Haz rollback cuando los usuarios necesiten una versión estable
Haz rollback cuando los usuarios que ya están en el target necesiten volver a un bundle conocido como estable. Esta es una respuesta más contundente que pausar. Cambia lo que sirve el channel, así que verifica el build estable seleccionado antes de confirmar la acción.
En Capgo, abre el channel afectado y revisa su historial de builds. Elige la versión que quieras restaurar y confirma que es el bundle estable correcto para esta app y channel. La documentación de Capgo sobre documentación de rollback describe la ruta en el dashboard y señala que los dispositivos recibirán el build seleccionado la próxima vez que busquen una actualización.
Tras el rollback, no asumas que todos los dispositivos cambiaron al instante. Un dispositivo debe buscar una actualización, y un usuario offline podría no hacerlo hasta más tarde. Mantén el incidente abierto hasta que hayas verificado la versión activa del channel y probado la recuperación en un dispositivo del cohort afectado.
Usa el bundle integrado solo si ese es el objetivo de recuperación deseado. Este redirige los dispositivos al web build empaquetado en la app nativa, que puede diferir del último bundle OTA. Verifica la compatibilidad y el impacto en el usuario antes de elegirlo como paso de recuperación.
Mantén disponible el bundle que causó el incidente para su análisis, a menos que tu proceso de retención indique lo contrario. El release ID y el commit ayudan a los ingenieros a comparar el cambio con la versión estable. Preserva los logs relevantes antes de la limpieza, especialmente si necesitas entender por qué el error pasó los tests.
El rollback no es la solución para todos los fallos. Si la causa raíz es una dependencia del lado del servidor, repara ese servicio. Si el cambio depende de un code nativo ausente en los binarios instalados, prepara un Native Build y sigue el flujo de release de la app store para ese cambio.
Paso 5: Verifica la recuperación con analytics y chequeos de dispositivos
Tras una pausa o un rollback, verifica qué están haciendo los dispositivos en lugar de asumir que el cambio de control es prueba de recuperación. Primero revisa el estado del canal activo. Luego compara la adopción de updates, errores y reportes de dispositivos entre la release afectada y la versión estable.
La analítica de live update de Capgo te ayuda a inspeccionar métricas de adopción, tasas de error y logs a nivel de dispositivo. Usa esas señales para responder preguntas clave: ¿los nuevos dispositivos siguen recibiendo el target?, ¿los dispositivos afectados están buscando el bundle estable? y ¿se detuvieron los fallos reportados tras la recuperación?
Prueba el flujo de usuario que falló. Una descarga exitosa no garantiza que la app funcione. Abre la pantalla correspondiente, repite la acción que causó el reporte y verifica que la app llegue al estado esperado. Si el incidente afecta a un flujo crítico, pide a alguien ajeno al cambio que confirme el resultado.
Compara peras con peras. El conteo de errores puede subir por razones ajenas al release, como un problema de servicio o cambios en el tráfico. Filtra por bundle, channel, versión de la app y dispositivo donde sea posible. Busca diferencias vinculadas al release en lugar de culpar a la última actualización por defecto.
Revisa también a los usuarios que no se han actualizado. Su presencia puede hacer que las métricas generales parezcan saludables mientras el grupo afectado sigue viendo el bug. Monitorea la proporción de dispositivos en el target frente a la versión estable, y vincula los reportes de soporte a la versión que el usuario realmente ejecuta.
Documenta el resultado de la recuperación y la incertidumbre restante. Si los errores bajan pero algunos usuarios siguen reportando el mismo problema, no cierres el incidente hasta entender si están offline, usan un native shell antiguo o siguen en el bundle afectado.
La recuperación se confirma cuando el canal apunta a la versión deseada y el flujo de usuario afectado funciona en un dispositivo donde se pudo reproducir el error. Las métricas te ayudan a entender la magnitud del problema; una prueba en dispositivo confirma la experiencia real del usuario.
Paso 6: Evita incidentes recurrentes con workflows de release más seguros
Integra el pause y el rollback en tu plan de release antes de publicar. El responsable del release debe saber quién puede detener la exposición y quién puede aprobar el retorno a la versión estable. Así evitarás un retraso común: esperar a una reunión mientras más dispositivos entran en el rollout.
Mantén asignado un fallback estable mientras se testea el objetivo del rollout. Usa primero un cohort pequeño y definido, y expande solo cuando las señales de salud acordadas se mantengan en tus límites. Capgo permite el control de releases basado en canales, para que los equipos puedan separar el testing del despliegue masivo en producción.
Implementa checks de release en tu CI/CD, el proceso automatizado que ejecuta tests y despliega cambios. Un pipeline puede publicar el bundle en el canal correspondiente tras pasar los tests. También debe fallar de forma segura si el canal es incorrecto o si el release no está listo para el promotion.
Un workflow de continuous delivery mantiene el software listo para el release mediante un proceso automatizado. Para un workflow de OTA, mantén claro el punto de aprobación humana incluso si la publicación es automatizada. La automatización debe hacer que la acción elegida sea repetible, no tomar la decisión por un cambio que no ha sido revisado.
Con Capgo, un despliegue de un solo comando puede publicar un bundle en un canal. Mantén el comando dentro del mismo proceso de release que tus checks y haz que el canal de destino sea visible en el registro de despliegue. Eso ayuda al ingeniero de guardia a ver exactamente qué se lanzó sin adivinar qué lane lo recibió.
Antes de activar salvaguardas automáticas, define qué señal las activa y qué acción ejecutan. Un pause puede detener la nueva exposición mientras mantiene a los dispositivos del cohort actual en el objetivo. Un rollback puede redirigir los dispositivos hacia la versión estable. Esos resultados difieren, así que no configures uno como si fuera el otro.
Usa un canal de test para ensayar la respuesta completa. Publica un cambio inofensivo, verifica el control de pause y luego prueba el rollback al bundle anterior. Confirma el comportamiento de la app en un dispositivo tras cada acción. Un runbook escrito debe incluir el canal, el comando o la ruta en el dashboard, el estado esperado y la persona que confirma el éxito.
Las release notes deben identificar el bundle y su propósito. Mantén un vínculo entre el registro de despliegue y el cambio en el source para que los ingenieros puedan acotar la búsqueda cuando aparezca un error. Si tu equipo transfiere incidentes entre distintas zonas horarias, incluye la última acción realizada y el responsable de la siguiente decisión.
Si el incidente apunta a un cuello de botella más amplio en la implementación del front-end, un desarrollador web como Amir Arezoo podría ser relevante para tareas de desarrollo web. Eso es independiente de los controles de rollout de Capgo, que gestionan la entrega y recuperación de app updates compatibles.
A estas alturas, tu flujo de release debería incluir un fallback estable, un responsable, una regla de parada y una acción de recuperación probada. Mantén el workflow lo suficientemente corto para que el ingeniero de guardia pueda ejecutarlo bajo presión.
FAQ
¿Pausar un rollout de Capgo hace un rollback en los dispositivos ya actualizados?
No. Pausar impide que nuevos dispositivos elegibles entren en el rollout, pero los dispositivos que ya están en el cohort pueden permanecer en el bundle de destino. Para devolver a esos usuarios a una versión estable, usa rollback u otra acción deliberada en el channel. Verifica el estado del channel tras el cambio y confirma el resultado en un dispositivo que haya recibido el target.
¿Cuándo debería pausar en lugar de hacer un rollback?
Pausa cuando el problema aún esté bajo investigación y necesites limitar la exposición. Haz un rollback cuando se sepa que el target daña a los usuarios o cuando los dispositivos afectados necesiten un bundle estable. La elección entre Capgo pause rollout vs rollback depende de si la necesidad inmediata es la contención o la recuperación del cohort actual.
¿Un rollback actualizará todos los dispositivos de inmediato?
No. Un rollback cambia el bundle al que apunta el channel, pero los dispositivos lo reciben cuando consultan la siguiente actualización. Un dispositivo offline puede permanecer en su bundle actual hasta que se reconecte. Verifica el target del channel y luego comprueba los dispositivos afectados y su estado de actualización antes de dar el incidente por resuelto.
¿Puede un rollback OTA solucionar un problema de una app nativa?
No. Un rollback de OTA puede restaurar un web bundle anterior, pero no puede añadir ni eliminar code nativos dentro del binario de la app instalada. Si el problema viene de un plugin nativo o un cambio en el app-shell, evalúa si hace falta un nuevo Native Build. Primero identifica qué capa causó el fallo.
¿Qué debo revisar tras pausar o hacer un rollback?
Confirma el estado del channel y el bundle activo, luego revisa la adopción de updates y los errores por release. Prueba el user journey que falló en un dispositivo del grupo afectado. También revisa los dispositivos que aún no se han actualizado, ya que las métricas globales pueden ocultar problemas limitados a una versión o cohort.
Conclusión
Usa Pause cuando necesites detener la exposición mientras investigas. Usa Rollback cuando los usuarios del target necesiten una versión estable. Configura ambos controles con antelación y pruébalos en un channel de test antes de tu próximo release a producción.
