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

Introducción a CI/CD para Kotlin con GitHub Actions

En el desarrollo moderno, la automatización de los procesos de compilación, prueba e implementación se ha convertido en una parte integral de un enfoque profesional. Para proyectos Kotlin, ya sean aplicaciones Android, servicios backend con Ktor o bibliotecas multiplataforma, configurar CI/CD (Integración Continua / Despliegue Continuo) permite reducir significativamente el tiempo de lanzamiento del producto y disminuir el riesgo de errores.

GitHub Actions es una herramienta potente y flexible integrada en el ecosistema de GitHub. Permite crear pipelines personalizados que se ejecutan automáticamente con pushes, creación de pull requests o según un horario. En este artículo, analizaremos el ciclo completo de configuración de CI/CD para Kotlin: desde la verificación básica del código hasta el despliegue automático.

Fundamentos de GitHub Actions: estructura y sintaxis

Antes de sumergirnos en lo específico de Kotlin, es importante comprender los conceptos básicos de GitHub Actions. El pipeline se describe en archivos YAML, que se almacenan en el directorio .github/workflows/ de tu repositorio.

Elementos clave de un workflow

• Event (evento): desencadenante que inicia el pipeline (push, pull_request, release, etc.).
• Job (tarea): conjunto de pasos que se ejecutan en un mismo runner (máquina virtual).
• Step (paso): acción concreta: ejecución de un comando, lanzamiento de un script o uso de un action predefinido.
• Runner: entorno de ejecución (Ubuntu, Windows, macOS).

Estructura básica del archivo kotlin-ci.yml:

name: Kotlin CI

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: Build with Gradle        run: ./gradlew build

Configuración de CI para Kotlin: compilación, pruebas y linting

La primera y más importante etapa es la integración continua. Esta garantiza que cada nuevo código pase la compilación y no rompa las pruebas existentes.

Almacenamiento en caché de dependencias de Gradle

Para acelerar la compilación, asegúrate de usar el almacenamiento en caché. Sin él, cada ejecución descargará todas las bibliotecas nuevamente.

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

Ejecución de pruebas y verificación de estilo

Añadamos pasos para ejecutar pruebas unitarias y el linter (detekt o ktlint). Esto ayudará a mantener la calidad del código.

- name: Run tests  run: ./gradlew test

- name: Run linter  run: ./gradlew detekt

Ejemplo de un workflow de CI completo para un proyecto Kotlin

jobs:  test:    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: Cache Gradle        uses: actions/cache@v3        with:          path: ~/.gradle/caches          key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle.kts') }}      - name: Build and test        run: ./gradlew check

Continuous Deployment: despliegue automático de aplicaciones Kotlin

Después de una integración exitosa, llega la etapa de despliegue. Para proyectos Kotlin, esto puede significar publicar una biblioteca en Maven Central, implementar un backend en un servidor o compilar un APK para Android.

Despliegue de un servicio backend con Ktor

Supongamos que tenemos una aplicación Kotlin con el framework Ktor. Queremos desplegarla automáticamente