Una pausa detiene la expansión a más dispositivos. Un rollback mueve dispositivos afectados hacia una versión conocida y segura. Capgo Soporta ambos, así que puedes contener un problema primero y decidir qué hacer a continuación.
Siga estos pasos para elegir la acción correcta, verificar su efecto y reducir la probabilidad de repetir el incidente.
We read 6 public guides on staged rollouts and rollback published by Google Play, Amazon Appstore, Microsoft’s CodePush, Bitrise, Nearform, and Digia. Four of the 6 separate pausing from rolling back as distinct actions, while 2 skip rollback or treat pause as the only lever. None of the 6 explain how to verify recovery with analytics or device checks, and none describe a workflow for preventing repeat incidents. Getting the pause-versus-rollback choice right, then confirming it worked, closes a gap left open across public release guidance.
__CAPGO_KEEP_0__
- Paso 1: Configura el control de versiones en Capgo
- Paso 2: Elija pausar o retroceder
- Paso 3: Detenga la exposición adicional mientras investiga
- Paso 4: Volver atrás cuando los usuarios necesitan una versión estable
- Paso 5: Verificar la recuperación con análisis y comprobaciones de dispositivo
- Step 6: Evita incidentes repetidos con flujos de liberación más seguros
- FAQ
- Conclusión
Paso 1: Configura el control de liberación en Capgo
Before an incident, make sure your team knows which channel is delivering the release and which bundle is stable. A channel is a named lane that directs app devices to an update. A bundle is the updateable web code sent through that lane.
En Capgo, un despliegue progresivo puede mantener un paquete estable en su lugar mientras envía un objetivo de despliegue separado a un grupo seleccionado. Eso te da un punto de control antes de que el nuevo paquete llegue a la base de usuarios más amplia. Revisa los controles de despliegue progresivo antes de habilitarlos en producción. antes de habilitarlo en producción.
Una actualización OTA cambia la aplicación web actualizable __CAPGO_KEEP_0__ a través de la red. No reemplaza el binario nativo de la aplicación instalado desde una tienda de aplicaciones. El término actualización sobre la red describe este enfoque de entrega. Ten en cuenta esta frontera: si un arreglo necesita un nuevo plugin nativo o un cambio en la configuración nativa de la aplicación, un rollback de paquetes no lo proporcionará.
An OTA update changes the app’s updateable code over the air. It doesn’t replace the native app binary installed from an app store. The term over-the-air update describes this delivery approach. Keep this boundary in mind: if a fix needs a new native plugin or a change to the app’s native setup, a bundle rollback won’t supply it.
Antes de la liberación, confirme que el paquete estable es el que espera. Verifique el nombre del canal, el paquete objetivo y el estado de la implementación. Un error de ortografía en el nombre de un canal o un paquete obsoleto pueden enviar a los responsables hacia el control incorrecto cuando cada minuto importa.
Por ahora, debería tener un propietario de liberación nombrado, un paquete conocido bueno y una condición de parada escrita. Esa preparación convierte la próxima decisión en una elección operativa, no en un despliegue a través del panel de control.
Toma de Puntos Clave: Un pausa limita la nueva exposición. Un rollback cambia la versión a la que se dirigen los usuarios.
Paso 2: Elija si pausar o retroceder
Para la decisión de pausa de implementación vs rollback del Capgo, pregunte una pregunta primero: ¿está tratando de detener más dispositivos de recibir el objetivo, o mover dispositivos de un objetivo que ya está causando daño? Una pausa limita la nueva exposición. Un rollback elimina el objetivo y devuelve a los dispositivos al fallback estable en su próxima verificación de actualización.
Elija pausa cuando la evidencia es incompleta o el problema parece limitado. Puede tener un puñado de informes pero no sabe si el bug afecta un tipo de dispositivo, un flujo de usuario particular o todos los dispositivos actualizados. Pausar da a la equipe espacio para inspeccionar el señal sin agregar nuevos dispositivos al grupo de implementación.
Elegir rollback cuando el objetivo es claramente inseguro para los usuarios, o cuando el equipo tiene suficiente evidencia de que el paquete conocido es más seguro. Una pausa sola no elimina el objetivo malo de los dispositivos ya en la cohorte de lanzamiento. Si esos usuarios necesitan regresar a estable, el rollback es la acción que cambia su ruta de actualización.
El El canal de Capgo de referencia CLI listas controles de pausa y rollback separados. Trátalos como acciones diferentes, no dos nombres para el mismo freno de emergencia.
| Lo que ves | Acción inicial | ¿Qué verificar a continuación |
|---|---|---|
| Lo que verificar a continuación | Errores tempranos, alcance incierto | Comparar dispositivos afectados e inafectados |
| Comparar dispositivos afectados e inafectados | Revertir el objetivo | Confirmar que el paquete estable está activo |
| Problema relacionado con nativo code o un servicio | Detener o contener el cambio de la aplicación, luego arreglar la capa afectada | Verificar si se necesita una reparación de construcción nativa o de servicio |
| Solo un pequeño grupo tiene el objetivo, con impacto de usuario confirmado | Detener mientras se investiga | Reanuda solo después de que el propietario de la versión apruebe |
Un rollback no arreglará una interrupción de backend, y no puede agregar una capacidad nativa faltante. Primero identifica qué capa falló. Si el paquete web es el culpable, elija entre detener y revertir según cuántos usuarios necesitan alivio.
Paso 3: Detener la exposición adicional mientras investigas
Detener cuando necesitas detener nuevos dispositivos de entrar al grupo de rollout pero no estás listo para revertir el objetivo para dispositivos ya en él. Este es un paso de contención. Compra tiempo para verificar los hechos mientras mantienes el problema de difundirse a más usuarios.
Abrir el canal de producción y verificar que estás actuando en el rollout afectado. Detenerlo con el panel de control, CLI, o API que tu equipo utiliza. Luego lee el estado del canal de nuevo. No confíes solo en que una orden se complete con éxito; confirma que el rollout ahora muestra como detenido.
In el modelo de rollout progresivo de Capgo, los dispositivos ya en la cohorte pueden permanecer en el objetivo de rollout después de una pausa. Los dispositivos nuevos elegibles reciben la versión estable en su próxima verificación. Esa distinción importa: la pausa detiene la entrada nueva, pero no mueve la cohorte existente de vuelta a la versión estable por sí misma.
Captura los detalles de la liberación antes de hacer otro cambio. Registra el paquete objetivo, el canal, el momento de la pausa y el primer informe conocido. Mantén los detalles del dispositivo o sesión que tu equipo está autorizado a recopilar. Una cronología clara te ayuda a comparar la cohorte de rollout con dispositivos que siguen con el paquete estable.
Verifica el problema a través de un camino repetible. Si los usuarios informan un inicio de sesión fallido, prueba ese viaje exacto en un dispositivo afectado. Si la aplicación se cae al iniciar, verifica si el error se alinea con el nuevo paquete y la versión nativa de la aplicación. Evita tratar cada informe de soporte como prueba de que la actualización causó el problema.
Establece un propietario y un plazo de decisión para la investigación. Un rollout pausado puede quedar en limbo si nadie asume el próximo paso. El propietario debe reanudar después de que la evidencia aclare la liberación o elegir el rollback cuando el objetivo sigue siendo inseguro.
Consejo Pro: Avísale a soporte y al equipo de liberación que el rollout está pausado. De lo contrario, un grupo puede seguir elevando informes mientras otro asume que el rollout ya ha sido revertido.
Por ahora, los nuevos dispositivos ya no deberían estar ingresando al conjunto de rollout. Verifique el estado del canal y el comportamiento de un dispositivo que no estaba en el conjunto antes de moverse a rollback o reanudar.
Step 4: Volver atrás cuando los usuarios necesitan una versión estable
Volver atrás cuando los usuarios ya están en el objetivo y necesitan moverse hacia una versión conocida y buena. Esto es la respuesta más fuerte que pausar. Cambia qué el canal sirve, así que verifique la versión estable seleccionada antes de confirmar la acción.
In Capgo, abra el canal afectado y revise su historia de compilación. Elija la versión que desea restaurar, luego confirme que es la paquete estable correcto para esta aplicación y canal. Capgo’s documentación de rollback describe el camino del panel de control y nota que los dispositivos reciben la compilación seleccionada la próxima vez que busquen una actualización.
Después de rollback, no asuma que todos los dispositivos cambiaron al mismo tiempo. Un dispositivo necesita buscar actualizaciones, y un usuario offline puede no hacerlo hasta más tarde. Mantenga el incidente abierto hasta que haya verificado la versión activa del canal y haya probado el camino de recuperación en un dispositivo en el conjunto afectado.
Utilice el paquete integrado solo cuando ese sea el objetivo de recuperación intencionado. Puntúa a los dispositivos hacia la compilación web empaquetada dentro de la aplicación nativa, que puede diferir de la última compilación OTA. Verifique la compatibilidad y el impacto del usuario antes de elegirlo como paso de recuperación.
Conservar el paquete que causó el incidente disponible para análisis a menos que su proceso de retención diga lo contrario. El ID de la versión y el commit ayudan a los ingenieros a comparar el cambio con la versión estable. Preservar registros relevantes antes de la limpieza, especialmente si necesita entender por qué el problema escapó de la prueba.
No es el rollback la solución correcta para cada falla. Si la causa raíz es una dependencia del lado del servidor, repare ese servicio. Si el cambio depende de una code nativa ausente de los binarios instalados, prepare una compilación nativa y siga el camino de lanzamiento de la tienda de aplicaciones para ese cambio.
Paso 5: Verificar la recuperación con análisis y comprobaciones de dispositivos
Después de una pausa o rollback, verifique qué dispositivos están haciendo en lugar de tratar el cambio de control como prueba de recuperación. Compruebe el estado del canal activo primero. Luego compare la adopción de actualizaciones, errores y informes de dispositivos entre la versión afectada y la versión estable.
Las señales de Capgo’s live update analytics pueden ayudarlo a inspeccionar métricas de adopción, tasas de errores y registros de dispositivos. Utilice esas señales para responder preguntas específicas: ¿los dispositivos nuevos siguen recibiendo el objetivo, ¿los dispositivos afectados están buscando el paquete estable, y ¿el fallo reportado se detuvo después de la recuperación?
Prueba el camino del usuario que falló. Un descarga exitosa no prueba que la aplicación funcione. Abre la pantalla relevante, repite la acción que llevó al informe y verifica que la aplicación alcance el estado esperado. Si el incidente involucra un flujo crítico, que alguien distinto de la persona que hizo el cambio confirme el resultado.
Compara lo mismo con lo mismo. Un alto recuento de errores puede aumentar por razones no relacionadas con la versión, como un problema de servicio o un cambio en el tráfico. Filtra por paquete, canal, versión de la aplicación y dispositivo donde estén disponibles. Busca una diferencia relacionada con la versión en lugar de culpar por defecto al último update.
También verifica 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. Sigue los porcentajes de dispositivos en el objetivo frente a los de estable, y mantén los informes de soporte vinculados a la versión que los usuarios realmente ejecutan.
Anota el resultado de la recuperación y la incertidumbre restante. Si los errores caen pero un par de usuarios siguen reportando el mismo problema, no cierres el incidente hasta que entiendas si están desconectados, en una caja nativa más antigua o todavía utilizando el paquete afectado.
La recuperación se confirma cuando el canal apunta a la versión deseada y el camino del usuario fallido funciona en un dispositivo que pudo reproducir el problema. Las métricas te ayudan a ver la forma del problema; un dispositivo de verificación confirma lo que una persona experimenta.
Paso 6: Evita incidentes repetidos con flujos de liberación más seguros
Haga que la pausa y el rollback sean parte del plan de liberación antes de publicar. El propietario de la liberación debe saber quién puede detener la exposición y quién puede aprobar un regreso a estable. Eso elimina un retraso común: esperar a una reunión mientras más dispositivos entran en la rollout.
Mantenga un fallback estable asignado mientras se prueba el objetivo de la rollout. Utilice un pequeño conjunto definido primero, luego amplíe solo cuando los señales de salud acordadas permanezcan dentro de sus límites. Capgo admite el control de liberación basado en canales, por lo que los equipos pueden separar la prueba de la entrega de producción amplia.
Coloque las comprobaciones de liberación en CI/CD, el proceso automatizado que ejecuta pruebas y despliega un cambio. Una canalización puede publicar el paquete en el canal previsto después de que pasen las pruebas. También debe fallar de manera segura si el canal es incorrecto o la liberación no está lista para la promoción.
Un flujo de entrega continuo mantiene el software listo para la liberación a través de un proceso automatizado. Para un flujo de OTA, mantenga el punto de aprobación humana claro incluso cuando la publicación es automática. La automatización debe hacer que la acción elegida sea repetible, no tomar la decisión para un cambio no revisado.
Con Capgo, un despliegue de un comando puede publicar un paquete en un canal. Mantenga el comando en el mismo proceso de liberación que sus comprobaciones, y haga visible el canal objetivo en el registro de despliegue. Eso ayuda al ingeniero de llamada ver exactamente qué se envió sin adivinar qué carril lo recibió.
Antes de habilitar las medidas de seguridad automáticas, defina qué señal desencadena su acción y qué acción tomar. Una pausa puede detener la exposición nueva mientras que mantiene los dispositivos de la cohorte actual en el objetivo. Un rollback puede dirigir los dispositivos hacia un estado estable. Estos resultados difieren, por lo que no configures una como si fuera la otra.
Utilice un canal de prueba para ensayar la respuesta completa. Publique un cambio inocuo, verifique el control de pausa y luego pruebe el rollback a la versión anterior del paquete. Confirme el comportamiento de la aplicación en un dispositivo después de cada acción. Un libro de ejecución escrito debe incluir el canal, el comando o la ruta de la consola, el estado esperado y la persona que confirma el éxito.
Las notas de lanzamiento deben identificar el paquete y su propósito. Mantenga un enlace entre el registro de despliegue y el cambio de origen para que los ingenieros puedan reducir la búsqueda cuando aparece un error. Si su equipo pasa incidentes a través de zonas horarias, incluya la última acción realizada y el próximo dueño de la decisión.
Si los incidentes apuntan a una mayor implementación de la parte frontal del sitio, un desarrollador web como Amir Arezoo Puede ser relevante para el trabajo de desarrollo web. Esto es separado de los controles de Capgo para la entrega y recuperación de actualizaciones de aplicaciones compatibles.
Por ahora, su ruta de lanzamiento debe incluir un fallback estable, un dueño, una regla de parada y una acción de recuperación probada. Mantenga el flujo de trabajo lo suficientemente corto para que el ingeniero de llamada pueda usarlo bajo presión.
FAQ
¿Detiene pausar un lanzamiento de Capgo los dispositivos actualizados ya?
No. La pausa detiene a los dispositivos elegibles nuevos de entrar en la actualización, pero los dispositivos ya en el conjunto pueden permanecer en la versión objetivo. Para mover a los usuarios hacia una versión estable, utilice la función de rollback o otra acción deliberada en el canal. Verifique el estado del canal después de cualquiera de estos cambios, y luego confirme el resultado en un dispositivo que recibió la versión objetivo.
¿Cuándo debería pausar en lugar de retroceder?
Pause when the issue is still under investigation and you need to stop wider exposure. Roll back when the target is known to harm users or when affected devices need a stable bundle. The Capgo pause rollout vs rollback choice depends on whether the immediate need is containment or recovery for the existing cohort.
¿Actualizan todos los dispositivos de inmediato?
No. Un rollback OTA puede restaurar una versión web anteriormente actualizable, pero no puede agregar o eliminar componentes nativos dentro de un binario de aplicación instalada. Si el problema proviene de un cambio en un plugin o app-shell nativo, evalúe si se necesita una nueva compilación nativa. Primero identifique qué capa causó el fallo.
¿Qué debería verificar después de pausar o retroceder?
No. An OTA rollback can restore an earlier updateable web bundle, but it can’t add or remove native code inside an installed app binary. If the issue comes from a native plugin or app-shell change, assess whether a new native build is needed. First identify which layer caused the failure.
¿Qué debo verificar después de pausar o deshacer?
Confirmar el estado del canal y el paquete activo, luego verificar la adopción de actualizaciones y errores por liberación. Prueba la experiencia del usuario que falló en un dispositivo del grupo afectado. También verifica 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
Detener cuando necesites parar la exposición nueva mientras investigas. Revertir cuando los usuarios del objetivo necesitan una versión estable. Establece ambos controles con anticipación, luego practícalos en un canal de prueba antes de tu próxima liberación de producción.
