Llevar una aplicación Android a producción no es apretar un botón y cruzar los dedos. El deployment en Android exige entornos separados, fases beta, rollouts progresivos y un sistema de versionamiento claro que te permita rastrear cada cambio sin volverte loco en el intento.

Si desarrollas apps móviles y quieres reducir el riesgo de publicar errores en la Play Store, estas prácticas te ayudan a controlar cada paso antes y después del lanzamiento.

¿Por qué necesitas varios entornos antes de producción?

Trabajar con un solo entorno es una receta para el desastre. Necesitas al menos dos espacios distintos antes de pensar en producción.

El primero es el entorno con datos mockeados, donde pruebas la app con información falsa y flujos controlados. El segundo es el sandbox, una caja de arena donde ya te conectas al servidor real, mides tiempos de respuesta y observas el comportamiento de la aplicación cuando algo falla.

En ese entorno sandbox puedes simular escenarios reales: qué pasa cuando el servidor se cae, cuándo se demora en traer un dato, cómo responde la app al enviar información. Es tu fase beta interna antes de exponer cualquier cosa al usuario final.

¿Qué es un entorno sandbox? Es un espacio de pruebas conectado al servidor real donde validas el comportamiento de la aplicación sin afectar a usuarios en producción.

¿Cómo funciona la fase beta cerrada y el rollout progresivo?

Después del sandbox no saltas a producción. Pasas por una fase beta cerrada con un release candidate, es decir, la versión que pretendes mandar a la Play Store pero que todavía no liberas al público.

Esa versión la reciben pocos usuarios que saben que la app puede fallar y que aún no tiene todos los fix. Con su feedback haces correcciones, vuelves a sacar otra beta y monitoreas como aprendiste en la clase anterior.

Cuando la beta está estable, llega el rollout progresivo. No envías la actualización al 100% de tus usuarios de golpe. Lo haces así:

• Liberas al 5% de los usuarios y monitoreas el comportamiento.
• Si todo va bien, subes al 10% y sigues observando métricas.
• Continúas escalando porcentajes hasta cubrir el total.

La ventaja es brutal: si en ese 5% inicial detectas que el 80% presenta fallas, detienes la versión, corriges y solo se vio afectada una fracción mínima de tu base. Así el rollout se vuelve rápido y controlado.

¿Qué es un rollout progresivo? Es lanzar una actualización por porcentajes (5%, 10%, etc.) en lugar de hacerlo a todos los usuarios al mismo tiempo, para reducir el impacto de errores.

¿Qué es una granja de pruebas y por qué la necesitas?

Una granja de pruebas es un conjunto de dispositivos físicos de distintas gamas donde ejecutas tus pruebas end-to-end, unitarias y manuales. La idea es acercarte al entorno real, donde los usuarios tienen celulares muy distintos entre sí.

En esta granja revisas cosas concretas:

• Cómo se comportan las animaciones en un dispositivo de gama baja.
• Qué tan fluida se siente la app en un dispositivo de gama alta.
• Cómo responden las pruebas end-to-end en un Samsung frente a un Huawei, que tiene una arquitectura muy diferente.

Este paso te evita esa típica sorpresa de que la app funciona perfecto en tu emulador pero falla en el celular del usuario.

¿Cómo aplicar semantic versioning en aplicaciones móviles?

Somos humanos y fallamos al desarrollar. Por eso necesitas un log o sistema de versionamiento que te diga cómo evoluciona la aplicación. El estándar más usado, no solo en móviles sino en cualquier software, es el semantic versioning.

El formato tiene tres números separados por puntos: major, minor y patch. Por ejemplo, la versión 18.0.1 se lee así:

• Major (18): cambios drásticos. Un flujo totalmente nuevo, un cambio de marca, una nueva colorimetría o una experiencia completamente distinta.
• Minor (0): nuevas funcionalidades o features añadidos sobre la misma base.
• Patch (1): correcciones de bugs o hotfix sin agregar funcionalidad nueva.

¿Cómo se interpreta una versión como 18.0.1?

El 18 te dice que la aplicación ha tenido 18 cambios drásticos a grandes rasgos. El 0 indica que en esta versión major aún no se han añadido nuevos features. El 1 significa que tras salir a producción se detectaron errores y se lanzó un hotfix para repararlos.

Con solo leer ese número entiendes la historia de la app: cuántos rediseños profundos hubo, cuántas funcionalidades se sumaron y cuántas reparaciones fueron necesarias.

¿Qué significa el patch en semantic versioning? Es el último número de la versión y se incrementa cuando solo corriges bugs, sin agregar funcionalidades ni hacer cambios drásticos.

¿Cuándo no abusar del versionamiento?

No intentes meter información de más en el número. Una versión como 1.321.480.1115 abruma, deja de ser útil y rompe el propósito de comunicar el estado de la app de un vistazo.

Sé ordenado con la nomenclatura: cada número debe reflejar un cambio real y significativo. Si lo respetas, basta una mirada para saber qué tipo de actualización está en manos del usuario.

¿Qué práctica de deployment te ha salvado más veces en producción? Cuéntame en los comentarios cómo manejas tus rollouts y versionamientos.