# Publica actualizaciones sin sorpresas

- **URL canónica:** https://playbook.affpartners.io/es/apps/practices/quality-release/
- **Versión Markdown:** https://playbook.affpartners.io/es/apps/practices/quality-release/index.md
- **Módulo:** Calidad del producto
- **Tiempo:** 45 minutos antes del release

Un release seguro responde tres preguntas por adelantado: qué se revisará antes de publicar, quién vigilará las primeras señales y qué condición detendrá la distribución.

## Resultado

Una ficha de release de una página con las rutas de usuario afectadas, las revisiones, los responsables, las métricas y las condiciones de parada.

## Un release es una revisión controlada, no solo un botón de publicar

Hasta un cambio pequeño puede romper el inicio de sesión, la analítica o la ruta que viene de una notificación. Antes de publicar, el equipo acuerda qué rutas se ven afectadas, quién vigila las primeras horas y qué señal significa continuar, detenerse o revertir.

## Qué vas a necesitar

- **Build:** La build de release para iOS y Android, además de la versión anterior desde la tienda para probar la ruta de actualización.
- **Equipo:** Un responsable del release, un desarrollador móvil o ingeniero de QA y un contacto de soporte para la ventana de observación.
- **Ventana:** Al menos 60 minutos antes de publicar para las revisiones y las primeras 2 a 4 horas después del release para el monitoreo.

## Términos en lenguaje sencillo

- **Crash-free rate — La proporción de usuarios sin cierres inesperados de la app:** Definición: Cuanto más cerca del 100%, menos usuarios sufrieron un cierre inesperado de la app durante el periodo elegido. Ejemplo: Un 99,5% de usuarios crash-free significa que el 0,5% sufrió al menos un cierre inesperado.
- **ANR — Un bloqueo de una app de Android:** Definición: Android registra un ANR cuando la interfaz deja de responder al usuario durante demasiado tiempo. Ejemplo: El usuario toca un botón, la pantalla se congela y Android ofrece cerrar la app.
- **Analytics event — El registro de una acción concreta del usuario:** Definición: La app envía un evento cuando un usuario abre una pantalla, toca un botón o completa una acción. Ejemplo: registration_started y registration_completed muestran cuántas personas abandonan el registro.
- **Deep link — Un enlace a una pantalla concreta de la app:** Definición: Tras el toque, el usuario aterriza en la ruta prometida y no en la pantalla de inicio. Ejemplo: Un push sobre una lección guardada abre esa lección directamente.
- **Conversion — La proporción de personas que pasan al siguiente paso:** Definición: Muestra cuántas de las personas que empezaron un paso lo completaron o llegaron al siguiente. Ejemplo: 80 registros completados de 100 iniciados: 80 ÷ 100 × 100% = 80% de conversión.

## Cuándo aplicarla

Antes de cada actualización, sobre todo cuando cambian el registro, el almacenamiento de datos, las notificaciones, los deep links o una ruta clave del usuario.

## Qué abrir antes del release

Reúne los enlaces por adelantado. Cuando aparezca un problema, el equipo no debería estar buscando el dashboard correcto ni a la persona correcta en el historial del chat.

- **Lista de cambios**
  - **Fuente:** Toma las tareas del release y tradúcelas a rutas de usuario: inicio de sesión, registro, contenido, una operación, notificaciones, perfil.
  - **Si no hay acceso:** Si no hay lista de cambios, pide a cada desarrollador que diga en una frase su cambio y la pantalla que podría afectar.
- **Estabilidad y eventos**
  - **Fuente:** Prepara dashboards del crash-free rate, ANR, errores de API y eventos clave de la versión nueva de la app.
  - **Si no hay acceso:** Sin dashboard, asigna a alguien para revisar logs, cuentas de prueba y solicitudes de soporte a los 30, 60 y 120 minutos.
- **Canal de reacción**
  - **Fuente:** Define por adelantado el chat, la persona que decide y la forma de detener la distribución o publicar rápido un arreglo.
  - **Si no hay acceso:** Si revertir técnicamente no es posible, anota un plan seguro: pausar campañas, desactivar la función o avisar a los usuarios.

## Prepara el release en cinco pasos

1. **Traduce las tareas a rutas de usuario.** No te quedes en una lista de cambios técnicos. Di qué verá el usuario y qué ruta vecina podría romperse.
   - **Dónde hacerlo:** En la parte superior de la ficha de release, junto a la versión.
   - **Ejemplo:** Cambió la autorización → revisar el inicio de sesión, la restauración de sesión, la actualización desde la versión antigua y el deep link para un usuario sin sesión.
2. **Revisa la instalación limpia y la actualización.** Una instalación nueva y una actualización desde una versión antigua son escenarios distintos. Prueba los dos en iOS y Android con cuentas de prueba reales.
   - **Dónde hacerlo:** En la build de prueba y en la versión de la tienda.
   - **Ejemplo:** Después de actualizar desde 4.2 el usuario sigue con la sesión abierta; el historial y los ajustes se conservan.
3. **Recorre las acciones críticas.** Revisa el inicio de sesión, la primera acción útil, la operación clave, una notificación y el regreso desde segundo plano. Anota el hecho, no un «debería funcionar».
   - **Dónde hacerlo:** En una lista de verificación con la fecha, el dispositivo y el nombre de quien revisa.
   - **Ejemplo:** Android 13: el registro pasó 10 de 10 veces; el evento de finalización se ve en el reporte.
4. **Anota las condiciones de parada.** Antes de publicar, define la señal concreta que detiene la distribución. «Si se ve mal» no ayuda a nadie a decidir.
   - **Dónde hacerlo:** En la última columna de la ficha de release.
   - **Ejemplo:** Nos detenemos si la conversión de inicio de sesión en la versión nueva está más de 10% por debajo de lo normal o si empiezan a perderse sesiones.
5. **Asigna el monitoreo posterior al release.** Nombra al responsable, los intervalos de revisión y el canal de reacción. Soporte debe saber qué cambió y qué datos adjuntar a las solicitudes.
   - **Dónde hacerlo:** En el chat y en la ficha de release.
   - **Ejemplo:** Revisiones a los 30, 60 y 120 minutos; responsable: María; soporte adjunta la versión de la app y el ID del usuario.

## Ejemplos prácticos

- **Antes de publicar: la actualización desde 4.2:** QA actualiza la versión de la tienda y revisa que la sesión y el historial se conserven. Perder la sesión o los datos es una condición de parada escrita de antemano, no algo para discutir después del lanzamiento.
- **Después de publicar: puntos de control:** El responsable del release observa el crash-free rate, los errores de inicio de sesión y la conversión de la acción clave a los 30, 60 y 120 minutos; soporte adjunta la versión de la app a cada solicitud nueva.

## Artefacto final: Ficha de control del release 4.3

Una fila por revisión. El responsable, el hecho observado y la condición de parada van justo al lado.

| Revisión | Responsable | Resultado esperado | Condición de parada |
| --- | --- | --- | --- |
| Actualización desde 4.2 | QA | Sesión y datos conservados | Pérdida de sesión o de datos |
| Registro limpio | iOS/Android | El código y el perfil funcionan | Éxito por debajo del 95% en las pruebas |
| Acción clave | Product manager | El evento y el resultado se ven | Caída de conversión >10% |
| Deep link desde un push | Especialista de CRM | Se abre la pantalla correcta | El enlace lleva a un error |
| Primeras 2 horas | Responsable del release | Crash-free en el rango normal | Subida fuerte de cierres inesperados o ANR |

La decisión la toma el responsable del release. Ante una señal de parada, el equipo detiene la distribución, anota la hora y la versión, avisa a soporte y elige entre revertir o hacer un arreglo urgente.

## Lista de verificación del release

No marques puntos por adelantado. Cada revisión necesita un hecho: dispositivo, hora, resultado o enlace al dashboard.

- [ ] Los cambios están traducidos a rutas de usuario claras.
- [ ] La instalación limpia y la ruta de actualización se probaron en iOS y Android.
- [ ] Las acciones críticas, los eventos de analítica y los deep links funcionan.
- [ ] Están anotadas las condiciones de parada y un plan de reacción seguro para las métricas clave.
- [ ] Están asignados un responsable del release, los intervalos de monitoreo y un contacto de soporte.

## Qué observar después del release

- **Estabilidad:** El crash-free rate, el ANR y los errores de API de la versión nueva se mantienen en el rango normal.
- **Ruta clave:** El inicio de sesión, el registro y la acción principal no rinden peor que en la versión anterior.
- **Señales en vivo:** Soporte y las reseñas no muestran ningún problema nuevo recurrente en las primeras 72 horas.

## Regla principal

Si el equipo no sabe quién detiene la distribución ni ante qué señal, el release no está listo para publicarse.

## Crece con GameChange Partners

[Explorar el programa de afiliados ↗](https://gamechange.partners/es?utm_source=academy&utm_medium=referral&utm_campaign=gcpacademy)

---

- [Versión HTML](https://playbook.affpartners.io/es/apps/practices/quality-release/)
- [Todas las prácticas](https://playbook.affpartners.io/es/apps/)