Una pausa evita que un rollout llegue a más dispositivos. Un rollback devuelve los dispositivos afectados a una versión estable conocida. Capgo soporta ambas, por lo que puedes contener un problema primero y decidir qué hacer a continuación.
Usa estos pasos para elegir la acción correcta, verificar su efecto y reducir la probabilidad de repetir el incidente.
Leímos 6 guías públicas sobre despliegues escalonados y rollback publicadas por Google Play, Amazon Appstore, CodePush de Microsoft, Bitrise, Nearform y Digia. Cuatro de las 6 separan la pausa del rollback como acciones distintas, mientras que 2 omiten el rollback o tratan la pausa como la única palanca. Ninguna de las 6 explica cómo verificar la recuperación con analíticas o comprobaciones de dispositivo, y ninguna describe un flujo de trabajo para prevenir incidentes recurrentes. Elegir bien entre pausa y rollback, y luego confirmar que funcionó, cierra una brecha que permanece abierta en las guías públicas de lanzamiento.
Tabla de contenidos
- Paso 1: Configura los controles de lanzamiento en Capgo
- Paso 2: Elige si pausar o hacer rollback
- Paso 3: Pausar la exposición adicional mientras investigas
- Paso 4: Haz un rollback cuando los usuarios necesiten una versión estable
- Paso 5: Verifica la recuperación con analytics y comprobaciones de dispositivos
- Paso 6: Evita incidentes recurrentes con workflows de release más seguros
- FAQ
- Conclusión
Paso 1: Configura los controles de lanzamiento en Capgo
Antes de un incidente, asegúrate de que tu equipo sepa qué canal está entregando el lanzamiento y qué bundle es estable. Un canal es un carril con nombre que dirige los dispositivos de la app a una actualización. Un bundle es el code web actualizable que se envía por ese carril.
En Capgo, un rollout progresivo puede mantener un bundle estable en su lugar mientras envía un objetivo de rollout separado a un grupo seleccionado. Eso te da un punto de control antes de que el nuevo bundle llegue a la base de usuarios más amplia. Revisa los controles de rollout progresivo antes de habilitar uno en producción.
Anota al responsable del lanzamiento y las señales que deberían 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 informa 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 porque suena estricto.
Una actualización OTA cambia el code actualizable de la app de forma inalámbrica. No reemplaza el binario nativo de la app instalado desde una tienda de aplicaciones. El término actualización over-the-air describe este método de entrega. Ten presente este límite: si una corrección requiere un nuevo plugin nativo o un cambio en la configuración nativa de la app, un rollback del bundle no lo proporcionará.
Antes del lanzamiento, confirma que el bundle estable es el que esperas. Verifica el nombre del canal, el bundle objetivo y el estado del rollout. Un error tipográfico en el nombre del canal o un objetivo obsoleto puede enviar a los responsables hacia el control equivocado cuando cada minuto cuenta.
A estas alturas, deberías tener un responsable de release designado, un bundle conocido como estable y una condición de parada documentada. Esa preparación convierte la siguiente decisión en una elección operativa, no en una carrera contra el reloj por el dashboard.
Conclusión clave: Una pausa limita la nueva exposición. Un rollback cambia la versión a la que se dirigen los usuarios.
Paso 2: Elige si pausar o hacer rollback
Para la decisión de pause rollout vs rollback de Capgo, pregúntate primero: ¿intentas evitar que más dispositivos reciban el target o sacar a los dispositivos de un target que ya está causando daños? Pausar 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 pausar 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 validado es más seguro. Pausar 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 Referencia del channel CLI de Capgo lista controles separados de pause y rollback. Trátalos como acciones distintas, no como dos nombres para el mismo botón 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 vinculado a code nativo o a un servicio | Pausar o contener el cambio en la app y luego corregir la capa afectada | Comprobar si hace falta un Native Build o reparar un servicio |
| Solo un grupo pequeño tiene el target, sin impacto confirmado en usuarios | Pausar mientras se investiga | Reanudar solo tras la aprobación del responsable |
Un rollback no arreglará una caída del backend ni añadirá una capacidad nativa que falta. Primero identifica qué capa falló. Si el problema está en el web bundle, elige entre pausar o revertir según cuántos usuarios necesiten una solución rápida.
Paso 3: Pausar la exposición adicional mientras investigas
Pausa cuando necesitas evitar que nuevos dispositivos entren al grupo de rollout, pero aún no estás listo para revertir el objetivo para los dispositivos que ya están en él. Es una medida de contención. Te da tiempo para verificar los hechos mientras impides que el problema se extienda a más usuarios.
Abre el canal de producción y verifica que estás actuando sobre el rollout afectado. Pausa usando el dashboard, CLI o el control de API que use tu equipo. Luego, lee el estado del canal. No confíes solo en que un comando se complete con éxito; confirma que el rollout ahora aparece como pausado.
En el modelo de rollout progresivo de Capgo, los dispositivos que ya están en la cohorte pueden permanecer en el objetivo del rollout después de una pausa. Los nuevos dispositivos elegibles reciben el fallback estable en su próxima verificación. Esa distinción es importante: la pausa detiene la entrada nueva, pero no mueve la cohorte existente de vuelta a estable.
A continuación, captura los detalles de la release antes de hacer otro cambio. Registra el bundle objetivo, el canal, la hora de la pausa y el primer informe conocido. Mantén los detalles de dispositivo o sesión que tu equipo está autorizado a recopilar. Una línea de tiempo clara te ayuda a comparar la cohorte de rollout con los dispositivos que siguen en el bundle estable.
Verifica el problema a través de una ruta reproducible. Si los usuarios reportan un inicio de sesión fallido, prueba ese viaje exacto en un dispositivo afectado. Si la app se cierra al lanzarse, comprueba si el crash coincide con el nuevo bundle y la versión nativa de la app. Evita tratar cada informe de soporte como prueba de que la actualización causó el problema.
Asigna un responsable y un tiempo de decisión para la investigación. Un rollout en pausa puede quedarse en limbo si nadie es dueño del siguiente paso. El responsable debe reanudar tras evidencia que aclare la release o elegir rollback si el objetivo sigue siendo inseguro.
Consejo pro: Informa al equipo de soporte y al equipo de release de que el rollout está en pausa. De lo contrario, un grupo puede seguir escalando informes mientras otro asume que el rollout ya se ha revertido.
A estas alturas, los nuevos dispositivos ya no deberían estar entrando en la cohorte de rollout. Revisa el estado del canal y el comportamiento de un dispositivo que no estaba en la cohorte antes de pasar a rollback o reanudar.
Paso 4: Haz un rollback cuando los usuarios necesiten una versión estable
Haz rollback cuando los usuarios ya en el objetivo necesiten volver hacia un bundle conocido como bueno. Esta es la respuesta más fuerte que pausar. Cambia lo que el canal sirve, así que verifica el build estable seleccionado antes de confirmar la acción.
En Capgo, abre el canal afectado y revisa su historial de builds. Elige la versión que quieres restaurar y confirma que es el bundle estable correcto para esta app y canal. Capgo’s documentación de rollback describe la ruta en el dashboard y señala que los dispositivos recibirán la build seleccionada la próxima vez que busquen una actualización.
Tras el rollback, no asumas que todos los dispositivos cambiaron a la vez. Un dispositivo necesita comprobar si hay actualizaciones, y un usuario sin conexión puede no hacerlo hasta más tarde. Mantén el incidente abierto hasta que hayas verificado la versión activa del canal y probado la ruta de recuperación en un dispositivo del grupo afectado.
Usa el bundle integrado solo cuando ese sea el objetivo de recuperación previsto. Apunta los dispositivos de vuelta al build web empaquetado dentro de 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. Conserva los logs relevantes antes de la limpieza, sobre todo si necesitas entender por qué el problema no se detectó en las pruebas.
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 que no está 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 comprobaciones de dispositivos
Tras una pausa o un rollback, verifica qué están haciendo los dispositivos en lugar de tratar el cambio de control como prueba de recuperación. Primero revisa el estado del canal activo. Luego compara la adopción de actualizaciones, los errores y los 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 concretas: ¿los dispositivos nuevos siguen recibiendo el target?, ¿los dispositivos afectados están consultando el bundle estable? y ¿dejó de producirse el fallo reportado tras la recuperación?
Prueba el flujo de usuario que falló. Una descarga correcta no demuestra que la app funcione. Abre la pantalla correspondiente, repite la acción que generó el reporte y verifica que la app llegue al estado esperado. Si el incidente afecta a un flujo crítico, pide a alguien que no haya hecho el cambio que confirme el resultado.
Compara lo comparable. Un conteo amplio de errores puede aumentar por causas ajenas al release, como un problema de servicio o un cambio en el tráfico. Filtra por bundle, channel, versión de la app y dispositivo cuando esos campos estén disponibles. Busca una diferencia asociada al release en lugar de culpar por defecto a la última actualización.
Revisa también a los usuarios que no se han actualizado. Su presencia puede hacer que las métricas generales se vean bien mientras el grupo afectado sigue viendo el bug. Sigue la proporción de dispositivos en el target frente a la proporción en stable, y mantén los reportes de soporte vinculados a la versión que ejecutan realmente los usuarios.
Anota el resultado de la recuperación y la incertidumbre que queda. Si los errores bajan pero algunos usuarios siguen reportando el mismo problema, no cierres el incidente hasta entender si están offline, en un shell nativo antiguo o siguen usando el bundle afectado.
La recuperación se confirma cuando el canal apunta a la versión prevista y el flujo de usuario que fallaba funciona en un dispositivo que pueda reproducir el problema. Las métricas te ayudan a ver la forma del problema; una prueba en dispositivo confirma lo que experimenta una persona.
Paso 6: Evita incidentes recurrentes con workflows de release más seguros
Incluye la pausa y el rollback en el 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 estable. Así eliminas un retraso habitual: esperar una reunión mientras más dispositivos entran en el rollout.
Mantén asignado un fallback estable mientras se prueba el objetivo del rollout. Usa primero una cohorte pequeña y definida, y amplía solo cuando las señales de salud acordadas se mantengan dentro de tus límites. Capgo admite control de releases basado en canales, para que los equipos puedan separar las pruebas de la entrega amplia a producción.
Integra checks de release en tu CI/CD, el proceso automatizado que ejecuta tests y despliega un cambio. Un pipeline puede publicar el bundle en el canal previsto tras pasar los tests. También debe fallar de forma segura si el canal es incorrecto o si el release no está listo para su promoción.
Un flujo de continuous delivery mantiene el software listo para el release mediante un proceso automatizado. Para un flujo OTA, mantén claro el punto de aprobación humana incluso cuando la publicación sea automática. La automatización debe hacer repetible la acción elegida, no debe tomar la decisión por un cambio sin revisar.
Con Capgo, un despliegue de un solo comando puede publicar un bundle en un canal. Mantén el comando en el mismo proceso de release que tus checks y haz que el canal de destino sea visible en el registro del despliegue. Esto ayuda al ingeniero on-call a ver exactamente qué se lanzó sin adivinar qué lane lo recibió.
Antes de habilitar salvaguardas automáticas, define qué señal las activa y qué acción realizan. Una pausa puede detener la nueva exposición manteniendo los dispositivos de la cohorte actual en el objetivo. Un rollback puede dirigir los dispositivos hacia una versión estable. Esos resultados difieren, así que no configures uno como si fuera el otro.
Usa un canal de prueba para ensayar la respuesta completa. Publica un cambio inofensivo, verifica el control de pausa y luego prueba el rollback al bundle anterior. Confirma el comportamiento de la app en un dispositivo después de cada acción. Un runbook escrito debe incluir el canal, el comando o la ruta del dashboard, el estado esperado y la persona que confirma el éxito.
Las notas de la versión deben identificar el bundle y su propósito. Mantén un vínculo entre el registro de despliegue y el cambio en el código para que los ingenieros puedan acotar la búsqueda si aparece un error. Si tu equipo transfiere incidentes entre distintas zonas horarias, incluye la última acción realizada y quién debe tomar 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 puede ser relevante para el desarrollo web. Eso es independiente de los controles de rollout de Capgo, que gestionan la entrega y recuperación de actualizaciones de apps 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 revierte los dispositivos ya actualizados?
No. Pausar evita que nuevos dispositivos elegibles entren en el rollout, pero los dispositivos que ya están en la cohorte pueden permanecer en el bundle de destino. Para devolver a esos usuarios a una versión estable, usa rollback u otra acción deliberada sobre el canal. Revisa el estado del canal después del 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 evitar una mayor exposición. Haz rollback cuando sepas que el target daña a los usuarios o cuando los dispositivos afectados necesiten un bundle estable. La decisión de Capgo entre pausar el rollout y hacer rollback depende de si la necesidad inmediata es contener o recuperar la cohorte actual.
¿Un rollback actualizará todos los dispositivos de inmediato?
No. Un rollback cambia el bundle al que apunta el canal, pero los dispositivos lo reciben la próxima vez que busquen una actualización. Un dispositivo offline puede quedarse en su bundle actual hasta que se reconecte. Verifica el target del canal y luego revisa 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 OTA puede restaurar un bundle web actualizable anterior, pero no puede añadir o eliminar code nativo dentro del binario de la app instalada. Si el problema proviene de un plugin nativo o de un cambio en la app-shell, evalúa si se necesita un nuevo build nativo. Primero identifica qué capa causó el fallo.
¿Qué debo revisar tras pausar o hacer un rollback?
Confirma el estado del canal y el bundle activo, luego revisa la adopción de la actualización y los errores por release. Prueba el flujo de usuario 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 generales pueden ocultar problemas limitados a una versión o cohorte.
Conclusión
Pausa cuando necesites detener la nueva exposición mientras investigas. Haz rollback cuando los usuarios del objetivo necesiten una versión estable. Configura ambos controles de antemano y ensáyalos en un canal de prueba antes de tu próxima release en producción.
