En el post anterior, hemos configurado nuestro primer análisis PL/SQL con SonarQube y Jenkins. Lo ejecutamos, y luego podemos ver los resultados en el dashboard de SonarQube.

Será una oportunidad para examinar y explicar en los próximos articulos las reglas de SonarQube sobre las mejores prácticas de programación PL/SQL. Pero en primer lugar, vamos a ver lo que nos ofrece el Quality Profile PL/SQL de SonarQube.

Recordemos que un Quality Profile es un grupo de reglas, cada una con un peso (Blocker, Crítical, Major, etc.). Podemos personalizar el perfil, activando o desactivando ciertas reglas, o asignando un nivel diferente de criticidad según las buenas prácticas en marcha en el equipo de proyecto o en el cliente. Unas reglas, por lo general las más importantes, son obligatorias y no se deben desactivar, aunque podemos cambiar eventualmente su peso. Otras normas, en general, menos críticas, se pueden desactivar si un cliente ha optado por no incluirlas en sus propias mejores prácticas.

Para tomar estas decisiones, echemos un vistazo a lo que nos ofrece el perfil de calidad PL/SQL de SonarQube.

El Quality Profile PL/SQL de SonarQube

En el cuadro de mando SonarQube de nuestro proyecto, la página ‘Issues drilldown’ enumera varios violaciónes de buenas prácticas de programación PL/SQL.

Podemos constatar 17 infracciones de tipo Blockers pero zero defecto crìtico (Critical). Bastante sorprendente.

Es muy posible tener sólo 17 Blockers, como posible consecuencia de falta de atención por parte del equipo del proyecto, pero una puntuación perfecta en las normas críticas con una total ausencia de defecto es realmente increíble.

Vamos a ver el Quality Profile por defecto de SonarQube. Activamos el menú correspondiente en  la barra de menú, para abrir la página del mismo nombre.

Al final de esta página, encontramos el Profile PL/SQL llamado ‘Sonar way’, con 74 reglas.

Un clic en este enlace nos permite entrar en la página de detalle de estas normas.

En ella, encontramos en primer lugar el conjunto de reglas críticas al seleccionar ‘Critical’ en la combo-box ‘Severity’, y luego activando el botón ‘Search’.

Podemos ver que este Profile tiene sólo 5 reglas ‘Critical’ y todas ellas desactivadas, ya que no hay ninguna seleccionada.

Ahora, si buscamos todas las reglas de cualquier criticidad, pero inactivas:

Podemos ver que 58 reglas son desactivadas, además de los 74 existentes.

Por supuesto que no todas son necesariamente aplicables, pero mi objetivo en esta serie de posts es construir una demo que me permite mostrar lo que se puede hacer con SonarQube para una evaluación de la calidad de código PL/SQL. Por eso, yo quiero tener el mayor número de reglas, y luego escoger si hay que desactivar algunas o cambiar su criticidad para mi demo.

Crear un nuevo Quality Profile

Voy a crear un nuevo perfil de calidad en el que voy a activar todas las reglas existentes. Luego, podremos volver a ejecutar un análisis y ver en el cuadro de mando SonarQube si tengo unos resultados interesantes.

Para crear un nuevo Profile, tengo primero que conectarme como ‘Admin’, de tal modo que, cuando entro de nuevo en la página ‘Quality Profile’, nuevos menús han aparecido que me permiten copier el perfil por defecto, con un click en el menú ‘Copy’.

Surge un dialog-box para escoger un nombre para este nuevo Profile.

Una vez creado, vamos en su página de Profile y buscamos todas las reglas inactivas, como lo hemos hecho anteriormente.

Una vez estas 58 reglas en la pantalla, puedo activarlas todas de una vez con el ‘Bulk Change’ en la parte superior derecha de la página. Simplemente seleccionamos ‘Activate all’ para activar todas las reglas presente en la página.

Tras esta operación, SonarQube me dice que 132 reglas están disponibles en mi nuevo perfil : las 74 activas al principio más las 58 que acabamos de activar. La cuenta es correcta.

Se queda una última operación que realizer: asignar este perfil a mi análisis PL/SQL. Vamos en la pestaña ‘Projects’ y buscamos el proyecto que representa mi análisis de código PL/SQL. Con 2 letras introducidas en el campo de busqueda, SonarQube lista todos los proyectos con estas 2 letras y me permite escoger el análisis de código PL/SQL.

Luego, voy a hacer un ‘Logout’ como Admin y ejecutar de nuevo mi análisis PL/SQL en Jenkins.

La pagina ‘Issues drilldown’ muestra ahora nuevos defectos ‘Critical’ y un aumento muy importante en el número de violaciones.

Entonces, vamos a poder ver todas las reglas PL/SQL disponibles en SonarQube, y por lo tanto personalizar nuestro nuevo Quality Profile.

El siguiente post se centrará en las reglas más importantes: ‘Blockers’ y ‘Critical’. Hasta luego.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.