Canales de prueba: del equipo al mundo sin sobresaltos

Una versión no salta del portátil al mundo: recorre una escalera de audiencias cada vez más amplias y cada vez menos tolerantes al error. Los cuatro canales de la tienda no son cuatro botones equivalentes, son cuatro combinaciones distintas de latencia de revisión, tamaño de audiencia, visibilidad pública y capacidad de recogida de señal. Elegir mal el canal cuesta tiempo cuando es conservador y reputación cuando es temerario. Y hay una asimetría que gobierna todo el diseño: subir por la escalera es barato y reversible, bajar no existe. Nadie desinstala una versión mala del móvil de un usuario; lo único que puedes hacer es publicar otra encima y esperar a que llegue.

Los cuatro canales y qué resuelve cada uno

Los canales se ordenan por audiencia, pero lo que de verdad los diferencia es qué tipo de señal producen y cuánto tardan en producirla.

Esa ordenación esconde un segundo eje que importa tanto como la audiencia: la latencia de disponibilidad. El canal interno pone la versión en manos del equipo en minutos porque solo pasa comprobaciones básicas; el resto de canales atraviesan el mismo proceso de revisión que producción y por tanto heredan su incertidumbre de calendario. Un equipo que planifica asumiendo que probar en cerrado es instantáneo descubre que su ciclo de iteración pasó de horas a días.

El canal interno es el que más se malinterpreta. Su valor no está en probar funcionalidad, que se prueba mejor con instalaciones directas, sino en ejercitar exactamente el camino de producción: el artefacto minificado y ofuscado, firmado con la clave real, troceado por la tienda y descargado por el dispositivo. Ese camino tiene fallos propios que la compilación de depuración jamás reproduce, y descubrirlos en el canal interno cuesta minutos mientras que descubrirlos en producción cuesta una versión de emergencia.

Hay un matiz de mecánica que ahorra confusiones: para participar en un canal de prueba, la persona debe aceptar una invitación asociada a la cuenta con la que tiene configurada la tienda en su dispositivo, y esa aceptación tarda un rato en propagarse. La queja recurrente de que un participante no ve la versión casi nunca es un fallo de la plataforma: es una cuenta distinta de la invitada, una invitación sin aceptar, o simplemente propagación pendiente.

Los canales cerrado y abierto se distinguen menos por el tamaño que por el control. En el cerrado sabes quién prueba y puedes hablar con esas personas; en el abierto obtienes volumen anónimo. Un equipo con producto delicado suele quedarse en cerrado con varias listas de audiencias distintas. Un equipo que necesita detectar fallos que solo aparecen en el uno por mil de dispositivos necesita el abierto, porque ninguna lista invitada alcanza esa densidad.

La mecánica de una release

Una release es un objeto con tres partes: uno o varios artefactos, unas notas de versión por idioma y una configuración de destino. Se crea en un canal, se revisa, y desde ahí puede promocionarse a canales superiores sin reconstruir nada.

flowchart TD
BUILD[Artefacto firmado por integracion continua] --> INT[Canal interno]
INT --> VER[Verificacion del camino de produccion]
VER --> CER[Canal cerrado con testers invitados]
CER --> SIG[Recogida de senal durante dias]
SIG --> ABI[Canal abierto opcional]
ABI --> PRO[Produccion con despliegue por porcentaje]
CER --> PRO
PRO --> MON[Vigilancia de fallos y ANR]

La promoción es la operación que hace que este flujo tenga sentido económico: el binario que llega a producción es bit a bit el mismo que se probó abajo. Si en cada canal reconstruyes, no estás promocionando sino publicando cuatro cosas distintas, y todo lo aprendido en los canales inferiores pierde validez. Esta es la regla que más se incumple en equipos que automatizan mal la integración continua.

# Publicar en un canal desde integracion continua, con la API de publicacion
./gradlew :app:bundleRelease
fastlane supply \
  --aab app/build/outputs/bundle/release/app-release.aab \
  --track internal \
  --release_status draft

# Promocionar lo ya revisado a produccion sin reconstruir
fastlane supply \
  --track internal \
  --track_promote_to production \
  --rollout 0.05

Las notas de versión tienen una particularidad que conviene automatizar: se definen por idioma, y muchas configuraciones exigen que estén presentes en todos los idiomas activos de la ficha. Generarlas desde el sistema de control de versiones, con un fichero por idioma en el repositorio, es la práctica que evita tanto los lanzamientos bloqueados por notas ausentes como las notas escritas a las once de la noche que dicen “correcciones varias” durante dos años seguidos.

La publicación gestionada es el interruptor que separa aprobar de publicar. Con ella activada, una versión aprobada por la revisión se queda esperando y solo sale cuando tú lo ordenas. Sirve para coordinar un lanzamiento con una campaña, con un despliegue de servidor o con una publicación simultánea en varias plataformas. Sin ella, aprobar y publicar son el mismo evento y pierdes el control del momento.

Diseñar el flujo según el equipo

No existe un flujo canónico. Existe un compromiso entre la velocidad que necesitas y la señal que puedes permitirte perder, y ese compromiso depende de tres variables: cuántos usuarios tienes, cuánto cuesta un fallo en tu producto y cuánta capacidad tienes de responder rápido.

Equipo pequeno, app joven, pocos usuarios
  interno -> produccion con despliegue lento
  motivo: el canal cerrado no reune volumen suficiente para dar senal

Producto establecido con base amplia
  interno -> cerrado varios dias -> produccion por porcentaje
  motivo: el cerrado ya produce datos estadisticamente utiles

App critica o regulada
  interno -> cerrado -> abierto -> produccion escalonada
  motivo: cada peldano compra evidencia antes de exponer mas gente

Correccion urgente de un fallo grave
  interno breve -> produccion al cien por cien
  motivo: la exposicion al fallo actual supera al riesgo del cambio

Conviene además fijar de antemano el criterio de promoción, porque si no se decide antes se decide con el sesgo del momento. Un criterio útil tiene tres partes: un tiempo mínimo de permanencia en el canal, un volumen mínimo de sesiones acumuladas que garantice que la ausencia de fallos significa algo, y un conjunto de umbrales comparados contra la versión anterior. Sin las tres, promocionar acaba dependiendo de si alguien tiene prisa.

Ese último caso merece atención porque contradice la intuición de que más prudencia es siempre mejor. Cuando ya hay una versión rompiendo la app de todo el mundo, desplegar la corrección lentamente prolonga el daño. La prudencia se mide contra el estado actual, no contra un ideal sin riesgo.

Hay además un requisito que condiciona el flujo de quienes empiezan: las cuentas de desarrollador personales creadas recientemente deben ejecutar una prueba cerrada con un número mínimo de participantes durante un periodo continuado antes de poder solicitar acceso a producción. No es un consejo, es una puerta cerrada, y no se satisface con cuentas de conveniencia porque se exige participación real y sostenida. Los equipos que planifican el lanzamiento sin contar con esas semanas descubren el requisito cuando ya no tienen margen.

Errores de flujo que arruinan una publicación

La mayoría de los desastres de publicación no son fallos de código sino de secuencia. Vale la pena conocerlos porque casi todos son irreversibles.

El primero es quemar códigos de versión. Cada artefacto subido consume su entero para siempre, incluso si descartas la versión. Un pipeline que sube borradores en cada integración agota el espacio útil y, peor, puede dejar en un canal superior un código mayor que el de producción, lo que bloquea publicar hasta que saltes por encima.

Ese primer error tiene una comprobación barata que conviene automatizar antes de cualquier publicación, porque detecta el bloqueo antes de provocarlo en lugar de descubrirlo cuando la versión ya está en revisión.

# Volcar el estado de todos los canales antes de publicar
fastlane run google_play_track_version_codes track:production
fastlane run google_play_track_version_codes track:beta
fastlane run google_play_track_version_codes track:alpha
fastlane run google_play_track_version_codes track:internal

# Regla que debe cumplirse siempre antes de subir
#   codigo_nuevo mayor que el maximo de todos los canales

El segundo es cruzar canales con códigos desordenados. Si el canal abierto tiene un código mayor que producción, los usuarios de ese canal no recibirán la versión de producción aunque sea más nueva en el tiempo, porque el sistema solo actualiza hacia códigos mayores. Sacarlos de ahí exige publicar una versión con código aún mayor en el canal que corresponda.

El tercero es olvidar que abandonar un canal no desinstala nada. Si detienes un canal de prueba, quienes lo tenían conservan esa versión y quedan varados hasta que producción supere su código. En apps con betas largas es una fuente crónica de usuarios atrapados en compilaciones antiguas.

El cuarto es publicar notas de versión solo en un idioma, lo que en algunas configuraciones borra las de los demás y deja fichas incompletas en mercados enteros.

El quinto, más sutil, es probar con una configuración que no es la de producción. Un canal alimentado por artefactos que apuntan a un servidor de pruebas, con la minificación desactivada o con una variante distinta de dependencias, produce confianza falsa: lo que valida no es lo que se publicará. La disciplina correcta es que el artefacto de los canales de prueba sea idéntico al de producción salvo en configuración remota, que sí puede diferir porque no vive en el binario.