por Juan Felipe Becerra, el 23 de junio de 2020
Para realizar esta Lección se debe tener lista la configuración inicial de Jenkins, sigue los pasos que te proporcionamos en la Lección Cómo instalar Jenkins utilizando Docker, que se enfoca en los ajustes previos para poder empezar utilizar Jenkins.
Una vez configurada la etapa build del pipeline (Lección 1) procedemos con la construcción de la etapa Scan, en esta podremos realizar un análisis del código que abarca temas desde mantenibilidad hasta cobertura desde pruebas unitarias.
Stage: Scan
En esta stage debemos interactuar con SonarQube, sonar es una herramienta de revisión automática de código, la cual permite detectar errores y vulnerabilidades.
Iniciaremos realizando la configuración desde Jenkins a Sonar, para esto ejecutamos los siguientes pasos, comenzando por agregar los plugins
1. Haz clic en “Administración Jenkins” y después en “Administrar Plugins”, asegúrate de tener instalados los plugins de sonar necesarios:
SonarQube Scanner for Jenkins
Quality Gates Plugin
De no tenerlos por favor instala ambos, luego reinicia Jenkins para actualizar los cambios.
2. Ahora accede a “Global Tool Configuration” en la administración de Jenkins. Dentro de esta opción busca la sección llamada “SonarQube Scanner”, por último añade un nuevo scanner con el nombre que desees (recomendado: sonar-scanner)
3. Luego desde “Configurar Sistema” dirígete a la sección “SonarQube servers” e ingresa los siguientes datos
Name: sonarqube
URL del servidor: http://sonarqube:9000
4. Una vez agregado el server dirígete a las opciones inferiores hasta “Jenkins Location” y modifica la dirección web de Jenkins y email del administrador.
5. Continua navegando en las secciones inferiores y detente en “Quality gates” y agrega una nueva instancia de sonar con los siguientes datos:
Name: quality-gate
SonarQube Server URL: http://sonarqube:9000
SonarQube account login: admin
SonarQube account password: admin
Nota: las credenciales de autenticación de sonar por defecto usan los valores admin/admin
6. Por último ubícate en la sección “Extended E-mail Notification”, en el campo SMTP server escribe el valor de smtp.gmail.com. En opciones avanzada selecciona Use SMTP Authentication y agrega las credenciales de tu correo electrónico.
Por último clic en Apply y finalmente en Guardar.
En este punto tendremos lista nuestra configuración de Jenkins a sonar, ahora vamos a realizar un par de ajustes en sonar para completar el flujo adecuado.
Nos dirigimos a nuestra plataforma de sonar por el puerto 9000, como se configuró previamente desde el docker-compose, vamos al login y accedemos con las credenciales por defecto de sonar
Login: admin
Password: admin
En la parte superior encontrarás un menú, dirígete a la opción “Administration” y luego a “Marketplace”, en esta sección se agregarán los plugins que son necesarios para el análisis de nuestro proyecto prueba.
A continuación te proporcionamos una lista de los plugins básicos de sonar, necesarios para el correcto funcionamiento del análisis de nuestro proyecto:
- Git
- GitHub Authentication for SonarQube
- JaCoCo
- SonarJava
- LDAP
- SAML 2.0 Authentication for SonarQube
- SonarXML
Dentro de esta misma opción de menú “Administration” se encuentra la pestaña “Configuration”, selecciona “General Settings”
Desplázate hasta la sección general “Server base URL” y en el campo escribe: http://sonarqube:9000
Ahora, desde la misma opción “Configuration” selecciona “Webhooks”, y clic en Create
Name: webhook-sonar
URL: http://jenkins:8080/sonarqube-webhook
y por último clic nuevamente en “Create” de la ventana emergente:
Finalmente, vamos a escribir el código que dará a entender al pipeline la ejecución de esta nueva etapa y el análisis en sonar.
Comienza definiendo el nombre de la etapa, y una variable de entorno con el nombre del scanner configurado previamente en la configuración de jenkins, de esta manera:
stage("scan"){
environment {
scannerHome = tool 'sonar-scanner'
}
}
Ahora vamos a definir cada uno de los pasos de la etapa
steps {
withSonarQubeEnv('sonarqube') {
sh "${scannerHome}/bin/sonar-scanner \
-Dsonar.projectKey=practicaJava:Test \
-Dsonar.projectName=practicaJava \
-Dsonar.projectVersion=0.${BUILD_NUMBER} \
-Dsonar.sources=${PROJECT_ROOT}/src/main \
-Dsonar.language=java \
-Dsonar.java.binaries=./${PROJECT_ROOT}/target/classes \
-Dsonar.java.test.binaries=${PROJECT_ROOT}/src/test/java \
-Dsonar.junit.reportPaths=./${PROJECT_ROOT}/target/surefire-reports \
-Dsonar.coverage.jacoco.xmlReportPaths=./${PROJECT_ROOT}/target/site/jacoco/jacoco.xml \
-Dsonar.java.coveragePlugin=jacoco"
}
}
Por último agregamos una instrucción, dentro de los steps, de timeout la cual es útil para detener la ejecución en caso de que el proceso no sea exitoso:
timeout(time: 10, unit: 'MINUTES') {
waitForQualityGate abortPipeline: qualityGateValidation(waitForQualityGate())
}
Fuera del script del pipeline agrega el método qualityGateValidation(), el cual enviará un correo de validación bajo los parámetros y porcentajes de calidad que se definan
def qualityGateValidation(qg) {
if(qg.status != 'OK') {
emailext body: "La Cobertura del escaneo es menor a 70%", subject: "Error Sonar Scan,
Quality Gate", to: "${EMAIL_ADDRESS}"
return true
}
emailext body: "La Cobertura del escaneo es mas del 70% - SUCCESS", subject: "Info -
Ejecucion pipeline", to: "${EMAIL_ADDRESS}"
return false
}
Una vez aplicados los cambios vuelve a construir el pipeline, ahora se agregará la nueva etapa
Dirígete a tu ambiente de sonar y observa el análisis del proyecto
Quality Gates:
Una Quality Gate es un conjunto de condiciones que ayuda a saber de inmediato si los proyectos están listos para salir a producción. Sonar proporciona una quality gate por defecto a todos los proyectos, que consta de 5 condiciones:
Pero cada proyecto tiene particularidades, por lo que puedes crear una Quality Gate con las condiciones que más se ajusten. Si alguna de las condiciones falla, la Quality Gate devolverá una respuesta de falla al pipeline, deteniendo su ejecución, veámoslo con el siguiente ejemplo:
La cobertura actual del proyecto es de 65.6%, si se agrega una nueva condición dentro de la Quality Gate acerca de la política de cobertura de código superior al 70% el pipeline fallará
Ahora ejecutamos de nuevo el pipeline después de aplicada esta condición, esperamos que falle en su stage scan
Revisemos el log
Como te explicamos previamente la Quality Gate arrojará un error ya que no se cumple la condición que establecimos sobre la cobertura, esto lo puedes visualizar en el proyecto:
Damos por cerrada la construcción de esta etapa, en una nueva lección continuaremos con la construcción de la etapa de despliegue, que en conjunto con el stage de construcción y análisis conforman el flujo básico y principal de un pipeline.
