SonarQube: Cómo mantener la calidad de tu código durante un proceso de CI/CD

En artículos anteriores hemos visto diversos procesos de testing que nos permiten garantizar la calidad y corrección del producto final que debemos entregar. En este artículo vamos a hablar de SonarQube, una herramienta que nos permite garantizar también la calidad a nivel interno.

Es decir, conseguiremos controlar si el proceso de desarrollo, la arquitectura empleada o los algoritmos empleados siguen una estructura adecuada, un patrón que nos permita un fácil mantenimiento del producto.

¿Qué es SonarQube?

SonarQube es una de las herramientas más usadas para revisar código, detectar bugs, vulnerabilidades y otros problemas dentro de nuestro proyecto. Permite el análisis de código que se encuentre escrito en los principales lenguajes de programación (Java, PHP, JavaScript, C#, HTML, etc.).

SonarQube se integra como un fichero más dentro del proyecto a analizar y, si el pipeline en el que se lanzan las tareas está correctamente configurado, la inspección del código se hará automáticamente cada vez que hagamos un cambio en alguna parte de dicho proyecto.

Imagen obtenida de la documentación oficial de SonarQube 

Como se muestra en la imagen, el escenario típico en el que mejor puede entenderse su utilidad es el que contiene tres fases claras: 

  • Desarrollo – El código es actualizado en el repositorio por los desarrolladores. Antes de solicitar al servicio de SonarQube que analice los cambios, ellos pueden disponer de feedback inmediato gracias a la herramienta SonarLint, que puede ser integrada en los IDEs.
  • CI/CD – Al incluir los nuevos cambios en el repositorio, las herramientas de Integración Continua comprueban y construyen el código, y ejecutan las pruebas. Acto seguido se hace la llamada al escáner de SonarQube para que analice los resultados de algunas de esas pruebas y el código como tal. 
  • Plataforma de SonarQube – Una vez realizado el análisis del proyecto, los resultados son almacenados en la plataforma y en función de las condiciones de calidad que se configuren, podrá informarse a los miembros del equipo si deben solventar alguna carencia.

Para los diversos proyectos que se realizan en WATA Factory, nos hemos decantado por usar la edición Community, la cuál es libre y de código abierto. Sin embargo, existen otras alternativas de pago que te facilitan la instalación y mantenimiento del servicio de SonarQube por parte de la misma compañía. Para el caso de la versión Community, ésta puede ser instalada en dos modalidades:

  • Local – El desarrollador podrá montarse el servicio de SonarQube en su localhost para poder analizar su código sin necesidad de alojarlo en ningún servidor externo o remoto. 
  • Remoto – El servicio de SonarQube se encontrará alojado en un servidor remoto dónde se podrá acceder a través de credenciales generadas por el administrador del servicio.  

En función de las necesidades y del tamaño del proyecto (miembros, recursos o servicios a los que acudir), podrás elegir la opción más adecuada según tus circunstancias.

Conceptos generales 

Para entender un poco más la relevancia que tiene el uso de esta herramienta, vamos a detallar los conceptos generales que van a aparecer en la plataforma: 

  1. Usuarios y grupos: Al igual que en cualquier entorno, vamos a poder definir usuarios que se organicen en grupos. Cada uno de ellos con una serie de privilegios que les permitirán desde solicitar el análisis de un proyecto hasta validar o cancelar falsos positivos en los análisis realizados. 
  2. Proyectos: Para poder realizar el análisis de nuestro código, tendremos que generar un proyecto en la plataforma dónde indiquemos los parámetros que van a identificar nuestro proyecto software. Dichos parámetros, en función del lenguaje que estemos usando en nuestro proyecto, se deberá indicar de una manera u otra. Dentro de estos proyectos encontraremos el análisis de cada uno de ellos, conteniendo los siguientes datos: 
  3. Bugs: Errores en el código que deben ser resueltos lo antes posible. 
  4. Vulnerabilidades: Puntos del código que se encuentran abiertos a ataques externos y que pueden poner en peligro la integridad y seguridad del proyecto. 
  5. Hotspots: Puntos del código que deben ser revisados para evitar problemas mayores, no tienen porqué poner en peligro la seguridad del proyecto. 
  6. Code smells: Elementos que hacen que el código sea poco legible o difícil de mantener. 
  7. Cobertura: A partir de los reportes de los tests unitarios ejecutados, SonarQube importa los resultados y muestra la cobertura de ellos. 
  8. Duplicaciones: Número de bloques, ficheros y líneas duplicadas detectadas. 
  9. Total de líneas: Total de líneas de código del proyecto. 
  10. Lenguajes: Lenguajes de programación que son usados en el proyecto. 
  11. Estado actual: Fail/Passed, dependiendo de los valores establecidos en el perfil de calidad que se le asocien. 
  12. Tags: Etiquetas que se le han asignado al proyecto. 
  13. Hora del último análisis: Registro de cada uno de los análisis realizados. 
  14. Perfiles de calidad: Dependen directamente de las condiciones establecidas en los Quality Gates, las cuales van a indicar cuáles son las reglas que deben seguirse en cada uno de los lenguajes disponibles en SonarQube. Las condiciones de los perfiles de calidad reflejarán límites en cuanto a mínimos de cobertura, líneas duplicadas, índice de seguridad o índice de mantenibilidad. 

Como podemos ver, el reporte y la información generada es muy amplia, lo que nos permite tener una visión muy precisa del estado de nuestro proyecto.

En WATA Factory hemos establecido SonarQube como una herramienta más y ha permitido la mejora de la calidad del código y también, un aprendizaje indirecto de los desarrolladores. Ya que con cada uno de los reportes se aprende qué malas prácticas deben evitar y cómo solventarlas con las propuestas ofrecidas por la misma herramienta, gracias a las reglas definidas en los Quality Gates. En futuros artículos, veremos cómo configurar nuestro proyecto para poder analizarlo con SonarQube de forma automática desde un pipeline