Una pausa detiene la expansión de una actualización hacia más dispositivos. Un rollback mueve dispositivos afectados hacia una versión conocida y estable. 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.
Contenido de la Tabla
- Paso 1: Configura el control de versiones en Capgo
- Step 2: Elija si pausar o dar marcha atrás
- Step 3: Pausa la exposición adicional mientras investigas
- Step 4: Da marcha atrás cuando los usuarios necesiten una versión estable
- Step 5: Verifica la recuperación con análisis y comprobaciones de dispositivo
- Step 6: Prevenga incidentes repetidos con flujos de liberación más seguros
- FAQ
- Conclusion
Step 1: Configura los controles 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, una liberación progresiva puede mantener un paquete estable en su lugar mientras envía un objetivo de liberación separado a un grupo seleccionado. Eso te da un punto de control antes de que el nuevo paquete alcance a la base de usuarios más amplia. Revisa los controles de liberación progresiva antes de habilitarlos en producción.
Anótate el propietario de la versión y los indicadores que deberían detener la expansión. Por ejemplo, decide qué hará su equipo si aumentan los errores de actualización, una pantalla clave deja de funcionar o el soporte informa que los usuarios no pueden completar una tarea. Establezca límites basados en el comportamiento normal de su aplicación en lugar de elegir un umbral solo porque parece estricto.
Una actualización OTA cambia el code de la aplicación que se puede actualizar por aire. No reemplaza el binario de la aplicación nativa instalado desde una tienda de aplicaciones. El término actualización por aire describe este enfoque de entrega. Ten en cuenta esta frontera: si una corrección necesita un nuevo plugin nativo o un cambio en la configuración nativa de la aplicación, un rollback de paquete no lo proporcionará.
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 lanzamiento. Un error de ortografía en el nombre de un canal o un paquete obsoleto puede enviar a los responsables hacia el control incorrecto cuando cada minuto importa.
Hasta ahora, debería tener un propietario de versió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 desorden a través de la consola.
Tomado de la experiencia: Un pausa limita la exposición nueva. 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 Capgo rollout vs rollback, pregunte una pregunta primero: ¿está tratando de detener más dispositivos de obtener el objetivo, o mover dispositivos de un objetivo que ya está causando daño? Una pausa limita la exposición nueva. Un rollback elimina el objetivo y devuelve los dispositivos a la versión estable de fallback en su próxima verificación de actualización.
Elige 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 equipo espacio para inspeccionar el señal sin agregar nuevos dispositivos al grupo de rollout.
Elige rollback cuando el objetivo es claramente peligroso para los usuarios, o cuando el equipo tiene suficiente evidencia de que el paquete conocido es seguro. Una pausa sola no elimina el objetivo malo de los dispositivos ya en el grupo de rollout. Si esos usuarios necesitan regresar a estable, el rollback es la acción que cambia su ruta de actualización.
El El canal CLI de referencia de Capgo listas controles de pausa y rollback separados. Trátalos como acciones diferentes, no dos nombres para el mismo freno de emergencia.
| Lo que ve | Acción inicial | Lo que verificar a continuación |
|---|---|---|
| Errores tempranos, alcance incierto | Pausa la rollout | Compare dispositivos afectados e inafectados |
| Fallas conocidas que afectan a la cohorte objetivo | Revertir la versión objetivo | Confirmar que la versión estable está activa |
| 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 compilación nativa o una reparación de servicio |
| Solo un pequeño grupo tiene la versión objetivo, sin 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 la versión de la web es la culpable, elija entre detener y revertir según cuántos usuarios necesitan alivio.
Step 3: Detener la exposición adicional mientras investigas
Detener cuando necesitas evitar que nuevos dispositivos entren en el grupo de lanzamiento, 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 se evita que el problema se propague a más usuarios.
Abra el canal de producción y verifique que está actuando en el lanzamiento afectado. Deténgalo con el panel de control, CLI, o API que su equipo utiliza. Luego, lea el estado del canal de nuevo. No confíe solo en que una orden se complete con éxito; confirme que el lanzamiento ahora se muestra como detenido.
En el modelo de lanzamiento progresivo de Capgo, los dispositivos ya en la cohorte pueden permanecer en el objetivo de lanzamiento después de un detención. Los dispositivos nuevos elegibles reciben la versión estable de fallback en su próxima verificación. Esa distinción importa: detener detiene la entrada nueva, pero no mueve la cohorte existente de nuevo a estable por sí mismo.
En segundo lugar, capture los detalles de la versión antes de hacer otro cambio. Registre el paquete objetivo, el canal, el momento de la detención y el primer informe conocido. Mantenga los detalles del dispositivo o sesión que su equipo está autorizado a recopilar. Una cronología clara le ayuda a comparar la cohorte de lanzamiento con dispositivos que aún están en el paquete estable.
Verifique el problema a través de un camino repetible. Si los usuarios informan un inicio de sesión fallido, pruebe ese viaje exacto en un dispositivo afectado. Si la aplicación se cae al iniciar, compruebe si el error de caída se alinea con el nuevo paquete y la versión nativa de la aplicación. Evite tratar cada informe de soporte como prueba de que la actualización causó el problema.
Establezca un propietario y un plazo para la investigación. Una pausa en la implementación puede quedar en limbo si nadie asume el próximo paso. El propietario debería reanudar después de que la evidencia aclare la versión de lanzamiento o elegir el rollback cuando el objetivo sigue siendo inseguro.
Consejo: Comuníquese con el equipo de soporte y la unidad de lanzamiento para informarles que la implementación está pausada. De lo contrario, un grupo puede seguir reportando incidentes mientras otro asume que la implementación ya ha sido revertida.
Por ahora, los dispositivos nuevos ya no deberían estar ingresando al conjunto de implementación. Verifique el estado del canal y el comportamiento de un dispositivo que no estaba en el conjunto de implementación antes de proceder con el rollback o la reanudación.
Paso 4: Retroceder cuando los usuarios necesitan una versión estable
Retroceder cuando los usuarios que ya están en la versión objetivo necesitan moverse hacia una versión conocida y segura. Esto es una 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.
En Capgo, abra el canal afectado y revise su historia de versiones. Elija la versión que desee restaurar, luego confirme que es la versión estable correcta para esta aplicación y canal. Capgo documentación de rollback describe el camino del panel de control y anota que los dispositivos reciben la versión seleccionada la próxima vez que buscan una actualización.
Después de retroceder, 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 del conjunto de implementación afectado.
Utilice el paquete integrado solo cuando ese es el objetivo de recuperación deseado. Puntúa los dispositivos hacia la construcción web empaquetada dentro de la aplicación nativa, que puede diferir del último paquete OTA. Verifique la compatibilidad y el impacto del usuario antes de elegirlo como su 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 los registros relevantes antes de la limpieza, especialmente si necesita entender por qué el problema escapó de la prueba.
Rollback is not the right fix for every failure. If the root cause is a server-side dependency, repair that service. If the change depends on native code absent from installed binaries, prepare a native build and follow the app store release path for that change.
Paso 5: Verificar la recuperación con análisis y comprobaciones de dispositivos
Después de una pausa o un rollback, verifique qué dispositivos están haciendo en lugar de tratar el cambio de control como prueba de recuperación. Verifique 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 Capgo live update de análisis pueden ayudarlo a inspeccionar métricas de adopción, tasas de errores y registros de dispositivo. Utilice esas señales para responder a preguntas específicas: ¿los dispositivos nuevos aún están recibiendo la versión objetivo, ¿los dispositivos afectados están buscando la versión estable del paquete, y ¿el error reportado se detuvo después de la recuperación?
Pruebe el camino del usuario que falló. Un descarga exitosa no prueba que la aplicación funcione. Abra la pantalla relevante, repita la acción que llevó al informe y verifique que la aplicación alcance el estado esperado. Si el incidente involucra un flujo crítico, tenga a alguien diferente a la persona que realizó el cambio que confirme el resultado.
Compare lo similar con lo similar. 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. Filtre por paquete, canal, versión de la aplicación y dispositivo donde estén disponibles. Busque una diferencia relacionada con la versión en lugar de culpar por defecto a la última actualización.
También verifique a los usuarios que no se han actualizado. Su presencia puede hacer que las métricas generales parezcan saludables mientras que el grupo afectado todavía ve el bug. Registre la participación de dispositivos en la versión objetivo frente a la participación en la versión estable, y mantenga los informes de soporte vinculados a la versión que los usuarios realmente están ejecutando.
Anote el resultado de la recuperación y la incertidumbre restante. Si los errores caen pero un puñado de usuarios siguen reportando el mismo problema, no cierre el incidente hasta que comprenda si están desconectados, en una caja de shell 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 de usuario fallido funciona en un dispositivo que podría 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.
Etapa 6: Evita incidentes repetidos con flujos de liberación más seguros
Antes de publicar, incluye la pausa y el rollback en el plan de liberación. El propietario de la liberación debe saber quién puede detener la exposición y quién puede aprobar un regreso a estable. Esto elimina un retraso común: esperar a una reunión mientras más dispositivos entran en la rollout.
Mantén asignada una caída estable mientras se prueba el objetivo de la rollout. Utiliza un pequeño grupo definido primero, luego amplía solo cuando los señales de salud acordadas permanezcan dentro de tus 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.
Coloca las comprobaciones de liberación en CI/CD, el proceso automático que ejecuta pruebas y despliega un cambio. Una canalización puede publicar el paquete en el canal deseado después de que las pruebas pasen. 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 automático. Para un flujo de OTA, mantén el punto de aprobación humano 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, una implementación de un comando puede publicar una 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 implementación. Eso ayuda al ingeniero de llamada en caso de emergencia a ver exactamente qué se envió sin adivinar en qué pista recibió el paquete.
Antes de habilitar las medidas de seguridad automáticas, defina qué señal los activa y qué acción toman. 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. Eos resultados difieren, por lo que no configuren uno como si fuera el otro.
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 paquete anterior. 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, la ruta de comando o la ruta de la consola, el estado esperado y la persona que confirma el éxito.
Las notas de liberación deben identificar el paquete y su propósito. Mantenga un enlace entre el registro de implementación y el cambio de origen para que los ingenieros puedan reducir la búsqueda cuando aparece un error. Si su equipo se encarga de 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 sistema, 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 propietario, 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
¿Detener un despliegue de Capgo detiene el despliegue de dispositivos actualizados?
No. Detener detiene a nuevos dispositivos elegibles de entrar en el despliegue, pero los dispositivos ya en la cohorte pueden permanecer en la versión objetivo. Para mover a esos usuarios hacia una versión estable, utilice el despliegue inverso o otra acción de canal deliberada. Verifique el estado del canal después de cualquiera de estos cambios, luego confirme el resultado en un dispositivo que recibió la versión objetivo.
¿Cuándo debería detener en lugar de desplegar hacia atrás?
Detener cuando el problema aún está bajo investigación y necesita detener la exposición más amplia. Desplegar hacia atrás cuando el objetivo es conocido que perjudica a los usuarios o cuando los dispositivos afectados necesitan una versión estable. La elección de detener el despliegue vs desplegar hacia atrás de Capgo depende de si la necesidad inmediata es contener o recuperar para la cohorte existente.
¿Actualizara una rollback a todos los dispositivos de inmediato?
No. Un despliegue hacia atrás cambia la versión a la que apunta el canal, pero los dispositivos la reciben cuando revisan la actualización. Un dispositivo que está desconectado puede permanecer en su versión actual hasta que se reconecte. Verifique el objetivo del canal, luego revise los dispositivos afectados y su estado de actualización antes de declarar el incidente resuelto.
Puede un rollback OTA solucionar un problema de aplicación nativa?
No. Una actualización de vuelta por OTA puede restaurar un paquete de web actualizable anterior, pero no puede agregar o eliminar nativos code dentro de un binario de aplicación instalada. Si el problema proviene de un plugin o cambio de capa nativa, evalúe si se necesita una nueva compilación nativa. Primero identifique qué capa causó el fallo.
¿Qué debo verificar después de pausar o retroceder?
Confirme el estado del canal y el paquete activo, luego verifique la adopción de actualizaciones y errores por liberación. Pruebe el recorrido del usuario que falló en un dispositivo del grupo afectado. También verifique 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 exposición nueva mientras investigas. Retrocede cuando los usuarios del objetivo necesitan una versión estable. Establezca ambos controles con anticipación, luego practíquelos en un canal de prueba antes de su próxima liberación de producción.
