Publicar en cada merge: la API de edición, Fastlane y el canal interno

La publicación automática es la frontera donde la integración continua se convierte en entrega continua, y es también donde más equipos se detienen porque la palabra publicar les suena a irreversible. Conviene deshacer esa asociación desde el principio: publicar en un canal de prueba cerrado no es enviar nada a los usuarios, es poner el artefacto donde un grupo definido de personas puede instalarlo con un toque en lugar de descargando un fichero de un chat. La diferencia entre un equipo que hace esto y uno que no se mide en horas de fricción por semana, pero también en algo más difícil de cuantificar: en el primero, cada fusión a la rama principal produce algo que existe de verdad, y esa propiedad cambia la manera en que la gente escribe código.

El modelo transaccional: la edición como unidad de cambio

La interfaz de programación del portal de desarrollo no expone operaciones sueltas del tipo sube este fichero. Expone un objeto llamado edición que funciona como una transacción: se abre, se le aplican cambios que no tienen ningún efecto observable mientras siga abierta, y se confirma en un único acto que los hace efectivos todos a la vez o ninguno. Ese diseño existe porque una publicación real no consiste solo en un binario, sino en un binario más un canal más unas notas de versión más un porcentaje de despliegue, y liberar esas piezas por separado dejaría estados intermedios incoherentes visibles para los usuarios.

Comprender esto resuelve de golpe una familia entera de errores desconcertantes. Los mensajes que hablan de una edición que ya no existe suelen significar que el proceso tardó demasiado entre la apertura y la confirmación, porque las ediciones caducan. Los que hablan de un conflicto suelen significar que hay dos ediciones abiertas a la vez, típicamente porque una ejecución anterior falló a mitad y nadie la cerró, o porque alguien tiene la consola web abierta con cambios sin guardar. Y los que informan de que el paquete no puede procesarse casi nunca se refieren al paquete, sino a que el número de versión ya fue usado en algún canal, incluido uno que el equipo había olvidado.

La secuencia canónica tiene cuatro pasos y el orden importa. Se abre la edición; se sube el artefacto, que queda asociado a la edición pero sin canal; se asigna ese artefacto a una pista concreta declarando su estado y, si procede, su fracción de despliegue; y se confirma. Un quinto paso opcional, a menudo el más útil, consiste en indicar que los cambios no se envían a revisión, lo que permite acumular varias subidas y decidir después.

La cuenta de servicio y el privilegio mínimo

La automatización se autentica con una cuenta de servicio del proveedor de nube, vinculada al portal de desarrollo y con una clave en formato de texto estructurado que se guarda como secreto igual que cualquier otra credencial. Aquí aparece la primera decisión de diseño que casi nadie toma conscientemente: qué permisos concederle. La respuesta cómoda es concederle administración completa; la respuesta correcta es concederle exactamente la capacidad de gestionar publicaciones en las pistas de prueba y nada más.

La diferencia es material. Una cuenta que solo puede subir a la pista interna no puede publicar en producción aunque alguien modifique el flujo, no puede alterar la ficha de la tienda, no puede cambiar precios ni responder reseñas y no puede retirar la aplicación. Como esa credencial vive en un almacén de secretos al que tienen acceso todos los flujos del repositorio, limitar su alcance es la única defensa real contra un error de configuración o contra una acción de terceros comprometida.

Conviene también separar credenciales por propósito cuando la organización lo permite: una cuenta para subir a pistas internas desde el pipeline automático y otra, con permisos mayores, reservada a un flujo manual que exige aprobación humana explícita. Es el mismo principio que separa la clave de subida de la clave de firma de aplicación, aplicado al plano de la distribución.

- name: Restaurar la credencial de la cuenta de servicio
  run: |
    printf '%s' "${{ secrets.PLAY_SERVICE_ACCOUNT_JSON }}" > "$RUNNER_TEMP/play.json"
    echo "PLAY_JSON=$RUNNER_TEMP/play.json" >> "$GITHUB_ENV"

- name: Subir a la pista interna
  run: bundle exec fastlane interna
  env:
    SUPPLY_JSON_KEY: ${{ env.PLAY_JSON }}

- name: Limpiar la credencial
  if: always()
  run: rm -f "$RUNNER_TEMP/play.json"

Fastlane frente a la invocación directa

Existen dos caminos y la elección depende menos de la elegancia que del alcance de lo que se automatiza. Invocar la interfaz de programación directamente, con la biblioteca cliente del proveedor o con peticiones a mano desde un script, es perfectamente razonable cuando lo único que se hace es subir un paquete a una pista interna y confirmar. Son unas pocas llamadas, sin dependencias ajenas al proyecto, con control total sobre el manejo de errores y sin un intérprete adicional que instalar y mantener en el runner.

Fastlane compensa cuando el alcance crece. Su acción de aprovisionamiento conoce el modelo transaccional completo, gestiona la caducidad y los conflictos de edición, y añade lo que resulta tedioso hacer a mano: sincronizar notas de versión desde una estructura de directorios por idioma, subir capturas de pantalla y textos de la ficha, gestionar el mapa de símbolos para desofuscar informes de fallo, y expresar despliegues por fases con una sintaxis legible. Su coste es una dependencia en ruby que hay que fijar por versión y cachear, y una capa de abstracción más entre tu intención y el error que devuelve el servidor.

La regla práctica es reconocible: si tus notas de versión viven en el repositorio y cambian con cada publicación, Fastlane te ahorra trabajo real. Si solo subes binarios a una pista interna y las notas las escribe alguien en la consola cuando toca promover, la invocación directa es más simple y más fácil de depurar.

# fastlane/Fastfile
default_platform(:android)

platform :android do
  desc "Compilar y subir a la pista interna sin enviar a revision"
  lane :interna do
    gradle(task: "bundle", build_type: "Release")
    upload_to_play_store(
      track: "internal",
      release_status: "draft",
      changes_not_sent_for_review: true,
      skip_upload_apk: true,
      skip_upload_metadata: true,
      skip_upload_images: true,
      skip_upload_screenshots: true
    )
  end

  desc "Promover lo ya subido a la pista cerrada con despliegue parcial"
  lane :promover do
    upload_to_play_store(
      track: "internal",
      track_promote_to: "beta",
      rollout: "0.1",
      skip_upload_aab: true
    )
  end
end

flowchart TD
A[Merge en la rama principal] --> B[Calcular numero de version desde el contador]
B --> C[Compilar el paquete de aplicacion firmado]
C --> D[Abrir edicion en el portal]
D --> E[Subir el artefacto a la edicion]
E --> F[Asignar a la pista interna]
F --> G[Confirmar la edicion]
G --> H[Disponible para el equipo en minutos]
H --> I{Se promociona}
I -- Si --> J[Pista cerrada con despliegue al diez por ciento]
I -- No --> K[Se descarta y se espera al siguiente merge]
J --> L[Ampliar o detener segun metricas]
style G fill:#a6e3a1,color:#11111b
style L fill:#f9e2af,color:#11111b

Publicar en cada fusión: qué significa de verdad

La formulación publicar en cada merge se malinterpreta con facilidad. No significa que cada fusión llegue a los usuarios, sino que cada fusión produce un artefacto real, firmado, instalable y localizable, disponible para un grupo interno en cuestión de minutos. La promoción a canales mayores sigue siendo una decisión, tomada por personas, sobre un artefacto que ya existe y que ya ha sido usado por alguien. Lo que se automatiza es la producción; lo que se conserva humano es la distribución.

El beneficio operativo más evidente es que la pregunta funciona esto en un dispositivo real deja de requerir que nadie compile nada. El menos evidente, y más valioso, es que separa la construcción de la decisión de publicar. Un equipo que compila solo cuando decide publicar descubre los problemas de la variante de publicación en el peor momento posible, con la fecha encima; un equipo que la construye en cada fusión los descubre el mismo día en que se introducen, cuando el cambio culpable ocupa una sola pantalla.

Hay dos disciplinas que hacen sostenible el esquema. La primera es la idempotencia: el flujo debe poder ejecutarse dos veces sobre el mismo commit sin dejar estados a medias, lo que implica cerrar o descartar ediciones huérfanas antes de abrir una nueva y tolerar el caso de un número de versión ya subido sin marcar la ejecución como fallida por ello. La segunda es la trazabilidad: cada artefacto debe llevar en sus notas internas el identificador exacto del commit que lo produjo, para que un informe de fallo de un probador se pueda convertir en un diagnóstico sin arqueología.

# Numero de version derivado de algo estrictamente creciente
VERSION_CODE=$(git rev-list --count HEAD)
./gradlew bundleRelease -PversionCode="$VERSION_CODE" -PgitSha="$(git rev-parse --short HEAD)"

# Detener un despliegue por fases sin publicar nada nuevo
bundle exec fastlane run upload_to_play_store track:production rollout:0 skip_upload_aab:true