Esta serie de artículos sobre la instalación de SonarQube terminará con este post. Recuerda cuáles eran los objetivos:
- Establecer un entorno de análisis de código para medir la calidad de las aplicaciones.
- Sin necesidad de conocimientos técnicos de Java, bases de datos, de red o herramientas de código abierto.
Eres un profesional en el mundo Cobol Mainframe o SAP, un consultor de la calidad, una interfaz entre los usuarios y los equipos de proyecto (stakeholder), un jefe de proyecto gestionando diferentes aplicaciones subcontratadas a diferentes proevedores: esta serie mostró los pasos para instalar SonarQube en tu PC, para analizar fácilmente y con regularidad cualquier entrega de código o versión de aplicación.
Y vamos a terminar hoy con un análisis del código Java que se utilizó anteriormente con el SonarQube Runner, y de una forma sencilla con el plugin SonarQube para Jenkins.
Creación de un análisis de SonarQube con Jenkins
Nuestro primer análisis con SonarQube Jenkins se centrará en el código Java ya utilizado en nuestro análisis con SonarQube Runner.
Para ello, vamos a crear un proyecto en el menú Jenkins en la parte superior izquierda de la página.
Seleccione el menú ‘Nueva Tarea‘: Jenkins muestra la pagina de creación de un nuevo ‘job’.
Es posible crear diferentes tipos de proyectos de acuerdo con las herramientas utilizadas (como Maven). Con SonarQube, vamos a elegir la primera opción ‘Crear un proyecto de estilo libre’ y escribir un nombre de proyecto: ‘Extranet‘ en mi ejemplo. El botón ‘OK’ en la parte inferior de la página se vuelve activo.
Tenga en cuenta que tenemos un mensaje de error si utilizamos un nombre de proyecto que ya existe.
Click en el botón ‘OK’ para acceder a la página de configuración del proyecto.
No voy a detallar las muchas opciones disponibles en esta página. Nunca las he usado, a excepción de la gestión de los logs, para eliminarlos automáticamente más allá de una fecha determinada, o cuando se vuelven demasiado numerosos.
Simplemente seleccione el botón ‘Añadir un nuevo paso’ que abre la siguiente lista de menús en la que elegimos ‘Invoke Standalone Sonar Analysis’ (si, este último menú en ingles, parece que se ha olvidado traducirlo).
Esto abre la página de configuración para este proyecto:
Solamente tengo que entrar el nombre del archivo properties que contiene los parámetros de nuestro primer análisis con el SonarQube Runner, el ‘sonar project.properties’, ubicado en un directorio ‘..\Projects (en la carpeta ‘home’ del SonarQube Runner).
En este post, te dije que era importante de administrar correctamente nuestro entorno, eljiendo dónde, para cada aplicación, ubicamos el código fuente y todo lo que contribuye a la configuración de análisis. Para cada proyecto, tengo un directorio ‘source’ con el código correspondiente, y un otro directorio ‘Implementation\Conf’ en el que voy a mantener el archivo de properties específicas en este análisis.
Este método tiene muchas ventajas, incluyendo:
- Encontrar fácilmente los parámetros de cualquier análisis, incluso mucho tiempo después de ella.
- Duplicar fácilmente los valores de un análisis que funciona a la perfección con una copia el mismo archivo para un proyecto nuevo. Queda entonces modificar los valores de estos parámetros, pero sé que no me he olvidado nada en la configuración, por lo que ningún error puede occurir debido a esta.
- Si trabajas con un servidor compartido, siga la misma configuración (y prácticas similares) lo que te permitirá ir de vacaciones tranquilo: todos los demás miembros de tu equipo sabrán exactamente cómo encargarse de tus proyectos sin haber participado en ellos. Esto no impide alguna documentación (que mantener en la carpeta ‘Implementation\Doc’), pero va a ser muy breve: una sincilla hoja de descripción del análisis.
Entonces, tengo exactamente el mismo fichero ‘properties’ que contiene los mismos parámetros de nuestro primer análisis con el SonarQube Runner.
Otra ventaja que me permite Jenkins es reemplazar cualquier valor en el archivo de la página de configuración ‘Invoke Standalone Sonar Analysis’, para por ejemplo especificar un número de versión para este análisis o versión de aplicación:
sonar.projectVersion=1.1
No se olvide de guardar la configuración antes de empezar el análisis con el menú ‘Construir ahora’.
Ejecución y log
Una barra de progreso muestra donde estamos en el análisis.
Un menú desplegable (menú contextual) nos permite ver el log del job durante o al final del análisis,
Si haces click en la imagen anterior de log, puedes ver los diversos parámetros que hemos indicado en nuestra configuración de Jenkins.
En la misma página, un menú que permite ver este log en modo texto con el fin de guardarlo o enviar por correo electrónico, por ejemplo.
Y, por último, el resultado en SonarQube.
Hemos visto en este artículo las principales ventajas de la utilización de Jenkins con Sonar:
- Organizar el entorno de análisis como deseamos, con un archivo de configuración para cada proyecto, y que podemos duplicar para reutilizarlo para un nuevo análisis.
- Poder sustituir un parámetro – como el número de versión – para cada análisis.
- Tener un log mucho más fácil de usar.
Con este último articulo, sabéis todo lo que es necesario conocer para hacer vuestros propios análisis y medir fácilmente las calidad de diferentes aplicaciones y diferentes tecnologías, sin necesidad de tener ningún conocimiento técnico especial.
Me refiero también a otras dos series en mi blog, en el análisis de las aplicaciones Cobol ou SAP con SonarQube.
A vosotros ahora. Y no dudad en dejar un comentario con el resultado de vuestros análisis.
Esta entrada está disponible también en Lire cet article en français y Read that post in english.