Stacks Tecnológicos soportados en Plataforma CI/CD

Contenido

MAVEN

Características principales de los proyectos Maven

Apache Maven es una herramienta ampliamente utilizada en el desarrollo de software, particularmente en proyectos basados en Java. Su objetivo principal es simplificar y automatizar la gestión de diversos aspectos del desarrollo de software. A continuación, se describen las características más relevantes de esta herramienta:

1. Gestión de Dependencias

Maven facilita la gestión y descarga automática de las dependencias necesarias para un proyecto. Las dependencias son bibliotecas externas o herramientas que un proyecto requiere para su funcionamiento. Con Maven, es suficiente especificar las dependencias en el archivo de configuración del proyecto, y el sistema se encarga de localizarlas, descargarlas y mantenerlas actualizadas.

Por ejemplo:

  • Si se requiere una biblioteca para el envío de correos electrónicos, se incluye su referencia en el archivo POM, y Maven la gestiona automáticamente.
  • Adicionalmente, Maven verifica la compatibilidad entre dependencias y notifica acerca de actualizaciones disponibles, garantizando un ecosistema coherente.

2. Estandarización de Proyectos

Maven implementa una estructura estándar para los proyectos, lo que permite una organización clara y uniforme. Esta estructura facilita la comprensión del proyecto por parte de cualquier desarrollador, sin necesidad de explicaciones adicionales. Las principales carpetas estándar incluyen:

  • src/main/java: Contiene el código fuente principal.
  • src/test/java: Almacena las pruebas del proyecto.
  • src/main/resources: Incluye configuraciones y recursos adicionales.

El cumplimiento de esta estructura también facilita la integración con herramientas y sistemas externos que reconocen este esquema por defecto.

3. Automatización de Tareas Repetitivas

Maven automatiza tareas recurrentes que son comunes en el desarrollo de software, como:

  • Compilación: Traducción del código fuente en un programa ejecutable.
  • Pruebas: Ejecución de pruebas automáticas para garantizar la funcionalidad del código.
  • Empaquetado: Creación de archivos ejecutables o desplegables, como JAR o WAR.
  • Generación de documentación: Producción de documentación del proyecto basada en configuraciones predefinidas.

Estas tareas se ejecutan mediante comandos simples, como mvn compile o mvn package, optimizando el tiempo y reduciendo el riesgo de errores manuales.

 

4. Compatibilidad con Múltiples Proyectos

Maven permite gestionar proyectos que dependen de otros, facilitando la integración y el mantenimiento de sistemas complejos. Cuando un proyecto base es modificado, Maven asegura que los proyectos dependientes reflejen dichos cambios de forma adecuada.

Por ejemplo:

  • En sistemas modulares, Maven simplifica la sincronización entre módulos y garantiza la consistencia del entorno de desarrollo.

5. Sistema Basado en Plugins

Maven es altamente extensible gracias a su sistema de plugins. Los plugins permiten realizar tareas específicas dentro de un proyecto, tales como:

  • maven-compiler-plugin: Compilación del código fuente.
  • maven-surefire-plugin: Ejecución de pruebas automáticas.
  • maven-site-plugin: Generación de un sitio web con información y reportes del proyecto.

La flexibilidad de este sistema permite adaptar Maven a las necesidades específicas de cada proyecto.

6. El Archivo POM (Project Object Model)

El archivo POM (Project Object Model), denominado pom.xml, es el componente central de un proyecto Maven. Este archivo contiene toda la información necesaria para la configuración y gestión del proyecto, incluyendo:

  • Dependencias requeridas.
  • Configuración de plugins.
  • Perfiles para diferentes entornos (por ejemplo, desarrollo y producción).
  • Información sobre versiones de herramientas y librerías.

El archivo POM actúa como una guía que dirige el comportamiento de Maven en el proyecto.

7. Repositorio Central

Maven utiliza un Repositorio Central en línea que contiene una amplia gama de bibliotecas y herramientas disponibles para cualquier proyecto. Cuando se especifica una dependencia en el archivo POM, Maven la busca automáticamente en este repositorio y la descarga al proyecto.

Aspectos destacados:

  • Si una dependencia no está disponible en el repositorio central, es posible configurar repositorios locales o privados.
  • El uso de repositorios centralizados asegura la disponibilidad de versiones actualizadas y la consistencia en los proyectos.

Estructura del stack tecnológico 

El stack tecnológico de los proyectos Maven en este proceso CI/CD incluye:

  • Herramienta principal: Apache Maven, utilizado para la gestión de dependencias, construcción y ciclo de vida del proyecto.
  • Lenguaje de programación: Java
  • Configuración básica:
    • El archivo principal de configuración es el pom.xml.
    • Contiene información sobre dependencias, plugins, perfiles, y configuraciones del proyecto necesarias para su construcción, pruebas y despliegue.
    •  
  • Entorno de construcción: Los componentes del stack tecnológico deben ser dockerizados, utilizando imágenes de Docker que contengan la JDK adecuada y cualquier herramienta adicional necesaria para el pipeline.

1. Versiones soportadas

 

2. Frameworks soportados

Los frameworks específicos (por ejemplo, Spring, Hibernate, etc.) no tienen restricciones predefinidas en este contexto, pero sus versiones deben ser compatibles con el JDK y Maven configurados. Estas versiones se gestionan en el archivo pom.xml.

3. Artefactos generados

En los proyectos Maven solo será posible generar un artefacto, ya sea un JAR o un WAR, pero no ambos simultáneamente.

4. Configuración necesaria en el pipeline para hacer uso de Maven

La configuración necesaria del stack tecnológico para su ejecución en el pipeline desarrollado debe tener en cuenta:

Fichero ci.json: fichero de configuración que se debe incluir en la raíz del repositorio del proyecto. Este fichero va a estar conformados por los siguientes elementos

{
  "pipeline": {
    "stack": {
      "maven":{
        "pom_path": "ruta del fichero pom.xml",
        "JDKVersion": "versión del JDK de Java ",
        "mavenVersion": “versión de maven",
        "compileGoals": "tareas a ejecutar en el proceso de compilación"
      }
    },
    "deployTo": [""],
    "gitRepo":{
      "repoURL":"ruta del repositorio git",
      "repoID":"id del repositorio"
    },
    "artifactInfo":{
      "artifactName": "nombre del artifact",
      "artifactVersion":"versión del artifact"
    },
    "notifications": {
      "dev": "correo para enviar notificaciones",
      "notify_all_stages": true
    },
    "e2eFramework": [
    {
      "framework": "",
      "version": "",
      "test_path":""
    }
    ]
  },
  "environments": {
    "entorno a ejecutar el proceso": {
      "contenedores": {
        "namespace": "nombre del namespace del pipeline"
      }
    }
  }
}
  • maven: Indica que el stack tecnológico a utilizar, en este caso Maven. 
  • pom-path: Especifica la ruta del archivo pom.xml de Maven.
  • JDKVersion: Versión JDK a utilizar.
  • mavenVersion: Versión de maven a utilizar.
  • compile goals: describe las tareas específicas que se deben ejecutar durante la etapa de compilación de un flujo de CI/CD.
  • deployTo: Indica la plataforma de despliegue que se utiliza. 
  • gitRepo: URL del repositorio del proyecto
  • artifactInfo: información del artefacto de su nombre y versión. 
  • notifications: Configuración de las notificaciones del pipeline. 
  • e2eFramework: Se indica el framework de pruebas a usar.
  • environments: Configuración necesaria para cada entorno de trabajo disponible.

A continuación se presenta un ejemplo del fichero de configuración:

{
  "pipeline": {
    "stack": {
      "maven":{
        "pom_path": "./pom.xml",
        "JDKVersion": "OpenJDK 14.0.2",
        "mavenVersion": "Maven 3.6.3",
        "compileGoals": "clean install -DskipTests"
      }
    },
    "deployTo": ["tomcat8"],
    "gitRepo":{
      "repoURL":"https://fuentes.juntadeandalucia.es/oficina-impulso-devsecops/aplicaciones-tipo/pruebaswebapp.git",
      "repoID":"990"
    },
    "artifactInfo":{
      "artifactName": "pruebaswebapp",
      "artifactVersion":"1.0.3-SNAPSHOT"
    },
    "notifications": {
      "dev": "correo para enviar notificaciones",
      "notify_all_stages": true
    },
    "e2eFramework": [
    {
      "framework": "",
      "version": "",
      "test_path":""
    }
    ]
  },
  "environments": {
    "TEST": {
      "contenedores": {
        "namespace": "cadenaunica"
      }
    },
    "PRE": {
      "contenedores": {
        "namespace": "cadenaunica"
      }
    }
  }
}

5. Herramientas de análisis estático de código que se pueden usar con Maven

  • SonarQube: Tiene soporte completo para Java, permitiendo realizar análisis estático de código y generando reportes detallados sobre calidad y cobertura. La tarea genérica de SonarQube se adapta a Java configurando el sonar.propierties fichero que debe ubicarse en la carpeta raíz del proyecto. A continuación, se puede observar un ejemplo de este fichero:

    sonar.projectKey=oficina-impulso-devsecops.aplicaciones-tipo.pruebaswebapp
            sonar.projectName=pruebasWebApp
            sonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml
            sonar.sources=./src/main
            sonar.java.binaries=target/**
            sonar.junit.reportsPath=reports/java/surefire-reports
            sonar.host.url=https://intranet.chap.junta-andalucia.es/sonar
            sonar.exclusions= despliegue/**
            sonar.sourceEncoding=UTF-8

 

6. Normas adicionales

Para mejorar la calidad y mantenibilidad de los proyectos Java, se recomienda seguir las siguientes normas adicionales:

  • Uso de versiones cerradas: Se recomienda especificar versiones fijas de las dependencias en el archivo POM para evitar incompatibilidades derivadas de actualizaciones automáticas.
  • Evitar el uso de proyectos multimódulo: A menos que sea estrictamente necesario, se sugiere evitar la división de un proyecto en múltiples módulos, ya que esto puede generar complejidad innecesaria y dificultades en la gestión del ciclo de vida del proyecto.
  • Uso de pruebas automatizadas: Se debe garantizar que todos los proyectos cuenten con un porcentaje adecuado de pruebas unitarias y de integración para minimizar errores en tiempo de ejecución.

NodeJS

Node.js es un entorno de ejecución de JavaScript basado en el motor V8 de Google Chrome, que permite ejecutar código JavaScript en el servidor.

1. Estructura del stack tecnológico

Node.js incluye el entorno de ejecución de JavaScript y un amplio ecosistema de paquetes gestionados por NPM. Tanto la configuración del componente que se desarrolla, como la configuración de las dependencias se guardan en el archivo “package.json”.

1.1 NPM

NPM (Node Package Manager) es el gestor de paquetes predeterminado para Node.js. Fue creado como una herramienta para facilitar la gestión de dependencias en proyectos de JavaScript mediante el uso de un archivo llamado package.json. Las características principales de NPM son:

  • Instalación de paquetes: Permite instalar paquetes de software desde el registro de NPM.
  • Gestión de dependencias: Facilita la gestión de las dependencias de un proyecto gracias a la sección “dependencies" del archivo mencionado anteriormente.
1.2 package.json

Este archivo contiene información sobre el proyecto que se está desarrollando, incluyendo las dependencias necesarias para que funcione correctamente, a continuación se muestra un ejemplo:

{
  "name": "mi-proyecto",
  "version": "1.0.0",
  "description": "Un ejemplo de proyecto con Node.js y NPM",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "dependencies": {
    "express": "4.17.1",
    "mongoose": "5.12.3"
  },
  "author": "nombre.apellidos",
  "license": "ISC"
}
1.3 Entorno de construcción

Los componentes deben ser adaptados para funcionar en entornos de contenedores.

2. Versiones soportadas

Se soportan las versiones LTS (Long-term support) de Node, actualmente las versiones soportadas son 18.x, 20.x y 22.x. La versión de Node se indica a través del fichero de la imagen de contenedor especificada en el archivo configuración de CI, “ci.json”.

3. Artefactos generados

La compilación de un proyecto NodeJS puede generar varios tipos de archivos y carpetas, según la configuración especificada. Los más comunes son:

  • dist/ o build: Carpeta que contiene los archivos compilados y listos para su ejecución.
  • main.js: Archivo principal de la aplicación, que puede ser el punto de entrada para el servidor o la aplicación web.
  • Archivos CSS y HTML: Si el proyecto incluye componentes de frontend, la compilación puede generar archivos CSS y HTML.
  • Paquetes comprimidos (.tgz): creados con el comando npm pack.

La tarea de construcción (stage “node-build”) empaqueta estos artefactos siguiendo las instrucciones definidas en el archivo “package.json”.

4. Configuración necesaria en el pipeline para hacer uso de la tecnología

A continuación se va a indicar la configuración necesaria del repositorio para poder utilizar la tecnología.

4.1 Contenerización

Uso de una imagen de contenedor que contenga la versión deseada de Node.js, junto con herramientas de build y test.

4.2 Archivo ci.json

Este archivo es el encargado de indicar la configuración con la que se va a compilar el proyecto en el pipeline, a continuación se muestra un ejemplo:

{ 

  "pipeline": { 
    "stack": { 
      "node": { 
        "package_path": "./package.json", 
        "nodeVersion": "NodeJs 22.7.0", 
        "installCommand": "npm install --force", 
        "buildCommands": "npm run build:ci && npm pack", 
        "testCommands": "npm test" 
      } 
    }, 
    "deployTo": ["OpenShift"], 
    "gitRepo": { 
      "repoURL":"https://fuentes.juntadeandalucia.es/oficina-impulso-devsecops/aplicaciones-tipo/pruebaswebapp.git ", 
      "repoID": "4589" 
    }, 
    "notifications": { 
      "dev": "correo para enviar notificaciones ", 
      "notify_all_stages": true 
    }, 
    "e2eFramework": [ 
      { 
        "framework": "", 
        "version": "", 
        "test_path": "" 
      } 
    ], 
    "excludedTasks": [], 
    "update_data_model_required": false 
  }, 
  "environments": { 
    "TEST": { 
      "contenedores": { 
        "namespace": "test-plataforma-cicd" 
      } 
    }, 
    "PRE": { 
      "contenedores": { 
        "namespace": "pre-plataforma-cicd" 
      } 
    } 
  } 
  • stack: Indica que el stack tecnológico a utilizar, en este caso Node.  
  • Package path: ruta donde se encuentra le fichero package.json 
  • NodeVersion: versión de node a implementar. 
  • InstallCommand: comandos a ejecutar para instalar librerías necesarias en la compilación(opcional). 
  • BuildCommands: comandos a ejecutar. 
  • TestCommands: comandos a ejecutar para los test. 
  • notifications: Configuración de las notificaciones del pipeline.  
  • e2eFramework: Se indica el framework de pruebas a usar (opcional). 
  • environments: Configuración necesaria para cada entorno de trabajo disponible. 

5. Herramientas de análisis estático de código que se pueden usar con esta tecnología

El pipeline contiene la herramienta de análisis de código SonarQube.

5.1 SonarQube

SonarQube es una plataforma de código abierto para la inspección continua de la calidad del código. Analiza el código fuente para detectar errores y vulnerabilidades. Además proporciona informes detallados y métricas sobre la calidad y seguridad del código.

Para integrar Sonarqube hay que configurar el archivo “sonar.properties” en la raíz del proyecto, a continuación se muestra un ejemplo de este archivo:

sonar.projectKey=oficina-impulso-devsecops.aplicacion.mi-proyecto
sonar.projectName=mi-proyecto
sonar.sources=src
# Se excluyen node_modules y carpetas de test
sonar.exclusions=node_modules/**,src/main.ts,src/main.server.ts,src/app/app.routes.ts,src/app/app.config.ts,src/app/app.config.server.ts
# Se especifica que el lenguaje es NodeJS
sonar.language=js
# Se usa el plugin de SonarJS para el analisis
sonar.javascript.file.suffixes=.js,.jsx
# Si hay test unitarios se declaran aqui
sonar.tests=src/app
sonar.test.inclusions=**/src/app/**/*.spec.ts

PHP

PHP es un lenguaje de programación utilizado principalmente para aplicaciones web, es compatible con múltiples frameworks como Laravel, Symfony, y CodeIgniter.

1. Estructura del stack tecnológico

PHP es un lenguaje de programación de código abierto ampliamente utilizado para el desarrollo web. Su flexibilidad y capacidad para integrarse con diversas bases de datos lo hacen ideal para crear aplicaciones dinámicas. La configuración del entorno y las dependencias se gestionan a través de archivos como “composer.json”.

1.1 Composer

Composer es un gestor de dependencias para PHP. Facilita la instalación y actualización de bibliotecas y paquetes necesarios para un proyecto. Las características principales de Composer son:

  • Instalación de paquetes: Permite instalar paquetes desde repositorios externos, el repositorio principal de Composer es Packagist.
  • Gestión de dependencias: Facilita la gestión de las dependencias de un proyecto mediante la sección “require” del archivo composer.json.
1.2 composer.json

Este archivo contiene información sobre el proyecto, incluyendo las dependencias necesarias para su funcionamiento. A continuación se muestra un ejemplo:

{
    "name": "nombre/proyecto",
    "description": "Descripción del proyecto",
    "require": {
        "monolog/monolog": "2.0"
    }
}
1.3 Entorno de construcción

Los componentes deben ser ejecutados en entornos de contenedores usando imágenes específicas para PHP, incluyendo la versión del intérprete requerida y herramientas como Composer.

2. Versiones soportadas

Se soportan todas las versiones de PHP que estén activamente mantenidas, como la versión 8.0. La versión de PHP deseada se especifica en la imagen de contenedor utilizada.

3. Artefactos generados

Los artefactos generados por esta tecnología suelen ser archivos con el código fuente de la aplicación o paquetes listos para desplegar. La tarea de construcción del pipeline (php-build) empaqueta estos artefactos siguiendo las instrucciones definidas en los archivos de proyecto, como composer.json.

4. Configuración necesaria en el pipeline para hacer uso de la tecnología 

A continuación se va a indicar la configuración necesaria del repositorio para poder utilizar la tecnología.

4.1 Contenerización

Uso de una imagen de contenedor que conténgala versión necesaria de PHP junto a Composer y las extensiones deseadas.

4.2 Archivo ci.json

Este archivo es el encargado de indicar la configuración con la que se va a compilar el proyecto en el pipeline, a continuación se muestra un ejemplo:

{
  "pipeline": {
    "stack": {
	 # Tecnología a usar
      "php": {
	   # Ruta de archivo composer.json
        "composer-path": "/composer.json",
	   # Imagen a usar
        "docker-image-ci": "quay.apps.paas-ges-cica.junta-andalucia.es/ada/custom-docker-images:php-8.2"
      }
    },
    # Nombre del artefacto
    "artifactName": "simple-php-project",
    "deployTo": ["OpenShift"]
  }
}

5. Herramientas de análisis estático de código que se pueden usar con la tecnología

El pipeline contiene la herramienta de análisis de código SonarQube.

5.1 SonarQube

SonarQube es una plataforma de código abierto para la inspección continua de la calidad del código. Analiza el código fuente para detectar errores y vulnerabilidades. Además proporciona informes detallados y métricas sobre la calidad y seguridad del código.

Para integrar Sonarqube hay que configurar el archivo “sonar.properties” en la raíz del proyecto, a continuación se muestra un ejemplo de este archivo:

# Identificador único del proyecto
sonar.projectKey=oficina-impulso-devsecops.aplicaciones-tipo.php-test
sonar.projectName=php-test
# Nombre del proyecto
sonar.projectName=PHP Project
# Versión del proyecto
sonar.projectVersion=1.0
# Directorios de código fuente (obligatorio)
sonar.sources=src
# Directorios de prueba
sonar.tests=tests
# Exclusiones para ficheros o directorios
sonar.exclusions=**/vendor/**,**/.git/**,**/.github/**,**/node_modules/**
# Directorio del analisis
sonar.php.coverage.reportPaths=coverage/clover.xml

 

Índice