Día de lanzamiento en el desarrollo de aplicaciones: qué es, etapas y preparación
El día de lanzamiento (release day) es la fecha programada para publicar una nueva versión de una aplicación móvil, que incluye la preparación del build, la revisión de la tienda, el staged rollout y el monitoreo. Para aplicaciones iOS, el proceso comienza con la carga del build en App Store Connect entre 24 y 48 horas antes de la fecha de lanzamiento planificada debido a la revisión obligatoria de Apple. Para Android, el build se compila y se sube a Google Play Console, donde el proceso de revisión suele tardar de 1 a 4 horas. Según Apple Developer Guidelines (2025), el 90% de los builds pasan la revisión en 24 horas. Staged rollout permite minimizar el impacto si se detectan errores después de la publicación.
Puntos clave
- Release day — conjunto de actividades desde la compilación del build hasta el monitoreo posterior al rollout
- Staged rollout — despliegue gradual: 1%, 10%, 50%, 100%
- Smoke testing — verificación final del build antes de enviarlo a la tienda
- Rollback plan — escenario de reversión preparado de antemano para errores críticos
- Release retrospective — análisis del proceso tras completar el rollout al 100%
Qué es el día de lanzamiento y cómo prepararse
El día de lanzamiento no es solo el momento de pulsar el botón Publicar. Es un proceso coordinado en el que participan desarrolladores, QA, DevOps, gestores de producto y, a veces, el equipo de soporte. La preparación comienza 2–3 semanas antes del día del lanzamiento: acordar el alcance, code freeze, pruebas de regresión, preparar notas de la versión y materiales de marketing. Cuanto más minuciosa sea la preparación, más tranquilo transcurrirá el día del lanzamiento.
La lista de verificación para la preparación del día de lanzamiento incluye: ejecución final de QA (suite de regresión + smoke) sobre el build de lanzamiento; verificación de metadatos en las tiendas (nombre, descripción, capturas de pantalla, keywords); acuerdo sobre el porcentaje de staged rollout con el gestor de producto; preparación del plan de rollback (qué tag redeploy, cuánto tiempo tomará); notificación al equipo y servicios relacionados sobre el próximo lanzamiento. Release checklist debe estar automatizado mediante CI/CD — por ejemplo, como un workflow de GitHub Actions que verifique todos los puntos antes de crear el tag de lanzamiento.
Un elemento importante de la preparación es el blackout period (período en el que los deploys a producción están prohibidos). Normalmente, el blackout se introduce 48 horas antes del día de lanzamiento y se levanta 24 horas después de un rollout exitoso al 100%. Change freeze durante el período de blackout se aplica a todos los servicios relacionados con el lanzamiento.
Preparación del build: code freeze, etiquetado y compilación
Entre 24 y 48 horas antes del día de lanzamiento se introduce un code freeze — una parada completa de los cambios en el código. Los desarrolladores se centran en preparar documentación y notas de la versión. DevOps compila el build de lanzamiento a partir de un tag fijado (por ejemplo, v2.6.0-rc1). El build pasa por una suite completa de regresión (pruebas automáticas + manuales). Si se encuentran errores críticos, se corrigen antes del code freeze o se pospone el lanzamiento. Release candidate (RC) — un build que ha pasado QA y está listo para enviarse a la tienda.
Etiquetado en Git: se crea un tag anotado (git tag -a v2.6.0 -m “Release v2.6.0”). El pipeline de CI/CD compila un AAB (Android App Bundle) para Google Play y un IPA (iOS App Store Package) para Apple App Store. El build se acompaña de: un archivo de sumas de verificación (SHA256), un changelog y una lista de problemas conocidos (known issues). Reproducible builds — una práctica ideal en la que recompilar desde el mismo tag produce un resultado binariamente idéntico.
bash
# Release pipeline — creación de tag y compilación
# Asume que el code freeze ya está activo
# Crear rama de release desde develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: las reglas de protección de ramas bloquean nuevos PRs
# Ejecutar suite de regresión en CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Crear tag de release después de QA exitoso
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Compilar binario de release mediante CI/CD
# fastlane build_release produce AAB + universal APK
fastlane build_releaseImportante: el version bump (actualización de version code y version name) se realiza antes del code freeze. Después del code freeze, la versión no cambia. Para Android: versionCode — un número entero que aumenta de forma monótona; versionName — versión semántica (2.6.0). Para iOS: CFBundleVersion (build number) y CFBundleShortVersionString (semantic version). Versioning debe estar automatizado en gradle/xcconfig.
Carga en la tienda y proceso de revisión
Para iOS: el build se sube mediante Xcode, Transporter o fastlane a App Store Connect. Después de la carga, el build pasa por una verificación automática de Apple (processing) y luego se envía a una revisión manual. El tiempo medio de revisión es de 24 horas, pero puede variar de 1 hora a 7 días según la carga de trabajo de los revisores de Apple y los requisitos de compliance. Expedited review — una solicitud de revisión acelerada para correcciones de errores críticos (disponible como máximo una vez al mes, no garantizada).
Para Android: el build se sube a través de Google Play Console. Google utiliza un enfoque combinado: pruebas automatizadas (accesibilidad, malware, cumplimiento de políticas) + revisión manual selectiva. El tiempo medio de revisión es de 1 a 4 horas. Internal test track y Closed track permiten realizar pruebas finales antes de la publicación en Production track. Recomendación: 1–2 días en Internal test → 1 día en Closed beta → rollout gradual en Production.
Para ambas plataformas, es crítico verificar los metadatos antes de subir el build: nombre de la aplicación, descripción (corta + completa), capturas de pantalla para cada dispositivo compatible (iPhone 6.5″, 5.5″, iPad, Android phone, tablet), keywords (iOS) o experiments de store listing (Android). Un error en los metadatos puede retrasar la revisión un día adicional. App metadata debe estar localizada en todos los idiomas compatibles.
Staged rollout: cómo desplegar un lanzamiento sin riesgos
El staged rollout (despliegue gradual, despliegue por fases) es una estrategia en la que una nueva versión se pone a disposición de los usuarios de forma progresiva, no de inmediato. Un esquema típico para un equipo maduro: 1% de usuarios (primeras 2–4 horas) → 10% (24 horas) → 25% (24 horas) → 50% (24 horas) → 100%. Cada etapa incluye monitoreo de métricas y verificación de ausencia de errores críticos. Staged rollout es la herramienta principal para minimizar el riesgo durante los lanzamientos.
Google Play Console ofrece un staged rollout integrado: se puede especificar un porcentaje de usuarios y programar aumentos graduales. Para iOS App Store Connect no existe esta funcionalidad integrada — el staged rollout se implementa mediante Phased Release (aumento automático de cobertura durante 7 días con posibilidad de pausa) o mediante feature flags en el servidor con geodistribución. Phased release en App Store Connect permite pausar el lanzamiento si se detectan problemas.
Métricas clave para pasar a la siguiente etapa: crash-free rate (≥99.9% para el nuevo lanzamiento), tasa de ANR (Android, ≤0.1%), tasa de error en API backend (≤0.5% 5xx), valoraciones de usuarios (no inferiores a la versión anterior), apdex score (≥0.94). Si alguna métrica supera el umbral, el rollout se pausa hasta determinar las causas. Go/no-go gate en cada etapa es responsabilidad del release manager o del ingeniero de guardia.
Monitoreo posterior al lanzamiento: qué observar en las primeras horas
Las primeras 4 horas tras el lanzamiento son el momento más crítico. El equipo monitorea la tasa de crashes (Sentry, Firebase Crashlytics, App Center), la tasa de error 5xx en el backend, eventos personalizados (pagos exitosos, inicios de sesión, registros), valoraciones en App Store y Google Play, y menciones en redes sociales (Twitter, Reddit). El dashboard de monitoreo debe estar preparado con antelación y disponible en una pantalla grande en la oficina o en un canal de Slack dedicado. Release dashboard — un panel único para todas las métricas del lanzamiento.
Atención especial a las métricas de regresión: comparar la tasa de crashes con la versión anterior en un período similar. Si la tasa de crashes ha aumentado más de un 0.1%, es una señal de alerta que requiere análisis inmediato. También es importante comparar la latencia mediana y p95 de los endpoints clave de API: incluso sin crashes, un aumento de 200ms en el tiempo de respuesta puede indicar un problema. Metric comparison (baseline vs actual) se automatiza en Datadog o Grafana.
Los comentarios de los usuarios son tan importantes como las métricas numéricas. En las primeras horas tras un lanzamiento, los usuarios dejan activamente reseñas en las tiendas y escriben al soporte. Los errores no detectados por las pruebas salen a la luz rápidamente en las reseñas. El líder del equipo o un ingeniero de QA designado monitorea las reseñas cada 30 minutos durante las primeras 4 horas y las clasifica: falso positivo, problema conocido (ya en la lista de known issues), nuevo error. New bugs P0/P1 — un desencadenante para pausar el rollout.
Rollback: cuándo y cómo revertir un lanzamiento
Rollback es la reversión a una versión estable anterior cuando se descubren problemas críticos. La decisión de hacer rollback la toma el release manager junto con el tech lead si: la tasa de crashes del nuevo lanzamiento cae por debajo del 99%, se detecta una fuga de datos, la funcionalidad crítica (pagos, autorización) no funciona para más del 5% de los usuarios, o la tienda (App Store Review) rechazó el build tras su publicación. Rollback trigger debe definirse antes del lanzamiento para que la decisión se base en hechos, no en emociones.
Para Android: el rollback en Google Play Console consiste en detener el staged rollout y cambiar a la versión anterior. Si el build actual ya está al 100% de los usuarios, publicar la versión anterior como un nuevo lanzamiento. Para iOS: a través de App Store Connect — Phased Release → Pause Release → publicar una nueva versión con la corrección (App Store no permite revertir a una versión anterior). iOS rollback es más complejo: el desarrollador debe compilar un nuevo build con revert commits y pasar la revisión nuevamente.
Después de un rollback, el equipo entra en modo de incidente: análisis de causa raíz, hotfix o siguiente lanzamiento con la corrección, post-mortem. El rollback no es un fallo, sino un procedimiento estándar. Los equipos que nunca han hecho un rollback probablemente no están detectando problemas, no es que publiquen lanzamientos sin errores. Rollback rate es una de las métricas DORA: los equipos de alto rendimiento hacen rollback en menos del 10% de los lanzamientos y se recuperan en menos de 1 hora.
Preguntas frecuentes
¿Qué día es mejor para lanzar una aplicación móvil?
Los mejores días son martes, miércoles o jueves. El lunes tiene alto tráfico del fin de semana, y el viernes conlleva el riesgo de entrar al fin de semana con un lanzamiento problemático. Evita el viernes: si se descubre un problema tras el despliegue, el equipo estará corrigiéndolo durante el fin de semana o esperando hasta el lunes.
¿Qué hacer si App Store Review rechaza el build?
Leer el motivo del rechazo en el Resolution Center, corregirlo y volver a subir el build. Causas frecuentes: enlaces rotos, campos incompletos, contenido sin suscripción (si se requiere), capturas de pantalla desactualizadas. App Review rejection retrasa el lanzamiento entre 24 y 48 horas, por lo que la primera carga del build debe hacerse 3–5 días antes de la fecha de lanzamiento planificada.
¿Qué porcentaje de staged rollout es óptimo para empezar?
Para lanzamientos importantes (cambios mayores) — 1%. Para lanzamientos de parche — 5–10%. La primera etapa debe ser lo suficientemente pequeña para que, en caso de error, el impacto sea mínimo, pero lo suficientemente grande para obtener métricas estadísticamente significativas. 1% para una aplicación con 10 millones de usuarios son 100,000 personas — suficiente para detectar problemas críticos.
¿Hay que hacer una release party?
Una release party (celebración en equipo) es opcional pero beneficiosa para la moral. Es mejor realizarla después de un rollout exitoso al 100%, no en el momento de subir el build. Release celebration se puede combinar con una retrospectiva del lanzamiento para discutir qué salió bien y qué se puede mejorar.
¿Quién es responsable de la decisión “lanzar o posponer”?
La responsabilidad recae en el release manager (normalmente un ingeniero senior o tech lead). La decisión se basa en los datos del dashboard de lanzamiento, no en la fecha límite. Release manager tiene la autoridad para retrasar el lanzamiento si las métricas no superan el go/no-go gate.
Resumen
- Día de lanzamiento — proceso coordinado desde el code freeze hasta el monitoreo posterior al rollout
- Preparación — release candidate, ejecución de QA, verificación de metadatos, plan de rollback
- Staged rollout — 1% → 10% → 25% → 50% → 100% con go/no-go gate en cada etapa
- Monitoreo — crash-free rate, ANR, tasa de error 5xx, valoraciones de usuarios en las primeras 4 horas
- Rollback — procedimiento estándar cuando la tasa de crashes baja del 99%
- Comunicación — notificar al equipo y a los interesados antes y después del lanzamiento
- Release retrospective — revisión del proceso tras completar el rollout al 100%
Desarrollaremos una aplicación móvil llave en mano
IT Sectr crea aplicaciones para iOS y Android para startups y empresas desde 2017. Le asesoraremos y le propondremos la mejor solución.
Lea también