Continuous Integration (CI) — qué es, principios y configuración de automatización

Qué es Continuous Integration

Continuous Integration (CI) es una metodología de desarrollo que automatiza el proceso de integración de código de múltiples contribuyentes en una base de código única. El término fue introducido por Martin Fowler a principios de los 2000 como un conjunto de prácticas para prevenir el “infierno de la integración” — una situación en la que los desarrolladores trabajan aislados durante semanas y, al fusionar cambios, surgen numerosos conflictos que requieren días de resolución manual.

El problema que resuelve la CI

Sin CI, un desarrollador termina una función, intenta fusionar sus cambios con la rama principal y descubre que sus colegas han modificado los mismos archivos. Resolver conflictos lleva horas y a menudo rompe el código funcional. La CI resuelve este problema imponiendo la integración varias veces al día: cuanto más frecuente es la integración, menos conflictos hay y más fácil es resolverlos. La práctica muestra que con la integración diaria, la resolución de conflictos toma minutos, mientras que con la integración semanal toma horas.

Impacto económico de la CI

Según el IBM Systems Sciences Institute, el costo de corregir un error en la etapa de codificación es de $25, en la etapa de prueba de $100, y en la etapa de producción de $2,500. La CI desplaza la detección de defectos lo más a la izquierda posible (shift left), encontrando errores en la etapa del commit cuando su corrección es prácticamente gratuita. Los equipos con CI dedican en promedio el 15% de su tiempo a la depuración, frente al 35% de los equipos sin CI.

Principios básicos de Continuous Integration

Martin Fowler definió las prácticas clave de CI que siguen siendo relevantes independientemente de la pila tecnológica. Seguir estos principios garantiza que la CI aporte valor en lugar de convertirse en una carga burocrática. El desarrollo móvil impone requisitos adicionales, pero el núcleo permanece sin cambios.

Repositorio único

Todo el código del proyecto se almacena en un único repositorio con un sistema de control de versiones unificado (Git). Una fuente única de verdad elimina la situación en la que una función se desarrolla en un fork y no se sincroniza con la base de código principal durante semanas. En proyectos móviles, esto significa que las partes de Android, iOS y backend pueden estar en un mismo repositorio (monorepositorio) o en repositorios separados con un esquema de versionado compartido.

Compilación automatizada

La compilación del proyecto debe ejecutarse con un solo comando. Para Android es ./gradlew assembleDebug, para iOS — xcodebuild o fastlane build. El script de compilación verifica la reproducibilidad: la compilación en el servidor CI debe dar el mismo resultado que en la máquina del desarrollador. Cualquier diferencia en el entorno se elimina mediante contenedores o IaC (Infrastructure as Code).

Pruebas automatizadas

Después de la compilación se ejecutan todos los niveles de pruebas: unitarias, de integración y de interfaz de usuario. Si las pruebas fallan, el commit se considera no válido. Mantener el estado verde es una responsabilidad compartida del equipo. En proyectos móviles, a menudo se separan las pruebas rápidas (ejecutadas en menos de 5 minutos por commit) de las pruebas lentas (pruebas de UI en dispositivos reales, ejecutadas con menos frecuencia).

// Ejemplo de prueba unitaria con informe compatible con CI
class LoginViewModelTest {

    private val repository = mock<AuthRepository>()
    private val viewModel = LoginViewModel(repository)

    @Test
    fun loginWithValidCredentials_success() {
        val email = "test@example.com"
        val password = "ValidPass123"

        whenever(repository.login(email, password))
            .thenReturn(Result.success(User("token-xyz")))

        val result = viewModel.login(email, password)

        assertEquals(LoginState.Success, result)
        verify(repository).login(email, password)
    }
}

Fail fast y transparencia

Los resultados de la CI son públicos para todo el equipo: todos ven qué commit rompió la compilación. La transparencia crea una cultura de responsabilidad: los desarrolladores verifican sus cambios antes del push y corrigen la compilación rota fuera de turno. El servidor CI envía notificaciones a Slack o Telegram cuando cambia el estado de la compilación.

Componentes de un sistema CI

Un sistema CI completo consta de varios componentes que interactúan entre sí. Cada componente es responsable de su parte del pipeline: desde el inicio hasta el informe. Comprender la arquitectura de CI ayuda a diagnosticar problemas y optimizar el rendimiento.

Servidor CI

El componente central que gestiona la cola de compilaciones, la asignación de recursos y la publicación de resultados. Un servidor CI puede ser en la nube (GitHub Actions, GitLab CI, CircleCI) o autoalojado (Jenkins, TeamCity). El servidor monitorea los cambios en el repositorio mediante webhook o polling y ejecuta el pipeline en cada push o pull request.

Runners y agentes

Los runners son máquinas virtuales o físicas que ejecutan las tareas de compilación. En la CI en la nube, los runners son proporcionados por el proveedor y se facturan por tiempo de uso. Los runners autoalojados se instalan en la propia infraestructura y requieren mantenimiento. Las compilaciones de iOS necesitan runners macOS, las de Android necesitan Linux o Windows.

Artefactos y caché

Después de la compilación, el sistema CI guarda los artefactos (APK, IPA, informes de pruebas) en un almacenamiento — están disponibles para descargar y desplegar. El caché de dependencias (caché de Gradle, caché de CocoaPods) entre ejecuciones acelera las compilaciones posteriores de 3 a 5 veces.

Continuous Integration para aplicaciones móviles

El desarrollo móvil tiene requisitos especiales para la CI que difieren de los proyectos web o backend. Los largos tiempos de compilación (3–15 minutos para Android, 5–20 minutos para iOS), los múltiples tipos de artefactos (APK, AAB, IPA), la necesidad de firmado y ofuscación — todo esto requiere una configuración personalizada del pipeline de CI.

Pipeline de CI para Android

Una CI típica para Android incluye: linting (ktlint, detekt) y análisis estático, pruebas unitarias con JUnit y MockK, compilación de APK/AAB debug y release, pruebas instrumentadas en un emulador dentro de la CI y publicación de artefactos. El caché de Gradle acelera las compilaciones repetidas — sin él, cada compilación descarga las dependencias desde cero, perdiendo 3–5 minutos.

Pipeline de CI para iOS

La CI para iOS requiere un runner macOS para compilar código Swift/Objective-C. El pipeline incluye: instalación de dependencias de CocoaPods o SPM, SwiftLint para verificar el estilo, pruebas unitarias con XCTest, compilación de IPA, firmado de código mediante Fastlane match y carga en TestFlight. Un runner autoalojado en Mac mini o Mac en un centro de datos es una alternativa a los runners macOS en la nube.

Proyectos multiplataforma (Flutter, React Native)

Flutter y React Native se compilan en builds nativos para ambas plataformas. La CI debe admitir dos runners: Linux para compilaciones de Android y macOS para compilaciones de iOS. La estrategia óptima es un pipeline dividido: compilación de Android en un runner Linux, compilación de iOS en un runner macOS, tras lo cual ambos artefactos se combinan en una única versión.

Comparación de herramientas CI

La elección de una herramienta CI depende del tamaño del equipo, el rendimiento requerido, el presupuesto y la pila tecnológica. A continuación se presenta una comparación de las soluciones populares con énfasis en el desarrollo móvil. Las soluciones autoalojadas brindan control pero requieren administración; las soluciones en la nube ofrecen comodidad pero limitan la configuración.

GitHub Actions

Gratuito para repositorios públicos (2000 minutos/mes). GitHub Actions ofrece un ecosistema de acciones listas para Android (gradle/actions) e iOS (apple-actions). La desventaja es que los runners macOS solo están disponibles en planes de pago. Ideal para proyectos de código abierto y equipos pequeños que ya usan GitHub.

Jenkins

Un servidor CI autoalojado de código abierto. Jenkins se configura mediante Groovy Pipeline, admite cientos de complementos y funciona en cualquier hardware. Requiere un ingeniero DevOps para su instalación y mantenimiento. Popular en el segmento empresarial donde el control de la infraestructura es crítico.

GitLab CI

CI/CD integrado en GitLab con una arquitectura de runners abierta. GitLab CI permite usar tus propios runners (incluido macOS) en el plan gratuito. La configuración YAML es más potente que GitHub Actions pero más difícil de aprender. Adecuado para equipos que usan GitLab como plataforma única de DevOps.

CircleCI

Una CI en la nube centrada en la velocidad. CircleCI admite imágenes Docker, macOS y Android, y almacena en caché las dependencias automáticamente. El precio es basado en créditos — más caro que GitHub Actions para equipos pequeños, pero más rápido gracias a runners optimizados. Recomendado para proyectos de producción con requisitos de velocidad.

Ejemplo de configuración de CI

Veamos la configuración de CI para un proyecto Android usando GitHub Actions. El pipeline realiza análisis estático, compilación y pruebas en cada push y pull request a la rama main. La configuración mínima toma 15 minutos y no requiere servicios externos.

name: Android CI
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - run: ./gradlew ktlintCheck detekt

  unit-tests:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew testDebugUnitTest
      - uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/tests/

El pipeline consta de dos trabajos paralelos: lint (realiza análisis estático) y unit-tests (depende de lint — si el linting falla, las pruebas no se ejecutan). El trabajo unit-tests carga el informe de pruebas como un artefacto — el equipo puede revisarlo en la interfaz de GitHub Actions sin descargar archivos localmente.

Verificación local antes de CI

Para evitar fallos de CI debido a errores triviales, configure un hook pre-push en Git o una tarea de Gradle que ejecute las mismas verificaciones localmente. Por ejemplo: ./gradlew ktlintCheck detekt testDebugUnitTest. Si las verificaciones locales toman más de 3 minutos, divídalas en rápidas (linter) y lentas (pruebas), ejecutando las rápidas antes de cada commit y las lentas solo antes del push.