1. Información general
En este artículo, veremos el análisis de código fuente estático con SonarQube, que es una plataforma de código abierto para garantizar la calidad del código.
Comencemos con una pregunta central: ¿por qué analizar el código fuente en primer lugar? En pocas palabras, para garantizar la calidad, confiabilidad y facilidad de mantenimiento durante la vida útil del proyecto; un código base mal escrito siempre es más caro de mantener.
Muy bien, ahora comencemos descargando la última versión LTS de SonarQube desde la página de descarga y configurando nuestro servidor local como se describe en esta guía de inicio rápido.
2. Análisis del código fuente
Ahora que hemos iniciado sesión, debemos crear un token especificando un nombre, que puede ser nuestro nombre de usuario o cualquier otro nombre de elección y haga clic en el botón generar.Usaremos el token más adelante en el momento de analizar nuestro (s) proyecto (s). También necesitamos seleccionar el idioma principal (Java) y la tecnología de construcción del proyecto (Maven).
Definamos el complemento en pom.xml :
org.sonarsource.scanner.maven sonar-maven-plugin 3.4.0.905 La última versión del complemento está disponible aquí. Ahora, necesitamos ejecutar este comando desde la raíz de nuestro directorio de proyecto para escanearlo:
mvn sonar:sonar -Dsonar.host.url=//localhost:9000 -Dsonar.login=the-generated-tokenNecesitamos reemplazar el token generado por el token de arriba.
El proyecto que usamos en este artículo está disponible aquí.
Especificamos la URL de host del servidor SonarQube y el inicio de sesión (token generado) como parámetros para el complemento Maven.
Después de ejecutar el comando, los resultados estarán disponibles en el panel de proyectos, en // localhost: 9000 .
Hay otros parámetros que podemos pasar al complemento de Maven o incluso configurar desde la interfaz web; sonar.host. url, sonar.projectKey y sonar.sources son obligatorios, mientras que otros son opcionales.
Otros parámetros de análisis y sus valores predeterminados están aquí. Además, tenga en cuenta que cada complemento de idioma tiene reglas para analizar el código fuente compatible.
3. Resultado del análisis
Ahora que hemos analizado nuestro primer proyecto, podemos ir a la interfaz web en // localhost: 9000 y actualizar la página.
Allí veremos el resumen del informe:
Los problemas detectados pueden ser un error, una vulnerabilidad, un olor de código, una cobertura o una duplicación. Cada categoría tiene un número correspondiente de problemas o un valor porcentual.
Además, los problemas pueden tener uno de cinco niveles de gravedad diferentes: bloqueador, crítico, mayor, menor e información. Justo delante del nombre del proyecto hay un icono que muestra el estado de Quality Gate: aprobado (verde) o fallido (rojo).
Hacer clic en el nombre del proyecto nos llevará a un panel de control dedicado donde podemos explorar problemas particulares del proyecto con mayor detalle.
Podemos ver el código del proyecto, la actividad y realizar tareas de administración desde el panel del proyecto, cada uno disponible en una pestaña separada.
Aunque hay una pestaña de Problemas global , la pestaña de Problemas en el panel del proyecto muestra problemas específicos del proyecto en cuestión solo:
La pestaña de problemas siempre muestra la categoría, el nivel de gravedad, las etiquetas y el esfuerzo calculado (con respecto al tiempo) que se necesitará para rectificar un problema.
Desde la pestaña de problemas, es posible asignar un problema a otro usuario, comentarlo y cambiar su nivel de gravedad. Al hacer clic en el problema en sí, se mostrarán más detalles sobre el problema.
La pestaña de problemas viene con filtros sofisticados a la izquierda. Estos son buenos para localizar problemas. Entonces, ¿cómo se puede saber si la base de código es lo suficientemente saludable para su implementación en producción? Para eso está Quality Gate.
4. Puerta de calidad de SonarQube
En esta sección, veremos una característica clave de SonarQube: Quality Gate. Luego veremos un ejemplo de cómo configurar uno personalizado.
4.1. ¿Qué es una puerta de calidad?
Un Quality Gate es un conjunto de condiciones que el proyecto debe cumplir antes de que pueda calificar para el lanzamiento de producción. Responde a una pregunta: ¿puedo enviar mi código a producción en su estado actual o no?
Asegurar la calidad del código "nuevo" mientras se corrigen los existentes es una buena manera de mantener una buena base de código a lo largo del tiempo. Quality Gate facilita la configuración de reglas para validar cada nuevo código agregado a la base de código en un análisis posterior.
Las condiciones establecidas en Quality Gate aún afectan a los segmentos de código no modificados. Si podemos evitar que surjan nuevos problemas, con el tiempo, eliminaremos todos los problemas.
Este enfoque es comparable a arreglar la fuga de agua de la fuente. Esto nos lleva a un término particular: Período de fuga. Este es el período entre dos análisis / versiones del proyecto .
Si volvemos a ejecutar el análisis, en el mismo proyecto, la pestaña de descripción general del panel del proyecto mostrará los resultados para el período de fuga:
Desde la interfaz web, la pestaña Quality Gates es donde podemos acceder a todas las puertas de calidad definidas. De forma predeterminada, SonarQube way viene preinstalado con el servidor.
La configuración predeterminada para SonarQube way marca el código como fallado si:
- la cobertura del nuevo código es inferior al 80%
- el porcentaje de líneas duplicadas en el código nuevo es mayor que 3
- La calificación de mantenibilidad, confiabilidad o seguridad es peor que A
With this understanding, we can create a custom Quality Gate.
4.2. Adding Custom Quality Gate
First, we need to click on the Quality Gates tab and then click on the Create button which is on the left of the page. We'll need to give it a name – baeldung.
Now we can set the conditions we want:
From the Add Condition drop-down, let's choose Blocker Issues; it'll immediately show up on the list of conditions.
We'll specify is greater than as the Operator, set zero (0) for the Error column and check Over Leak Period column:
Then we'll click on the Add button to effect the changes. Let's add another condition following the same procedure as above.
We'll select issues from the Add Condition drop-downand check Over Leak Period column.
The value of the Operator column will be set to “is less than” and we'll add one (1) as the value for the Error column. This means if the number of issues in the new code added is less than 1, mark the Quality Gate as failed.
I know this doesn't make technical sense but let's use it for learning sake. Don't forget to click the Add button to save the rule.
One final step, we need to attach a project to our custom Quality Gate. We can do so by scrolling down the page to the Projects section.
There we need to click on All and then mark our project of choice. We can as well set it as the default Quality Gate from the top-right corner of the page.
We'll scan the project source code, again, as we did before with Maven command. When that's done, we'll go to the projects tab and refresh.
This time, the project will not meet the Quality Gate criteria and will fail. Why? Because in one of our rules we have specified that, it should fail if there are no new issues.
Let's go back to the Quality Gates tab and change the condition for issues to is greater than. We need to click the update button to effect this change.
A new scan of the source code will pass this time around.
5. Integrating SonarQube into a CI
Making SonarQube part of a Continuous Integration process is possible. This will automatically fail the build if the code analysis did not satisfy the Quality Gate condition.
For us to achieve this, we're going to be using SonarCloud which is the cloud-hosted version of SonaQube server. We can create an account here.
From My Account > Organizations, we can see the organization key, and it will usually be in the form xxxx-github or xxxx-bitbucket.
Also from My Account > Security, we can generate a token as we did in the local instance of the server. Take note of both the token and the organization key for later use.
In this article, we'll be using Travis CI, and we'll create an account here with an existing Github profile. It will load all our projects, and we can flip the switch on any to activate Travis CI on it.
We need to add the token we generated on SonarCloud to Travis environment variables. We can do this by clicking on the project we've activated for CI.
Then, we'll click “More Options” > “Settings” and then scroll down to “Environment Variables”:
We'll add a new entry with the name SONAR_TOKEN and use the token generated, on SonarCloud, as the value. Travis CI will encrypt and hide it from public view:
Finally, we need to add a .travis.yml file to the root of our project with the following content:
language: java sudo: false install: true addons: sonarcloud: organization: "your_organization_key" token: secure: "$SONAR_TOKEN" jdk: - oraclejdk8 script: - mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent package sonar:sonar cache: directories: - '$HOME/.m2/repository' - '$HOME/.sonar/cache'Recuerde sustituir la clave de su organización por la clave de organización descrita anteriormente. Confirmar el nuevo código y enviarlo al repositorio de Github activará la compilación de Travis CI y, a su vez, también activará el escaneo de la sonda.
6. Conclusión
En este tutorial, hemos visto cómo configurar un servidor SonarQube localmente y cómo usar Quality Gate para definir los criterios de idoneidad de un proyecto para el lanzamiento de producción.
La documentación de SonarQube tiene más información sobre otros aspectos de la plataforma.