Pipeline de PALO IT para la calidad de Código
- Etzael Henaro (Unlicensed)
- Ángeles Díaz (Unlicensed)
En este documento se describirán las tareas que se ejecutan en el pipeline de PALO IT para garantizar la calidad del código que se desarrollará.
stateDiagram-v2
[*] --> Checkout_SCM
Checkout_SCM --> Horusec_SAST_Scan
Horusec_SAST_Scan --> Build_Application
Build_Application --> Unit_Test_Application
Unit_Test_Application --> SonarQube_Scan
SonarQube_Scan --> AA
AA : Archive_Artifacts
AA --> [*]Checkout SCM
El paso de Checkout CSM en Jenkins es utilizado para obtener el código fuente de un sistema de gestión de configuración (CSM, por sus siglas en inglés) y agregarlo al espacio de trabajo del proyecto en Jenkins. El propósito principal de este paso es permitir la construcción y el despliegue automatizados del código fuente.
Cuando se agrega un paso de Checkout CSM en Jenkins, generalmente se especifica el tipo de CSM que se está utilizando, como Git, Subversion (SVN) o Mercurial. Luego, se proporciona la URL del repositorio que contiene el código fuente.
Cuando se ejecuta el paso de Checkout CSM, Jenkins se conecta al repositorio CSM correspondiente y descarga el código fuente en el espacio de trabajo del proyecto. Esto permite que las etapas posteriores del flujo de trabajo, como compilación, pruebas y despliegue, accedan al código fuente y realicen las acciones necesarias.
Además de descargar el código fuente, el paso de Checkout CSM también puede realizar otras acciones, como la autenticación del usuario que realiza la descarga, la especificación de una rama o etiqueta específica del repositorio, o la actualización del código fuente a una revisión o versión específica.
En resumen, el paso de Checkout CSM en Jenkins se encarga de obtener el código fuente desde un repositorio CSM y colocarlo en el espacio de trabajo del proyecto, lo que permite la automatización del proceso de construcción y despliegue del código.
Horusec SAST Scan
El paso de Horusec SAST Scan en Jenkins se utiliza para realizar un análisis estático de seguridad de aplicaciones (SAST, por sus siglas en inglés) utilizando la herramienta Horusec. Este paso tiene como objetivo identificar vulnerabilidades de seguridad en el código fuente de la aplicación y proporcionar información sobre posibles riesgos y brechas de seguridad.
Cuando se agrega un paso de Horusec SAST Scan en Jenkins, generalmente se configuran ciertos parámetros, como la ubicación del código fuente de la aplicación y las reglas de análisis a aplicar. También es posible definir las salidas deseadas, como la generación de informes o la acción a tomar en caso de encontrar vulnerabilidades críticas.
Durante la ejecución del paso de Horusec SAST Scan, Jenkins invoca la herramienta Horusec, que realiza un análisis estático del código fuente en busca de posibles problemas de seguridad. La herramienta Horusec examina el código en busca de patrones y vulnerabilidades conocidas, como inyecciones de SQL, ataques de cross-site scripting (XSS), configuraciones inseguras, uso de funciones o bibliotecas desactualizadas, entre otros.
Una vez finalizado el análisis, el paso de Horusec SAST Scan proporciona un informe detallado con los resultados encontrados, incluyendo las vulnerabilidades detectadas y su gravedad. Esto permite a los desarrolladores y equipos de seguridad tomar acciones correctivas para abordar las vulnerabilidades y mejorar la seguridad de la aplicación.
En resumen, el paso de Horusec SAST Scan en Jenkins se utiliza para ejecutar análisis estáticos de seguridad en el código fuente de una aplicación utilizando la herramienta Horusec. Ayuda a identificar vulnerabilidades y proporciona informes detallados para tomar medidas correctivas y mejorar la seguridad de la aplicación.
Build Application
En el paso de Build Application de Jenkins utilizando Java 17, se compila y construye la aplicación Java utilizando la versión 17 del lenguaje Java.
Para configurar el paso de Build Application en Jenkins, se deben especificar los parámetros necesarios para compilar y construir la aplicación Java. Esto puede incluir el directorio del código fuente, las dependencias externas, las opciones de compilación y cualquier otro requisito específico del proyecto.
Durante la ejecución del paso de Build Application, Jenkins utiliza el compilador de Java 17 para compilar el código fuente de la aplicación. Esto implica verificar la sintaxis y semántica del código, resolver las dependencias y generar los archivos binarios necesarios para ejecutar la aplicación.
Unit Test Application
En el paso de Unit Test Application de Jenkins utilizando Java 17 y JUnit, se ejecutan pruebas unitarias en la
aplicación Java utilizando el framework de pruebas JUnit en su versión compatible con Java 17.
Para configurar el paso de Unit Test Application en Jenkins, se deben proporcionar los parámetros necesarios para ejecutar las pruebas unitarias de la aplicación. Esto incluye el directorio de los archivos de prueba, las dependencias requeridas para las pruebas y cualquier configuración adicional específica del proyecto.
Durante la ejecución del paso de Unit Test Application, Jenkins utiliza JUnit junto con el entorno de ejecución de Java 17 para ejecutar las pruebas unitarias definidas en la aplicación. JUnit proporciona una estructura y API para escribir y ejecutar pruebas.
Durante la ejecución de las pruebas unitarias, Jenkins recopila los resultados y proporciona información sobre el estado de las pruebas, incluyendo la cantidad de pruebas pasadas, falladas o ignoradas, así como también la cobertura de código alcanzada por las pruebas.
Basándose en los resultados de las pruebas, Jenkins puede realizar acciones adicionales, como generar informes de pruebas, notificar a los miembros del equipo sobre el estado de las pruebas o incluso detener la construcción en caso de que alguna prueba falle.
SonarQube Scan
En el paso de SonarQube de Jenkins utilizando Java 17, se realiza un análisis estático del código fuente de la
aplicación Java utilizando SonarQube, una herramienta de análisis de calidad de código.
Durante la ejecución del paso de SonarQube, Jenkins utiliza SonarQube junto con el entorno de tiempo de ejecución de Java 17 para analizar el código fuente de la aplicación. SonarQube examina el código en busca de problemas de calidad y mejores prácticas, como duplicación de código, complejidad excesiva, vulnerabilidades de seguridad, incumplimiento de estándares de codificación, entre otros.
Una vez finalizado el análisis, SonarQube genera un informe detallado que muestra los problemas identificados y proporciona métricas de calidad del código. Estas métricas incluyen la cobertura de código, el número de problemas encontrados y el cumplimiento de los estándares definidos.
El paso de SonarQube en Jenkins también puede realizar acciones adicionales, como generar informes de calidad del código, establecer umbrales de calidad para detener la construcción en caso de incumplimiento y enviar notificaciones a los miembros del equipo sobre los resultados del análisis.
Archive Artifacts
En el paso de Archive Artifacts de Jenkins utilizando Java 17, se realiza la tarea de archivar los artefactos generados durante el proceso de construcción de la aplicación Java.
Cuando se configura el paso de Archive Artifacts en Jenkins, se especifica qué archivos o directorios deben ser archivados como artefactos. Estos artefactos pueden ser archivos binarios, como JAR, WAR o ZIP, o cualquier otro tipo de archivo generado durante la construcción de la aplicación.
Durante la ejecución del paso de Archive Artifacts, Jenkins identifica los archivos o directorios especificados y los comprime en un archivo empaquetado. Este archivo empaquetado se almacena en un lugar específico, generalmente en el servidor de Jenkins, y se conserva para su posterior uso o distribución.
Los artefactos archivados pueden ser utilizados en etapas posteriores del flujo de trabajo, como el despliegue en entornos de pruebas o producción, o pueden ser descargados por los miembros del equipo para su revisión o distribución.
Además de archivar los artefactos, el paso de Archive Artifacts también puede realizar acciones adicionales, como establecer restricciones de almacenamiento para limitar el número de versiones archivadas o configurar notificaciones para informar a los miembros del equipo sobre la disponibilidad de los artefactos.
Aprobación y consideraciones para subir código a repostorios de SPIN
