CI/CD para proyectos Kotlin con GitHub Actions: guía paso a paso

Introducción: Por qué CI/CD es indispensable para el desarrollo con Kotlin

El desarrollo moderno con Kotlin no solo implica escribir código conciso y seguro, sino también garantizar su entrega continua. Ya sea que estés creando una aplicación del lado del servidor con Ktor, una app para Android o un proyecto multiplataforma, las compilaciones y pruebas manuales se convierten rápidamente en un cuello de botella. CI/CD (Integración Continua / Despliegue Continuo) automatiza estos procesos, reduciendo el riesgo de errores humanos y acelerando el lanzamiento de nuevas funcionalidades.

GitHub Actions es una de las herramientas más populares para implementar CI/CD, especialmente si tu código ya está alojado en GitHub. Se integra estrechamente con el ecosistema de Kotlin, es compatible con Gradle y Maven, y te permite configurar pipelines de manera flexible para cualquier necesidad. En este artículo, analizaremos cómo configurar un ciclo completo de compilación, prueba y despliegue de un proyecto Kotlin usando GitHub Actions.

Conceptos básicos de GitHub Actions: Estructura de un workflow

Antes de escribir código, comprendamos los conceptos básicos. Un workflow en GitHub Actions es un proceso automatizado que se activa mediante un evento específico (por ejemplo, un push a la rama principal). Un workflow se describe en un archivo YAML almacenado en el directorio .github/workflows/ de tu repositorio.

Una estructura típica de workflow incluye:

• name — el nombre del workflow (se muestra en la interfaz de GitHub).
• on — los eventos desencadenantes (por ejemplo, push, pull_request).
• jobs — un conjunto de tareas que se ejecutan de forma secuencial o en paralelo.
• steps — los pasos dentro de un trabajo (configurar JDK, almacenar en caché dependencias, ejecutar pruebas).

Para proyectos Kotlin, un paso clave es configurar la versión correcta de JDK (generalmente 11, 17 o 21) y usar el Gradle Wrapper (./gradlew), lo que garantiza la reproducibilidad de la compilación en cualquier máquina.

Paso 1: Compilación y prueba básicas para un proyecto Kotlin

Comencemos con lo más simple: un workflow que ejecute pruebas en cada push a main o cuando se cree un Pull Request. Esta es la base de cualquier CI/CD: garantizar que el código nuevo no rompa la funcionalidad existente.

Crea un archivo .github/workflows/ci.yml con el siguiente contenido:

name: CI for Kotlin

on:  push:    branches: [ main ]  pull_request:    branches: [ main ]

jobs:  build:    runs-on: ubuntu-latest

    steps:      - uses: actions/checkout@v4

      - name: Set up JDK 17        uses: actions/setup-java@v4        with:          java-version: '17'          distribution: 'temurin'

      - name: Grant execute permission for gradlew        run: chmod +x gradlew

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

      - name: Build with Gradle        run: ./gradlew build

      - name: Run tests        run: ./gradlew test

Analicemos los puntos clave:

• actions/checkout@v4 — clona el repositorio en el runner.
• actions/setup-java@v4 — instala JDK 17 (Temurin). Puedes elegir una versión diferente si tu proyecto lo requiere, por ejemplo, JDK 11 o 21.
• actions/cache@v4 — almacena en caché las dependencias de Gradle. Esto es críticamente importante para la velocidad: sin caché, cada compilación descargaría todas las bibliotecas desde cero (lo que puede tomar 2-5 minutos). El almacenamiento en caché acelera esto a unos pocos segundos.
• ./gradlew build — una compilación completa del proyecto (compilación + pruebas). Si solo deseas pruebas, usa ./gradlew test.