CI/CD para proyectos Kotlin en GitHub Actions: guía completa

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

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

El desarrollo moderno en Kotlin —ya sea backend con Spring Boot, una aplicación Android o un proyecto multiplataforma— requiere un ciclo de entrega rápido y confiable. Los procesos manuales de compilación y prueba no solo consumen tiempo, sino que también son propensos a errores. Aquí es donde entra en juego CI/CD (Continuous Integration / Continuous Deployment).

GitHub Actions es un sistema de automatización integrado que permite ejecutar flujos de trabajo (workflows) directamente en tu repositorio. Para proyectos Kotlin es la opción ideal: se integra fácilmente con Gradle, soporta el almacenamiento en caché de dependencias y permite desplegar aplicaciones en cualquier plataforma.

En este artículo analizaremos cómo configurar un pipeline CI/CD completo para un proyecto Kotlin usando GitHub Actions: desde la compilación básica hasta el despliegue automático.

1. Fundamentos de GitHub Actions: estructura de un workflow

Cada workflow en GitHub Actions es un archivo YAML ubicado en el directorio .github/workflows/. Veamos los componentes básicos usando un proyecto Kotlin como ejemplo.

1.1. Disparadores (on)

Un workflow se ejecuta ante eventos específicos: push a una rama, creación de un Pull Request, o según un horario (cron).

1.2. Jobs y Steps

Un Job es un conjunto de pasos que se ejecutan en un mismo entorno virtual. Los Steps pueden ejecutar comandos, scripts o actions predefinidas del marketplace.

1.3. Ejemplo de workflow mínimo

Creemos el archivo .github/workflows/ci.yml para un proyecto Kotlin con Gradle:

name: CI for Kotlin

on:  push:    branches: [ main, develop ]  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: Setup Gradle        uses: gradle/actions/setup-gradle@v3

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

      - name: Run tests        run: ./gradlew test

Este pipeline ejecutará la compilación y las pruebas en cada push o PR a main/develop.

2. Optimización del CI: almacenamiento en caché y tareas paralelas

Sin optimización, cada ejecución descargará las dependencias de Gradle desde cero. Para proyectos Kotlin, esto puede llevar de 2 a 5 minutos. La solución es el almacenamiento en caché.

2.1. Almacenamiento en caché de Gradle

GitHub Actions permite almacenar en caché el directorio ~/.gradle/caches:

- 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-

Después de la primera ejecución, las siguientes usarán la caché — la velocidad aumenta entre 2 y 3 veces.

2.2. Jobs paralelos para diferentes tareas

Se pueden dividir las pruebas, el linting y la compilación en jobs separados que se ejecutan en paralelo:

jobs:  lint:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Run detekt        run: ./gradlew detekt

  test:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Run tests        run: ./gradlew test

  build:    needs: [lint, test]    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Build JAR        run: ./gradlew bootJar

Aquí, build se ejecutará solo después de que linting y pruebas hayan pasado exitosamente.