CI/CD para proyectos Kotlin: GitHub Actions de la A a la Z

Introducción: Por qué CI/CD es críticamente importante para proyectos Kotlin

En el desarrollo moderno con Kotlin, ya sea un backend con Ktor, una aplicación Android o un proyecto multiplataforma, la ejecución manual de operaciones repetitivas (compilación, ejecución de pruebas, verificación de estilo de código) no solo es una pérdida de tiempo, sino también una fuente de errores. CI/CD (Integración Continua / Despliegue Continuo) resuelve este problema automatizando todo el pipeline desde el commit hasta la producción.

GitHub Actions es una herramienta de automatización integrada que es perfecta para proyectos Kotlin. Permite crear pipelines directamente en el repositorio, sin necesidad de servicios de terceros. En este artículo, analizaremos cómo configurar un CI/CD completo para Kotlin usando GitHub Actions, desde la compilación básica hasta el despliegue.

1. Fundamentos de GitHub Actions y Kotlin

GitHub Actions se basa en workflows (flujos de trabajo): archivos YAML que definen una secuencia de pasos. Cada workflow se activa mediante un disparador (push, pull request, programación) y se ejecuta en un entorno virtual llamado runner.

Para proyectos Kotlin, el stack estándar incluye:

\n
• Gradle o Maven — sistema de compilación;
\n
• JUnit / Kotest — frameworks de pruebas;
\n
• Detekt / ktlint — linters para Kotlin.
\n

El primer paso es crear el archivo .github/workflows/ci.yml en la raíz del repositorio. Veamos una configuración mínima para compilación y pruebas.

1.1 Compilación y pruebas básicas

Comencemos con un pipeline simple que se activa en cada push y pull request a la rama main:

name: CI for Kotlin\n\non:\n  push:\n    branches: [ main ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n\n    steps:\n      - uses: actions/checkout@v3\n      - name: Set up JDK 17\n        uses: actions/setup-java@v3\n        with:\n          java-version: '17'\n          distribution: 'temurin'\n      - name: Grant execute permission for gradlew\n        run: chmod +x gradlew\n      - name: Build with Gradle\n        run: ./gradlew build\n      - name: Run tests\n        run: ./gradlew test

Este código hace lo siguiente: clona el repositorio, instala JDK 17 (versión recomendada para Kotlin 1.9+), hace ejecutable gradlew, ejecuta la compilación y lanza las pruebas. Si las pruebas fallan, el pipeline se detiene con un error.

2. Configuración avanzada: linting, caché y matriz de compilaciones

La configuración básica está bien, pero para un proyecto real se necesita más. Añadamos verificación de estilo de código con Detekt y caché de dependencias de Gradle para acelerar el trabajo.

2.1 Caché de Gradle

Sin caché, cada ejecución descarga las dependencias nuevamente, lo que puede tomar de 2 a 5 minutos. Usemos el caché integrado:

- name: Cache Gradle packages\n  uses: actions/cache@v3\n  with:\n    path: |\n      ~/.gradle/caches\n      ~/.gradle/wrapper\n    key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}\n    restore-keys: |\n      ${{ runner.os }}-gradle-

2.2 Linting con Detekt

Añadamos una tarea para verificar el código. Detekt se puede ejecutar a través del plugin de Gradle:

- name: Run Detekt\n  run: ./gradlew detekt

Si Detekt encuentra infracciones, el pipeline finalizará con un error. Esto garantiza que no entre código "sucio" al repositorio.

2.3 Matriz de compilaciones (Matrix Build)

Si su proyecto soporta múltiples versiones de Kotlin o JDK, use una matriz. Esto permite verificar la compatibilidad sin duplicar código:

jobs:\n  build:\n    strategy:\n      matrix:\n        java: [11, 17, 21]\n        kotlin: [1.9.0, 2.0.0]\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v3\n      - name: Set up JD