¿Cómo es en la práctica un pipeline de CI/CD móvil: Fastlane, GitHub Actions, Bitrise?

#Qué significa "un pipeline real" más allá de un check verde

Una respuesta junior describe un único job de CI que corre ./gradlew test en cada push. Una respuesta senior describe un pipeline con etapas distintas y con gates — análisis estático, pruebas unitarias, un build firmado, pruebas de UI instrumentadas, distribución beta y un lanzamiento a la tienda — donde cada etapa puede fallar de forma independiente y las etapas siguientes nunca corren contra un artefacto que no pasó las anteriores. Las herramientas puntuales cambian (Fastlane, GitHub Actions, Bitrise), pero la forma del pipeline es casi universal entre los equipos móviles serios.

#Las etapas, en orden

Cada commit o pull request dispara primero el análisis estático — ktlint/detekt en Android, SwiftLint en iOS — porque es la señal más barata y debería fallar rápido antes de gastar minutos de CI en cualquier otra cosa. Después corren las pruebas unitarias directamente contra la JVM (sin necesidad de emulador) o vía xcodebuild test contra un simulador para las pruebas de Swift de lógica pura, y solo después de que ambas pasan el pipeline construye un artefacto real. Las ramas de feature y los pull requests normalmente se quedan en un build debug sin firmar para que el PR reciba su check rápido; los merges a main o a una rama de release van más allá y producen un build de release firmado, porque las claves de firma nunca deberían exponerse a pull requests arbitrarios de forks.

#Fastlane es el pegamento, no el sistema de CI en sí

Fastlane no reemplaza a GitHub Actions ni a Bitrise — es la herramienta que convierte una docena de comandos de shell frágiles en un lane nombrado y versionado que tanto una persona como el CI pueden correr de forma idéntica. Un Fastfile típicamente expone lanes como test, beta y release, y cada uno compone acciones más chicas por debajo: una construye y firma una app de iOS, otra gestiona certificados y perfiles de aprovisionamiento sincronizándolos desde un repositorio git cifrado para que ningún desarrollador tenga que clickear a mano la UI de firma de Xcode, otra maneja un build de Gradle en Android, otra sube a Google Play con un porcentaje de rollout específico, y otras suben a TestFlight y a App Store Connect respectivamente. La mayor ganancia de nombrar Fastlane en una respuesta de entrevista es nombrar específicamente la acción de sincronización de certificados — la firma es donde muere la mayoría de los primeros intentos de armar CI móvil.

#GitHub Actions vs. Bitrise: tradeoffs distintos, no una mejora estricta

GitHub Actions es CI genérico: escribís vos el workflow, elegís el runner (un runner de macOS es obligatorio para cualquier paso de build de iOS, y se factura a una tarifa notablemente más alta que Linux), y sos vos quien se encarga de cachear las dependencias de Gradle, CocoaPods o Swift Package Manager para tener tiempos de build razonables. Bitrise es CI nativo para mobile: la gestión de certificados y perfiles de aprovisionamiento, la integración con el Apple Developer Portal y el acceso a device farms están más cerca de ser ciudadanos de primera clase ahí, al costo de una factura de SaaS y menos flexibilidad fuera de la caja con forma de mobile para la que fue construido. Muchos equipos serios usan ambos — GitHub Actions haciendo de gate en los pull requests con feedback rápido de pruebas unitarias, y Bitrise (o un pool de runners de macOS propios) a cargo de los lanes más pesados de build firmado y distribución.

#La distribución beta es un gate real, no un detalle secundario

Un build firmado que pasa las pruebas de UI instrumentadas — Espresso/Compose en un emulador headless o de un device farm en la nube, XCUITest en un simulador o un device farm físico — va a testers internos antes de llegar siquiera a una tienda: Firebase App Distribution o el track interno de Play Console en Android, TestFlight en iOS. Este es un gate deliberado, no burocracia: las señales de crashes y ANRs de testers reales en dispositivos reales detectan lo que una corrida en un emulador de CI estructuralmente no puede, y saltearse este paso es exactamente cómo un build roto llega a usuarios de producción en vez de a un canal de QA primero.

#El lanzamiento a la tienda en sí es escalonado, no un interruptor

Ambas tiendas soportan — y los equipos maduros exigen — un rollout escalonado o por fases: un porcentaje chico de usuarios primero, escalando durante varios días mientras se vigila la tasa de crash-free y de ANR en la analítica propia de la tienda, con la posibilidad de frenar o revertir antes de que el rollout llegue a todos. Automatizar ese aumento de porcentaje mediante Fastlane o la API de App Store Connect, condicionado a un chequeo de salud en vez de a un timer fijo, es el detalle que separa "lanzamos a la tienda" de "lanzamos de forma segura".