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

Introducción: Por qué CI/CD es el estándar del desarrollo Java moderno

En el mundo del desarrollo Java, la velocidad y la calidad de la entrega del código son críticas. Cada día, los equipos realizan cientos de cambios, y sin automatización, el proceso de integración se convierte en un caos. CI/CD (Integración Continua / Despliegue Continuo) resuelve este problema: el código se compila, prueba y despliega automáticamente en los servidores.

La herramienta GitHub Actions es una solución integrada de CI/CD directamente en el repositorio. Permite crear pipelines (workflows) en YAML que reaccionan a push, pull request u otros eventos. En este artículo, analizaremos el ciclo completo de configuración de CI/CD para un proyecto Java: desde la compilación básica hasta el despliegue en la nube.

Aprenderá cómo acelerar el desarrollo, evitar errores y automatizar las tareas rutinarias. ¡Comencemos!

1. Fundamentos de GitHub Actions: estructura de un workflow

¿Qué es GitHub Actions?

GitHub Actions es una plataforma para automatizar flujos de trabajo. Un workflow (flujo de trabajo) es un conjunto de pasos que se ejecutan cuando ocurre un evento (por ejemplo, un push a la rama main). Cada workflow consta de:

\n
• Event — desencadenante (push, pull_request, schedule).
\n
• Jobs — tareas que se ejecutan en máquinas virtuales (runner).
\n
• Steps — acciones concretas (ejecutar un script, instalar dependencias).
\n

Para un proyecto Java, un workflow típico incluye: descargar el código, instalar JDK, compilar con Maven/Gradle, ejecutar pruebas y publicar artefactos.

Creación del primer workflow para Java

Cree en la raíz del repositorio la carpeta .github/workflows/ y el archivo ci.yml. Aquí hay un ejemplo mínimo para un proyecto Maven:

name: Java CI with Maven\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@v4\n    - name: Set up JDK 17\n      uses: actions/setup-java@v4\n      with:\n        java-version: '17'\n        distribution: 'temurin'\n    - name: Build with Maven\n      run: mvn clean compile\n    - name: Run tests\n      run: mvn test

Este workflow se ejecuta al hacer push o pull request en main. Verifica que el código compile y que las pruebas pasen. Si una prueba falla, el workflow termina con error y usted recibe una notificación.

2. Configuración avanzada: almacenamiento en caché, matrices y artefactos

Almacenamiento en caché de dependencias

Maven y Gradle descargan las dependencias cada vez desde cero, lo cual es lento. GitHub Actions admite el almacenamiento en caché. Agregue un paso con actions/cache:

- name: Cache Maven packages\n  uses: actions/cache@v4\n  with:\n    path: ~/.m2/repository\n    key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}\n    restore-keys: |\n      ${{ runner.os }}-maven-

La clave de caché se basa en el hash de pom.xml. Si el archivo no ha cambiado, las dependencias se restauran desde la caché, reduciendo el tiempo de compilación en 2-3 veces.

Matriz de compilaciones (Matrix Build)

Los proyectos Java a menudo se prueban en varias versiones de JDK y sistemas operativos. Utilice la estrategia matrix:

jobs:\n  test:\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        java: [11, 17, 21]\n    steps:\n    - uses: actions/checkout@v4\n    - name: Set up JDK ${{ matrix.java }}\n      uses: actions/setup-java@v4\n      with:\n        java-version: ${{ matrix.java }}\n        distribution: 'temurin'\n    - name: Test with Maven\n      run: mvn test

GitHub creará 3 trabajos paralelos: para Java 11, 17 y 21. Esto garantiza la compatibilidad del código con diferentes versiones de JDK.

Guardar artefactos

Después de la compilación, el archivo JAR se puede guardar como un artefacto para descargarlo manualmente o usarlo en el siguiente trabajo:

- name: Upload JAR artifact\n  uses: actions/upload-artifact@v4\n  with