Sonar – Análisis Cobol con Jenkins

Hemos visto en el post anterior cómo instalar el plugin Sonar para Jenkins. Ahora llega el momento de hacer nuestro primer análisis con Jenkins. Se centrará en el código fuente Cobol ya utilizado en nuestro primer análisis con Sonar y el Java Runner.

Para eso, vamos a crear un proyecto, desde la página principal de Jenkins.

En la página de creación, entramos un nombre de proyecto y seleccionamos la primera opción:

Esto nos abre la página de configuración de este proyecto, en la cual indicamos que deseamos efectuar un análisis Sonar:

Nos queda indicar el fichero de configuración para este análisis, lo mismo que ya hemos utilizado para nuestro primer análisis con Sonar: C:\Soft\Sonar\sonar-runner-1.1\Projects\sonar-project.properties:

Pero antes, vamos a especificar en este fichero una nueva versión para nuestro análisis: sonar.projectVersion=1.1.

No olvides guardar los parámetros de tu proyecto.

Antes de arrancarlo.

Mientras que se ejecuta…

 

Podemos ver el log de análisis:

Luego en Sonar, el resultado de este análisis, con la versión indicada en nuestro fichero de configuración:

Hemos visto cómo evitar dos desventajas del Java Runner (que utilizamos por falta de práctica de la sintaxis Maven):

  1. Un fichero único de configuración de análisis: Jenkins nos permite especificar un fichero distinto para cada análisis Sonar.
  2. Un log mucho más práctico y fácil de usar cada vez que lanzaremos uno de nuestros análisis Sonar.

Esto nos permite una gran flexibilidad de utilización, particularmente en la organización de nuestro entorno de análisis. Vamos a ver dos ejemplos.

Voy a comenzar por renombrar el fichero Myproject.properties, en la carpeta..\sonar-runner-1.1\Projects y la version de análisis (sonar.projectVersion=1.2) en este fichero (para comprobar que el ha sido utilizado).

Luego voy a indicar este nuevo fichero en la configuración de mi proyecto Jenkins antes de lanzar éste de nuevo…Y verificar el resultado en Sonar: una nueva versión 1.2 efectivamente aparece. Esto significa que puedo utilizar un espacio ‘Project’ con tantos ficheros de configuraciones que tengo de aplicaciones que analizar.

 

Otro tipo de organización consiste en dedicar un disco duro a mi entorno de análisis, con una caperta por cada aplicación, en la cual colocaré el código fuente y todos los ficheros de configuración de análisis. En este segundo ejemplo, vamos a:

  • Crear una carpeta G:\Mainframe\MyAppCobol para nuestra aplicación.
  • En esta carpeta, crear un sub-directorio \Source en lo cual copiamos los programas Cobol que analizar.
  • En esta carpeta, crear un sub-directorio \Implementation\Conf en lo cual ponemos el fichero de configuración Sonar MyAppCobol.properties.
  • En este fichero, modificar la propriedad sources=G:/Mainframe/MyAppCobol/Source con el fin de precisar el nuevo emplazamiento de los ficheros Cobol.

He aquí al que se parece nuestro nuevo entorno.

No nos queda más que modificar de nuevo la configuración de proyecto Jenkins con el fin de tomar en consideración el nuevo emplazamiento del fichero de configuración Sonar, y de ejecutar un nuevo análisis.

Así podemos organizar nuestros análisis como lo deseamos, o sea centralizando todos los ficheros de configuración en la misma carpeta \Projets (por ejemplo), o sea descentralizando cada uno al nivel de una carpeta por aplicación.

Podemos administrar tantos análisis que lo deseamos, de cualquiera tecnología con los plugins Sonar, y beneficiar de la consola Jenkins para administrar el logs de análisis.

Finalmente, la solución implementada se basa en el Java Runner de Sonar sin necesidad de conocimientos especiales de otras herramientas como Ant o Maven.

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *