Conceptos básicos de CI/CD: Objetivo y beneficios

La Integración Continua (CI) es el proceso mediante el cual los desarrolladores incorporan con frecuencia sus cambios en un repositorio compartido. Cada integración se verifica mediante la ejecución automática de pruebas y compilaciones, lo que ayuda a detectar errores de forma temprana.

Por otro lado, el Despliegue Continuo (CD) se enfoca en automatizar la entrega del código validado a entornos de producción o preproducción. Una vez que el código pasa las pruebas automatizadas de CI, se despliega automáticamente.

Los objetivos principales de CI/CD incluyen aumentar la eficiencia del equipo, mejorar la calidad del software y acelerar el proceso de entrega.

Entre los beneficios clave de implementar CI/CD se encuentran:

• Detección temprana de errores: Al integrar y probar cambios continuamente, se identifican problemas antes de que se conviertan en incidencias mayores.
• Entrega más rápida: La automatización acelera el ciclo de desarrollo, permitiendo que nuevas características y correcciones lleguen antes a los usuarios.
• Mayor calidad del producto: Las pruebas automatizadas garantizan que el código cumpla con los estándares establecidos.
• Feedback continuo: Se obtiene retroalimentación constante de las integraciones y despliegues.
• Reducción de costos: Al optimizar procesos y minimizar errores, se disminuyen los gastos asociados con el retrabajo y el mantenimiento.

Implementar CI/CD requiere una infraestructura adecuada y el uso de herramientas que soporten la automatización de procesos. Plataformas como GitHub Actions proporcionan un entorno integrado para configurar workflows que desencadenan tareas automáticamente ante eventos específicos, como commits o pull requests.

Creación de workflows: Estructura YAML y triggers (push, pull_request)

En GitHub Actions, los workflows se definen mediante archivos en formato YAML que se ubican en el directorio .github/workflows del repositorio. Estos archivos describen una serie de jobs y steps que se ejecutan en respuesta a ciertos triggers o eventos específicos.

La estructura básica de un workflow incluye los siguientes elementos:

• name: Nombre descriptivo del workflow.
• on: Define los triggers que activan el workflow.
• jobs: Contiene uno o varios jobs que realizan tareas específicas.

A continuación, se muestra un ejemplo sencillo de un workflow:

name: CI

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

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Comprobar código fuente
      uses: actions/checkout@v3

    - name: Configurar Java
      uses: actions/setup-java@v3
      with:
        java-version: '17'

    - name: Compilar y probar
      run: mvn install

En este ejemplo, el workflow llamado CI se activa con los triggers push y pull_request sobre la rama main. El workflow define un job llamado build que se ejecuta en un entorno ubuntu-latest y consta de varios steps:

1. Comprobar código fuente: Utiliza la acción oficial actions/checkout@v3 para obtener el código del repositorio.
2. Configurar Java: Establece la versión de Java requerida usando actions/setup-java@v3.
3. Compilar y probar: Ejecuta el comando mvn install para compilar y ejecutar las pruebas del proyecto.

Los triggers son fundamentales para determinar cuándo se ejecuta un workflow. Los triggers más comunes son:

• push: Se activa cuando se realizan commits en determinadas ramas o etiquetas.
• pull_request: Se activa cuando se abre, actualiza o cierra un pull request.

Se puede especificar sobre qué ramas o etiquetas se quieren activar los triggers:

on:
  push:
    branches:
      - main
      - 'feature/*'
    tags:
      - 'v1.*'

En este caso, el workflow se activa con un push en la rama main, en cualquier rama que comience con feature/ o al crear una etiqueta que comience con v1..

Además de push y pull_request, existen otros triggers que pueden ser útiles:

• workflow_dispatch: Permite ejecutar el workflow de forma manual desde la interfaz de GitHub.
• schedule: Programa la ejecución del workflow usando expresiones cron.
• repository_dispatch: Se activa mediante una llamada a la API de GitHub.

Por ejemplo, para ejecutar el workflow diariamente a medianoche:

on:
  schedule:
    - cron: '0 0 * * *'

Los jobs contienen los pasos necesarios para realizar las tareas del workflow. Cada step puede usar una acción existente o ejecutar comandos directamente:

• uses: Indica que se utilizará una acción compartida o una acción del repositorio.
• run: Ejecuta un comando de shell directamente en el runner.

Se pueden utilizar acciones del Marketplace de GitHub Actions o crear acciones personalizadas. Por ejemplo, para agregar un step que analice el código con SonarCloud:

- name: Análisis estático con SonarCloud
  uses: sonarsource/sonarcloud-github-action@v1.10
  with:
    args: >
      -Dsonar.projectKey=mi-proyecto
      -Dsonar.organization=mi-organizacion
      -Dsonar.host.url=https://sonarcloud.io

En la configuración del archivo YAML hay que tener cuidado con la indentación y a la sintaxis. Un error en la estructura puede causar que el workflow no se ejecute como se espera.

Además, se pueden definir variables de entorno y utilizar estrategias para ejecutar jobs en diferentes matrices de configuraciones:

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        java: [11, 17]
    steps:
      - name: Configurar Java ${{ matrix.java }}
        uses: actions/setup-java@v3
        with:
          java-version: ${{ matrix.java }}

En este ejemplo, el job build se ejecutará dos veces, una con Java 11 y otra con Java 17, gracias al uso de la matriz definida en strategy.

Finalmente, los workflows pueden depender de otros jobs utilizando la clave needs y establecer condiciones con if:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      # Pasos de pruebas
  deploy:
    runs-on: ubuntu-latest
    needs: test
    if: github.ref == 'refs/heads/main'
    steps:
      # Pasos de despliegue

Aquí, el job deploy se ejecutará solamente si el job test ha finalizado correctamente y si la rama es main.

Ejemplos de pipelines: Pruebas automáticas, build, lint

Pruebas automáticas

La ejecución de pruebas automáticas permite verificar que el código funciona correctamente y que las nuevas modificaciones no introducen errores. A continuación, se muestra un ejemplo de workflow que ejecuta pruebas cuando se realizan cambios en la rama main:

name: Pruebas Automáticas

on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Obtener código fuente
        uses: actions/checkout@v3

      - name: Configurar entorno
        run: |
          # Instalación de dependencias necesarias
          sudo apt-get update
          sudo apt-get install -y [paquetes necesarios]

      - name: Ejecutar pruebas
        run: |
          # Comando para ejecutar pruebas
          ./run_tests.sh

En este workflow, el trabajo test consta de los siguientes pasos:

1. Obtener código fuente: Se utiliza la acción actions/checkout@v3 para clonar el repositorio en el runner.

2. Configurar entorno: Se preparan las dependencias necesarias para ejecutar las pruebas.

3. Ejecutar pruebas: Se ejecutan las pruebas automáticas mediante un script o comando específico.

Es importante personalizar los comandos según las necesidades del proyecto. Por ejemplo, si se trata de un proyecto en Python, el paso de configuración podría incluir la instalación de paquetes con pip, y la ejecución de pruebas podría realizarse con pytest:

      - name: Configurar Python
        uses: actions/setup-python@v3
        with:
          python-version: '3.10'

      - name: Instalar dependencias
        run: pip install -r requirements.txt

      - name: Ejecutar pruebas
        run: pytest

Build (compilación)

El proceso de build se encarga de compilar el código fuente y preparar los artefactos necesarios para el despliegue. A continuación, se muestra un ejemplo de workflow para un proyecto en Java utilizando Maven:

name: Build del Proyecto

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Obtener código fuente
        uses: actions/checkout@v3

      - name: Configurar Java
        uses: actions/setup-java@v3
        with:
          java-version: '17'

      - name: Compilar proyecto
        run: mvn clean package

      - name: Almacenar artefactos
        uses: actions/upload-artifact@v3
        with:
          name: app.jar
          path: target/app.jar

En este pipeline, se realizan los siguientes pasos:

1. Obtener código fuente: Clona el repositorio para acceder al código.

2. Configurar Java: Establece la versión de Java necesaria para el proyecto.

3. Compilar proyecto: Ejecuta mvn clean package para compilar y empaquetar la aplicación.

4. Almacenar artefactos: Utiliza actions/upload-artifact@v3 para guardar el archivo app.jar generado, permitiendo su uso en otros jobs o su descarga posterior.

Para proyectos en otros lenguajes, el paso de compilación variará. Por ejemplo, en un proyecto de Node.js, se podría utilizar:

- name: Instalar dependencias
  run: npm install

- name: Compilar proyecto
  run: npm run build

Análisis estático (Lint)

El análisis estático o linting permite detectar problemas de estilo, errores potenciales y mejorar la calidad del código. A continuación, se presenta un ejemplo de workflow que ejecuta el linter en cada push:

name: Análisis de Código

on:
  push:
    branches: [ main ]

jobs:
  lint:
    runs-on: ubuntu-latest

    steps:
      - name: Obtener código fuente
        uses: actions/checkout@v3

      - name: Instalar Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Instalar dependencias
        run: npm install

      - name: Ejecutar linter
        run: npm run lint

En este caso:

1. Obtener código fuente: Clona el repositorio.

2. Instalar Node.js: Configura el entorno con la versión de Node.js requerida.

3. Instalar dependencias: Ejecuta npm install para instalar los paquetes necesarios.

4. Ejecutar linter: Corre el comando npm run lint, que debe estar definido en el package.json del proyecto.

Para proyectos en Python, se podría utilizar Flake8 o Pylint:

- name: Configurar Python
  uses: actions/setup-python@v3
  with:
    python-version: '3.10'

- name: Instalar linter
  run: pip install flake8

- name: Ejecutar linter
  run: flake8 .

Combinando pruebas, build y lint

Es posible combinar estas tareas en un único workflow o separarlas en jobs independientes dentro del mismo archivo YAML. A continuación, se muestra un ejemplo que incluye los tres procesos para un proyecto en JavaScript:

name: CI Pipeline

on:
  push:
    branches: [ main ]

jobs:
  lint:
    runs-on: ubuntu-latest

    steps:
      - name: Obtener código fuente
        uses: actions/checkout@v3

      - name: Instalar Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Instalar dependencias
        run: npm install

      - name: Ejecutar linter
        run: npm run lint

  test:
    runs-on: ubuntu-latest
    needs: lint

    steps:
      - name: Obtener código fuente
        uses: actions/checkout@v3

      - name: Instalar Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Instalar dependencias
        run: npm install

      - name: Ejecutar pruebas
        run: npm test

  build:
    runs-on: ubuntu-latest
    needs: test

    steps:
      - name: Obtener código fuente
        uses: actions/checkout@v3

      - name: Instalar Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Instalar dependencias
        run: npm install

      - name: Compilar aplicación
        run: npm run build

      - name: Almacenar artefactos
        uses: actions/upload-artifact@v3
        with:
          name: build
          path: build/

En este workflow:

• El job lint se ejecuta primero, analizando el código.
• El job test depende de lint (needs: lint) y se ejecuta solo si el linter no detectó problemas.
• El job build depende de test y se ejecuta únicamente si las pruebas automáticas pasan correctamente.

Notificaciones y reportes

Es posible agregar pasos para enviar notificaciones o generar reportes de los resultados de las ejecuciones. Por ejemplo, para enviar un mensaje en Slack en caso de fallo:

- name: Notificar en Slack
  if: failure()
  uses: slackapi/slack-github-action@v1.23.0
  with:
    payload: |
      {
        "text": "La build ha fallado en el commit ${{ github.sha }}."
      }

Uso de herramientas de terceros

Se pueden integrar herramientas como SonarCloud para análisis más profundos, o servicios como Codecov para medir la cobertura de código:

- name: Enviar cobertura a Codecov
  uses: codecov/codecov-action@v3
  with:
    token: ${{ secrets.CODECOV_TOKEN }}

Es muy importante manejar los secretos y variables de forma segura, utilizando GitHub Secrets.

Ejemplo completo aquí:

Manejo de secretos y variables: Configuración segura en GitHub

Secretos en GitHub Actions

Los secretos son valores cifrados que se almacenan en GitHub y pueden ser referenciados en los workflows. Al utilizar secretos, se evita que información confidencial quede expuesta en el repositorio o en los logs de ejecución.

Configuración de secretos

Para configurar secretos en un repositorio:

1. Acceder a la pestaña Settings del repositorio en GitHub.
2. Navegar a Secrets and variables y seleccionar Actions.
3. En el apartado Repository secrets, hacer clic en New repository secret.
4. Introducir un Nombre descriptivo y el Valor del secreto.
5. Guardar el secreto haciendo clic en Add secret.

Uso de secretos en workflows

Una vez configurados, los secretos pueden ser utilizados en los archivos YAML de los workflows. Se accede a ellos mediante la sintaxis ${{ secrets.NOMBRE_SECRETO }}. Por ejemplo:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Desplegar aplicación
        run: |
          some-deploy-command --token ${{ secrets.DEPLOY_TOKEN }}

En este ejemplo, el secreto DEPLOY_TOKEN se utiliza como parámetro en un comando de despliegue, garantizando que el token no se exponga en el código.

Variables en GitHub Actions

Además de los secretos, GitHub Actions permite definir variables que pueden ser utilizadas en los workflows. Las variables son útiles para almacenar valores que no son sensibles pero que pueden cambiar según el entorno o la configuración.

Definición de variables

Las variables se pueden definir en diferentes niveles:

• Variables de repositorio: Accesibles en todos los workflows del repositorio.
• Variables de entorno del job: Definidas dentro de un job específico.
• Variables de entorno del paso: Definidas dentro de un step.

Para definir variables de repositorio:

1. Ir a Settings del repositorio.
2. Seleccionar Secrets and variables y luego Actions.
3. En Repository variables, hacer clic en New repository variable.
4. Asignar un Nombre y un Valor a la variable.
5. Guardar la variable con Add variable.

Las variables se referencian en los workflows utilizando ${{ vars.NOMBRE_VARIABLE }}.

Uso de variables en workflows

Las variables se pueden utilizar para parametrizar comandos o configuraciones:

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      APP_ENV: ${{ vars.ENTORNO }}
    steps:
      - name: Construir aplicación
        run: build-command --env $APP_ENV

En este caso, la variable ENTORNO define el entorno de construcción y se asigna a la variable de entorno APP_ENV.

Mejorando la seguridad en workflows

Para asegurar que los secretos y variables se manejen correctamente:

• No imprimir los valores: Evitar utilizar comandos que puedan mostrar los valores de secretos en los logs, como echo ${{ secrets.SECRET_KEY }}.
• Limitar el acceso: Configurar permisos adecuados para que solo usuarios autorizados puedan ver o modificar los secretos y variables.
• Rotar los secretos: Actualizar periódicamente los valores de los secretos para reducir riesgos en caso de compromisos.

Acceso a secretos y variables desde acciones

En algunas situaciones, es necesario pasar secretos o variables a acciones que dependen de ellos. Por ejemplo, al autenticarse en Docker:

      - name: Autenticarse en Docker Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

Aquí, se utiliza el secreto integrado GITHUB_TOKEN que GitHub proporciona automáticamente a cada workflow y que permite interactuar con la API de GitHub de forma segura.

Utilización de contextos

GitHub Actions proporciona contextos que permiten acceder a información dinámica en los workflows. Los contextos relevantes para secretos y variables incluyen:

• secrets: Acceso a los secretos definidos.
• vars: Acceso a las variables de repositorio.
• env: Acceso a las variables de entorno.

Por ejemplo, para utilizar una variable de entorno en un step:

- name: Ejecutar script
  env:
    API_URL: ${{ vars.API_ENDPOINT }}
  run: script.sh

Proteger secretos en forks y pull requests

Es importante tener en cuenta que, por razones de seguridad, los secretos no están disponibles en workflows que se ejecutan a partir de pull requests desde forks. Esto evita que usuarios malintencionados puedan acceder a los secretos mediante modificaciones al código del workflow.

Si es necesario trabajar con forks, se pueden utilizar estrategias alternativas, como utilizar variables en lugar de secretos, o configurar los workflows para que se ejecuten únicamente en ramas internas.

Buenas prácticas

Para garantizar una gestión eficiente y segura de secretos y variables:

• Utilizar nombres consistentes: Establecer convenciones de nomenclatura para facilitar el mantenimiento.
• Documentar: Mantener registros sobre qué secretos y variables existen y para qué se utilizan.
• Revisar permisos: Verificar que los workflows y acciones tienen los mínimos privilegios necesarios.

Ejemplo práctico

Supongamos que se necesita desplegar una aplicación a un servicio en la nube que requiere una clave API. Primero, se agrega la clave como un secreto en el repositorio con el nombre CLOUD_API_KEY. Luego, se utiliza en el workflow:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Desplegar a la nube
        run: cloud-deploy --api-key ${{ secrets.CLOUD_API_KEY }}

De esta manera, la clave API se utiliza sin exponerla públicamente y se mantiene en un entorno seguro.

Caso práctico: creación de workflow para proyecto API REST Spring Boot

En este caso práctico, se mostrará cómo crear un workflow de GitHub Actions para automatizar la integración continua de una aplicación API REST desarrollada con Spring Boot. El objetivo es configurar un pipeline que compile el proyecto, ejecute las pruebas unitarias y realice el análisis de calidad del código cada vez que se realice un push o se abra un pull request en el repositorio.

Antes de comenzar, es necesario asegurarse de que el repositorio de GitHub contiene el código fuente del proyecto Spring Boot y que se utiliza Maven como herramienta de construcción. También se deben definir las dependencias y los scripts necesarios en el archivo pom.xml.

Para crear el workflow, se debe añadir un archivo YAML en el directorio .github/workflows/, por ejemplo, .github/workflows/ci.yml. Este archivo contendrá la configuración del pipeline de integración continua.

El contenido del archivo ci.yml será el siguiente:

name: CI Spring Boot

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

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Obtener código
      uses: actions/checkout@v3

    - name: Configurar Java
      uses: actions/setup-java@v3
      with:
        distribution: 'temurin'
        java-version: '17'
        cache: maven

    - name: Configurar caché de Maven
      uses: actions/cache@v3
      with:
        path: ~/.m2/repository
        key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
        restore-keys: |
          ${{ runner.os }}-maven-

    - name: Compilar y ejecutar pruebas
      run: mvn clean verify

    - name: Publicar resultados de pruebas
      if: always()
      uses: actions/upload-artifact@v3
      with:
        name: informes-pruebas
        path: target/surefire-reports/

    - name: Análisis de calidad con SonarCloud
      uses: SonarSource/sonarcloud-github-action@v1
      env:
        SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
      with:
        args: >
          -Dsonar.projectKey=mi-organizacion_mi-proyecto
          -Dsonar.organization=mi-organizacion

Ahora, se procederá a explicar cada parte del workflow:

Se asigna el nombre CI Spring Boot al workflow para identificarlo en GitHub.

En la sección on, se definen los triggers push y pull_request en la rama main, de modo que el workflow se ejecute al hacer un push o abrir un pull request hacia main.

En jobs, se especifica un único job llamado build que realizará las acciones necesarias.

En cuanto a los steps del job build:

1. Obtener código: Se utiliza la acción actions/checkout@v3 para clonar el repositorio en el runner.

2. Configurar Java: Se configura el entorno de Java usando la distribución Temurin versión 17 y se habilita la caché para acelerar las construcciones futuras.

3. Configurar caché de Maven: Se emplea actions/cache@v3 para almacenar en caché el directorio local de dependencias de Maven (~/.m2/repository). Esto reduce el tiempo de construcción al reutilizar las librerías ya descargadas.

4. Compilar y ejecutar pruebas: Se ejecuta el comando mvn clean verify para compilar el proyecto y correr las pruebas unitarias definidas.

5. Publicar resultados de pruebas: Se utiliza actions/upload-artifact@v3 para subir los informes generados de las pruebas, lo que permite su revisión posterior si es necesario.

6. Análisis de calidad con SonarCloud: Se ejecuta el análisis estático utilizando SonarCloud, para lo cual es necesario tener configurado el proyecto en la plataforma y haber creado un token de acceso.

Para que el análisis con SonarCloud funcione correctamente, se debe agregar el secreto SONAR_TOKEN al repositorio:

Ir a Settings > Secrets and variables > Actions.

Crear un nuevo secreto llamado SONAR_TOKEN y pegar el valor del token generado en SonarCloud.

En el paso del análisis, se proporcionan argumentos específicos:

with:
  args: >
    -Dsonar.projectKey=mi-organizacion_mi-proyecto
    -Dsonar.organization=mi-organizacion

Se deben reemplazar mi-organizacion y mi-proyecto por los nombres correspondientes en SonarCloud. Además, es posible añadir más parámetros para configurar el análisis según las necesidades del proyecto.

Una vez creado y configurado el archivo ci.yml, al realizar un push al repositorio, se activará el workflow automáticamente. Se puede verificar el estado de la ejecución en la pestaña Actions del repositorio en GitHub.

Si alguna de las etapas del pipeline falla, GitHub Actions notificará sobre el error y proporcionará los logs detallados. Es posible revisar los pasos y corregir los problemas detectados, como fallos en las pruebas unitarias o errores de compilación.

Se pueden agregar pasos adicionales al pipeline para cubrir más aspectos del desarrollo, como la verificación de estilo de código integrando herramientas como Checkstyle o SpotBugs, o la generación de reportes de cobertura utilizando plugins como JaCoCo.

Si se quiere probar el proyecto con diferentes versiones de Java, se puede utilizar la matriz en el workflow, modificando la sección de strategy:

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        java-version: [11, 17]
    steps:
      - name: Configurar Java ${{ matrix.java-version }}
        uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: ${{ matrix.java-version }}
          cache: maven
      # Resto de pasos

Esto hará que el job build se ejecute con cada versión especificada en la matriz, garantizando la compatibilidad del proyecto con múltiples versiones de Java.

Al finalizar, se habrá configurado un workflow completo para un proyecto API REST con Spring Boot.