El rollback es una operación de recuperación que revierte un cambio de software o configuración para restaurar un estado anterior estable. En Kubernetes, el historial de despliegue mantiene 10 ReplicaSets antiguos por defecto, mientras que PostgreSQL ROLLBACK descarta las actualizaciones de la transacción actual, no los datos confirmados previamente.
Un release sale a producción, los primeros usuarios abren la app y los tickets de soporte llegan antes de que el equipo termine de celebrar. Una pantalla de checkout falla, una nueva respuesta de API rompe un cliente antiguo, o un cambio de configuración desvía las peticiones. El equipo necesita restaurar el servicio sin adivinar qué archivos cambiaron ni pedir a cada usuario que reinstale.
Para eso sirve el rollback. No es prevención ni un botón de deshacer mágico. El nuevo release ya se aplicó. El rollback es la respuesta controlada cuando ese release causa errores, degradación de rendimiento, crashes o comportamientos inseguros. En la práctica, suele redeployar la versión anterior de la app o restaurar una configuración versionada, verificando que el servicio haya vuelto a un estado aceptable. El técnicas de análisis de fallos lo que tu equipo haga después sigue siendo importante, porque el rollback estabiliza el incidente pero no explica su causa.
Table of Contents
- La realidad de los fallos en el despliegue
- Cómo los sistemas modernos preservan el historial de releases
- El peligro oculto de revertir bases de datos y datos
- La decisión operativa de revertir
- Recuperación instantánea en apps móviles y cross-platform
- Construyendo una estrategia de release resiliente
- Claves para despliegues más seguros
La realidad de los fallos en el deployment
Un equipo móvil lanza un nuevo bundle con un cambio de navegación y una actualización de compatibilidad con el backend. Primero lo recibe la audiencia en staging. En minutos, los usuarios reportan que una pantalla principal no carga. El monitoreo muestra un aumento de errores, pero el equipo aún no sabe si el problema viene del bundle, del API, de un feature flag o de una dependencia.
La respuesta segura no es debatir el diagnóstico perfecto mientras crece la audiencia afectada. Si el equipo tiene un artefacto conocido como estable, puede detener el rollout y restaurar esa versión. La aplicación vuelve a un estado validado previamente mientras los ingenieros investigan el defecto y preparan una corrección.
El rollback es recuperación, no prevención
Prevención busca detener un cambio erróneo antes de que llegue a los usuarios. Los tests, la revisión de code, los checks de dependencias, los canary releases y los gates de aprobación sirven para eso. El rollback comienza cuando la prevención falla o tras aparecer una interacción inesperada en producción.
Un rollback puede afectar varias partes de un sistema de entrega:
- code de la aplicación: Redesplegar el ejecutable o el web bundle anterior.
- Configuración: Restaura una configuración, regla de enrutamiento o feature flag versionada.
- Assets: Volver a imágenes, scripts o archivos de contenido compatibles.
- Exposición de features: Desactiva una nueva funcionalidad mediante un kill switch o control de audiencia.
- Datos: Aborta una transacción activa o restaura datos desde un backup, sujeto a restricciones mucho más estrictas.
La última categoría requiere un tratamiento aparte. Revertir el code de la aplicación suele ser sencillo si los artifacts son inmutables y las dependencias siguen siendo compatibles. Revertir datos confirmados puede causar pérdida, corrupción o problemas regulatorios. Por tanto, un rollback de una release no debería implicar que cada operación de base de datos relacionada pueda retroceder de forma segura.
Por qué la entrega frecuente requiere una recuperación rápida
La continuous delivery moderna hace que las releases sean más frecuentes. Esto crea un requisito práctico: el coste operativo de un cambio fallido debe mantenerse limitado. Un equipo que puede desplegar rápido pero necesita un proceso manual largo para recuperarse solo ha optimizado la mitad del delivery.
La reversión manual sigue siendo posible, pero depende de que los operadores recuerden qué archivos cambiaron, qué servidores se actualizaron y qué configuración pertenecía a la release anterior. Ese proceso se vuelve frágil durante un incidente. Los sistemas automatizados mejoran el flujo al mantener artifacts inmutables, monitorizar señales de salud y revertir cuando se cumplen condiciones predefinidas.
Regla práctica: Trata el rollback como una capacidad de producción ensayada, no como un botón de emergencia que alguien tendrá que descifrar durante la caída.
Un rollback tampoco es una solución permanente. Restaura el servicio temporalmente, pero el defecto subyacente persiste. Los ingenieros aún deben identificar el desencadenante, evaluar los datos escritos durante el release fallido y lanzar una versión corregida o tomar otra decisión operativa deliberada.
Cómo los sistemas modernos preservan el historial de releases
Un sistema de recuperación solo puede restaurar lo que puede identificar y recuperar. Mantener un commit antiguo de la fuente no es suficiente si el build se produjo con dependencias con drift, si el binario fue sobrescrito o si el native shell ya no soporta el bundle.
Los sistemas de release modernos resuelven esto preservando una cadena de evidencia desde el código fuente hasta el artefacto desplegado. El equipo etiqueta una revisión estable, bloquea el grafo de dependencias, genera un artefacto direccionable y registra qué artefacto llegó a cada entorno. Ese registro le da a los operadores un objetivo específico en lugar de una instrucción ambigua como “vuelve a la versión anterior”.
Kubernetes como modelo concreto
Kubernetes ilustra la estructura claramente. Un Deployment controla los ReplicaSets, y esos ReplicaSets preservan las revisiones del despliegue. Kubernetes retiene 10 ReplicaSets antiguos por defecto, y los equipos pueden cambiar esa retención con spec.revisionHistoryLimit. Establecer el valor en 0 desactiva el rollback por completo, tal como se documenta en la Referencia de Kubernetes Deployment.
Un operador puede volver a la revisión inmediatamente anterior o seleccionar una revisión histórica exacta. El rollback cambia la configuración del Pod-template del Deployment, incluyendo campos como la imagen del contenedor y las labels. No revierte automáticamente campos no relacionados, como el número de réplicas. Después, los checks de rollout-status confirman si la revisión objetivo está saludable.
Esa distinción es clave para la entrega de bundles móviles y web. Un sistema debería registrar:
- La versión activa: Qué release recibió cada entorno, channel o dispositivo.
- La identidad del artifact: Un build inmutable o direccionable por contenido, no un archivo que pueda reemplazarse in situ.
- Compatibilidad de dependencias: Si el bundle anterior funciona con el native shell, APIs, servicios y esquema de datos actuales.
- El resultado de la recuperación: Si los dispositivos o instancias adoptaron con éxito el release restaurado.
“Previous” debe referirse a un artifact específico
Una etiqueta como previous es útil solo si apunta a un release inmutable. Si un equipo sobrescribe el archivo de esa etiqueta, el objetivo de recuperación puede cambiar sin que nadie lo note. Si el artefacto ha expirado del almacenamiento, el sistema de deployment puede conocer el número de revisión pero carecer de los bytes necesarios para restaurarlo.
Para una aplicación Capacitor, el web bundle también se ejecuta dentro de un native shell. Un bundle de JavaScript anterior puede depender de plugins nativos, permisos o comportamientos del bridge que el shell actual haya cambiado. Restaurarlo sin verificar la compatibilidad puede cambiar un incidente por otro.
El Enfoque de Capgo para control de versiones y rollbacks refleja un principio fundamental: el historial de releases debe ser explícito, recuperable y estar conectado a la audiencia que recibió cada build. Un rollback tiene éxito cuando el equipo puede responder tres preguntas rápido: ¿qué estaba activo?, ¿qué era estable? y ¿qué puede ejecutarse de forma segura con el sistema actual?
El peligro oculto de revertir bases de datos y datos
Un deployment fallido puede dejar al equipo con una instrucción urgente: “Solo restaura la versión anterior”. Eso puede funcionar para un code ejecutable, pero puede ser inseguro para una base de datos, donde la actividad de los clientes ya confirmada podría ser imposible de revertir limpiamente.
El rollback de la aplicación y el rollback de datos son operaciones distintas con diferentes modos de fallo. Un release de code a menudo puede sustituirse por otro artefacto inmutable. Una migración de esquema puede haber renombrado o eliminado un campo, transformado valores almacenados o cambiado las premisas de escrituras posteriores. Pedidos, pagos, mensajes, registros y consentimientos son datos de usuario válidos. No deberían desaparecer porque un release de la aplicación falló.
Por qué code y el esquema pueden desincronizarse
Supongamos que el release A entiende el esquema antiguo, mientras que el release B añade una columna o cambia cómo se almacena un valor. Tras desplegar B y ejecutar su migración, restaurar A puede hacer que la antigua consulta de code busque campos que ya no existen o interprete mal los nuevos datos.
Lo contrario genera un fallo distinto. Revertir la base de datos mientras los procesos del release B siguen activos puede causar fallos en las escrituras o dejar un estado parcial. Revertir tanto code como la base de datos puede parecer más limpio, pero puede borrar actividad legítima creada tras el despliegue. La distinción entre rollback de aplicación y rollback de datos debe estar en cada plan de release, no solo en las operaciones de base de datos.
PostgreSQL muestra lo que hace un rollback transaccional. ROLLBACK aborta la transacción actual y descarta las actualizaciones realizadas en ella, para que un grupo de escrituras parcialmente aplicadas no sea persistente. No puede deshacer cambios confirmados por una transacción anterior. Ejecutarlo ROLLBACK fuera de un bloque de transacción no revierte los datos almacenados.
Diseña migraciones para avanzar
Un diseño de release seguro mantiene la compatibilidad entre versiones de la app y cambios de esquema durante la transición. Los equipos también deben documentar prácticas de cifrado de SQLite para apps Capacitor junto con la compatibilidad de esquemas, controles de acceso y procedimientos de recuperación.
Una migración de tipo expand-and-contract suele seguir esta secuencia:
- Expand: Añade la nueva capacidad al esquema sin eliminar la anterior.
- Adopt: Despliega code que pueda leer y escribir en ambas representaciones, o introduce la nueva ruta manteniendo la antigua.
- Migrate: Mueve los registros existentes mediante un proceso controlado, con monitoreo y conciliación.
- Contract: Elimina la estructura antigua solo cuando las versiones dependientes ya no la requieran.
Esta secuencia hace que un rollback de code sea más viable, ya que la versión anterior de la app aún puede usar un schema que respete su contrato. No garantiza que todo rollback sea seguro, pero reduce la probabilidad de que la recuperación introduzca una nueva incompatibilidad.
Los sistemas de fintech, healthcare y e-commerce también requieren auditabilidad, controles de privacidad, gestión de estados de pago y un plan de conciliación. Un forward fix puede ser más seguro que revertir transacciones válidas o restaurar un snapshot que elimine actividad reciente de los usuarios.
Regla de base de datos: Realiza un rollback de code libremente solo cuando sus dependencias y su contrato de datos lo permitan. Trata los datos confirmados como un registro de avance continuo, a menos que un procedimiento de restauración probado demuestre lo contrario.
Antes del deployment, clasifica cada componente del release según su reversibilidad. Code, la configuración, la exposición de features, los assets, el schema y los datos de usuario siguen reglas de recuperación distintas. Un backup probado ayuda tras una corrupción catastrófica, pero restaurar un backup no sustituye un diseño de migración con backward compatibility.
Tomar la decisión operativa de revertir
El rollback es una decisión operativa, no solo un comando de deployment. Alguien debe decidir si el problema detectado proviene del release, si el estado anterior es seguro, si hay suficientes usuarios afectados para justificar la reversión y si un forward fix reduciría el riesgo de forma más efectiva.
DORA trata la tasa de fallos en cambios como despliegues que requieren intervención inmediata, a menudo un rollback o hotfix, y rastrea por separado el tiempo de recuperación de despliegues fallidos. Esto convierte al rollback tanto en un evento de fiabilidad como en un resultado de rendimiento de entrega, tal como se describe en la historia de las métricas DORA.
Define el trigger antes del incidente
Los buenos equipos acuerdan las condiciones de rollback mientras se diseña el release. Un trigger puede combinar señales de crash, tasas de error, fallos en health checks, reportes de soporte o una comparación canary. Un evento aislado no debería necesariamente revertir un release, pero un patrón claro en la audiencia monitoreada debe tener una respuesta definida.
El rollback automático es adecuado solo cuando el fallo es bien comprendido, reversible y observable mediante señales fiables. Un sistema automatizado que responda a cada anomalía puede empeorar un incidente al oscilar entre versiones, ocultar el fallo subyacente o reintroducir repetidamente una dependencia incompatible.
Para una aplicación móvil, la decisión requiere contexto adicional:
- Usuarios offline: Algunos dispositivos no buscarán actualizaciones de inmediato.
- Versiones mixtas: Los clientes antiguos y nuevos pueden coexistir durante mucho tiempo.
- Exposición escalonada: Un channel o canary puede revelar un problema antes que producción.
- Compatibilidad nativa: El web bundle restaurado debe funcionar con el shell instalado.
- Efectos en los datos: Un rollback de code podría no revertir las escrituras ya aceptadas por el backend.
Rollback vs. roll-forward
El rollback restaura un estado anterior. El roll-forward lanza un cambio correctivo. Ninguno es universalmente más seguro.
El rollback suele encajar para defectos de presentación reversibles, una mala configuración o un release que falla antes de alterar el estado persistente. El roll-forward puede ser más seguro si la migración ya se ejecutó, los usuarios han creado registros válidos o la versión anterior de la app no soporta el esquema actual. Un kill switch puede ser aún más seguro si la funcionalidad defectuosa se puede aislar sin reemplazar todo el release.
El runbook debe nombrar al incident commander, a la persona autorizada para ejecutar la acción, las señales de salud que confirmen el éxito y la vía de comunicación para producto y soporte. También debe indicar cuándo el equipo deja de intentar revertir y comienza a aplicar un fix forward.
Un runbook útil registra:
- La revisión de destino y la ubicación de su artifact.
- Las comprobaciones de compatibilidad para clientes nativos, servicios, dependencias y esquemas.
- El control del radio de impacto, como un canal, cohorte o canary.
- Los criterios de éxito, incluyendo señales de recuperación e impacto en usuarios.
- El responsable del seguimiento, encargado del release corregido y la revisión del incidente.
El la diferencia entre pausar un rollout y hacer un rollback es clave a nivel operativo. Pausar limita la exposición. El rollback cambia activamente lo que reciben los usuarios afectados. Los equipos deben saber qué acción necesitan antes de elegir una.
Recuperación instantánea en apps móviles y multiplataforma
La recuperación tradicional en lanzamientos móviles depende de la distribución de las app-stores. Si el error está en el binario nativo, el equipo debe preparar un binario corregido o anterior, enviarlo a la tienda correspondiente y esperar a que llegue a los usuarios. Ese proceso es adecuado para cambios nativos, pero genera fricción cuando el error se limita a JavaScript, CSS, configuración, copy o assets web.
La entrega over-the-air cambia la ruta de recuperación para esos cambios en la capa web. Un sistema live update puede publicar un bundle firmado a una audiencia controlada, permitir que los dispositivos lo apliquen en el próximo inicio o comprobación de actualización, y conservar el bundle anterior como fallback. No elimina la necesidad de revisión en la tienda cuando cambian los code nativos o los permisos de la plataforma, y no hace que el rollback de datos sea seguro.
La distribución en tiendas y los live updates resuelven problemas distintos
| Necesidad de recuperación | Lanzamiento de binario vía tienda | live update firmado |
|---|---|---|
| Cambio de plugin nativo o de permisos | Adecuado | No es un reemplazo |
| Defecto en JavaScript o CSS | Ruta de recuperación más lenta | Apto cuando la política y la compatibilidad lo permiten |
| Control de audiencia | Canales de la Store y controles de rollout | Canales segmentados y entrega escalonada |
| Objetivo de recuperación | Binario publicado | Web bundle versionado |
| Dependencia principal | Distribución en tiendas | Updater, firma, compatibilidad y observabilidad |
Una plataforma como Capgo soporta Capacitor live updates entregando web bundles firmados a canales específicos, manteniendo el historial de versiones, aplicando actualizaciones en el siguiente inicio o check, y ofreciendo protección de rollback si un nuevo bundle falla los health checks. La entrega diferencial permite enviar solo archivos cambiados, mientras que los canales separan audiencias de beta, staging, producción o clientes específicos. Estas funciones ayudan a reducir el impacto de un release fallido en la capa web, pero no eliminan la necesidad de validar la compatibilidad con el native-shell o los contratos de datos del backend.
El fallback automático requiere una señal de salud fiable
Un updater no debería marcar un bundle como saludable solo porque la descarga terminó. Debe distinguir entre la descarga, la instalación, el lanzamiento y la salud real de la aplicación. Si el nuevo bundle falla o no pasa los health checks en el siguiente inicio, el dispositivo puede volver a la última versión estable sin descargar un binario completo de la app store.
Esa recuperación tiene límites. El dispositivo puede estar offline, la actualización fallida puede haber cambiado datos en el servidor, o el bundle anterior puede ser incompatible con el native shell instalado. Los logs por dispositivo y los datos de adopción de versiones ayudan a soporte a determinar qué usuarios recibieron qué bundle y si el fallback funcionó.
El Guía de configuración de rollback de actualizaciones de Capacitor debe acompañar a una política de release, no reemplazarla. Firma cada artefacto, restringe quién puede publicar en canales de producción, preserva la versión de fallback y prueba el flujo de error en dispositivos reales. La distribución rápida solo es valiosa si el sistema puede probar que el bundle restaurado es el correcto.
Construyendo una estrategia de release resiliente
La preparación para el rollback es una propiedad de todo el sistema de release. Un build antiguo en object storage no ofrece protección real si el equipo no puede identificar sus dependencias, no sabe qué dispositivos lo adoptaron o nunca ha probado la recuperación con datos similares a producción.
Empieza con la cadena de artefactos. Etiqueta estados de código estables, bloquea dependencias, preserva builds firmados y nunca sobrescribas un release publicado. Luego, conecta cada artefacto a un entorno, canal y evento de despliegue. El equipo debe poder reconstruir lo ocurrido sin depender de la máquina local de un desarrollador.
Cuatro controles para reducir el riesgo de recuperación
- Artefactos inmutables: Almacena cada bundle de producción bajo una identidad única. Un puntero de "versión anterior" puede seleccionar un release, pero no debe mutar el release en sí.
- Migraciones compatibles: Usa técnicas de expand-and-contract para que versiones antiguas y nuevas de la app puedan coexistir durante una transición controlada.
- Automatización protegida: Automatiza el fallback solo para señales que distingan un fallo real del release de un problema de servicio transitorio.
- Validación de dependencias: Verifica el native shell, plugins, APIs, servicios y el esquema antes de permitir que una revisión objetivo se active.
La observabilidad cierra el ciclo. Captura la versión por dispositivo, el resultado del launch, el estado de la update, el motivo del fallo y el estado de adopción. Esos registros permiten a soporte saber si un usuario sigue en el bundle fallido, ya recibió el fallback o nunca descargó la update.
Los equipos deben ensayar la ruta de recuperación con datos reales y versiones de clientes mixtas. Una prueba que restaure code contra una base de datos de desarrollo vacía puede ignorar incompatibilidades causadas por registros reales, variantes de esquema antiguas, escrituras en cola y migraciones incompletas. Las pruebas de recuperación también deben verificar la autorización, la firma, la recuperación de artefactos, el targeting de canales y el plan de comunicación.
La recuperación no se mide por la existencia de un build antiguo. Se mide por la precisión con la que el equipo puede controlar el impacto y restaurar un estado compatible.
La planificación de lanzamientos debe incluir responsables explícitos para la coordinación de dependencias. Los equipos que necesiten un framework más amplio para gestionar dependencias en entornos agile pueden usar esa disciplina de planificación para alinear cambios en mobile, backend, base de datos y producto antes del deployment.
Una revisión de preparación práctica pregunta:
- ¿Puede el equipo identificar el artefacto exacto activo en cada canal?
- ¿Puede pausar la exposición sin cambiar el code ya instalado?
- ¿Puede restaurar un bundle firmado y compatible?
- ¿Puede demostrar que la base de datos sigue segura tras un rollback de la aplicación?
- ¿Puede detectar fallos por versión en lugar de solo a nivel de servicio agregado?
- ¿Puede optar por un roll-forward cuando una reversión dañaría datos válidos?
Si alguna respuesta no es clara, el proceso de release tiene un vacío de recuperación. Corregir ese vacío antes del próximo incidente es más barato que improvisar mientras los usuarios esperan.
Claves para despliegues más seguros
Un rollback revierte un cambio de software o configuración aplicado para restaurar un estado conocido y estable. No evita defectos, no repara la causa subyacente ni deshace automáticamente cambios confirmados en la base de datos.
Mantén los artefactos de la aplicación inmutables y direccionables. Rastrea la versión activa, dependencias, compatibilidad con el shell nativo y el público de cada release. Trata las migraciones de esquema y los datos de usuario como objetivos de recuperación separados, porque un rollback de code puede dejar la base de datos modificada y un rollback de base de datos puede destruir registros válidos.
Usa entregas escalonadas, señales de salud fiables, autorización explícita y un runbook probado. Para equipos móviles, los bundles over-the-air firmados pueden permitir una recuperación rápida en cambios compatibles de la capa web, mientras que los cambios nativos siguen requiriendo su ruta de release de binarios. Mide la recuperación por la reducción del blast radius y la restauración verificada del servicio, no por la presencia de un build antiguo.
Capgo ofrece a los equipos de Capacitor y Electron bundles de live-update firmados, canales segmentados, historial de versiones, observabilidad por dispositivo y protección de rollback para releases compatibles de la capa web. Revisa tu ruta de recuperación actual y mira cómo Capgo puede ayudarte a pausar la exposición, restaurar un bundle estable y mantener el control durante la respuesta a incidentes.
