Integración Contínua II – Sonar

Sonar

Sonar se define a sí mismo en su página web como “SonarQube is an open platform to manage code quality. As such, it covers the 7 axes of code quality.”. En castellano sencillo, viene a decir que es una plataforma abierta para gestionar la calidad del código. Cuando terminemos nuestra instalación de Sonar, podremos con un sencillo comando de Terminal ejecutar un análisis de calidad de nuestro código cuyos resultados veremos después en el navegador.

Instalación

Descarga

Iremos a la página de descargas de Sonar y elegiremos la versión 2.3. Esto nos dará el analizador.

Como con Gradle en nuestro anterior artículo, descomprimimos la carpeta y la dejamos en nuestra $home, sin la versión en ella. De ese modo, deberíamos tenerla en /home/miusuario/sonar.

Hecho eso, iremos a por el servidor local de Sonar a su página de sourceforge. Allí nos indican cómo meter los repositorios de Sonar para poder instalarlo usando apt-get install. Seguimos los pasos y, por último, lanzamos el script de ejecución:

/etc/init.d/sonar start
Ahora vamos a localhost:9000 a confirmar que todo está funcionando como debe. Si vemos el mensaje de “Welcome to SonarQube Dashboard” es que todo está correcto y podemos empezar a usarlo.

Configuración

Por comodidad, podemos meter en el $PATH la ruta al sonar-runner para no tener que estar poniendo la ruta entera cuando queramos ejecutarlo.  Como no querremos tener que estar usando export cada vez que iniciemos sesión, editaremos el fichero .profile que tenemos en nuestra $home. Debe quedar tal que así:
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

# Android tools
export PATH=${PATH}:~/android/tools
export PATH=${PATH}:~/android/platform-tools
export PATH=${PATH}:~/gradle/bin
export PATH=${PATH}:~/sonar-runner/bin
export ANDROID_HOME=/ruta/absoluta/hacia/android-sdks

La línea en azul es la que nos interesa. Añade la ruta al directorio de ejecutables de Sonar al $PATH, de manera que podamos invocar la herramienta sin precisar la ruta dónde está.

Uso

Para poder usar Sonar con nuestros proyectos, debemos tener un fichero en ellos, llamado sonar-project.properties, en el que le indicaremos la ruta relativa a nuestra carpeta src, entre otras cosas. Ejemplo:

# required metadata
    sonar.projectKey=NovedadesUmbria
    sonar.projectName=NovedadesUmbria
    sonar.projectVersion=1.0
     
    # path to source directories (required)
    sources=src/
     
    # path to test source directories (optional)
    #tests=tests
     
    # path to project binaries (optional), for example directory of Java bytecode
    #binaries=/home/scmbuild/wcbd/binaries
     
    # path to project libraries (optional)
    #libraries=junit.jar
     
     
    #Uncomment those lines if some features of java 5 or java 6 like annotations, enum, ...
    #are used in the source code to be analysed
    sonar.java.source=1.6
    sonar.java.target=1.6
     
    #reuse unit test reports, set dynamicAnalysis=true if you don't want to reuse existing test reports
    sonar.dynamicAnalysis=true
    #sonar.surefire.reportsPath=target//surefire-reports//
    #sonar.cobertura.reportPath=target//site//cobertura//coverage.xml
     
    # advanced parameters
    my.property=value
    protectedAllowed=true

Guardamos esto como “sonar-project.properties” en la raíz de nuestro repositorio. Luego, en el Terminal, nos moveremos al mismo directorio y ejecutaremos el comando

sonar-runner

(si no hemos metido la ruta en nuestro $PATH, habría que incluirla)

Cuando veamos que ha terminado la ejecución, nos iremos a la interfaz web de Sonar (localhost:9000) y veremos en ella que se ha generado nuestro proyecto. Pinchamos en él y veremos el informe detallado con información (nº de clases, nº de líneas de código, etc), el porcentaje de código comentado y documentado, la complejidad y, a la derecha, los problemas (issues) que pudiera tener la calidad de nuestro código, desglosado por categorías. Podemos pinchar en cada categoría para ir viendo la lista de problemas. Viene muy detallado, con la clase, el fragmento de código para localizar el “problema” y una breve descripción del mismo. Pueden ser desde “línea de código comentada”, a “este atributo debería ser privado”, etc.

Conclusión

Conviene hacer análisis regulares de nuestro código. Si probáis ahora con alguna app que tengáis hecha, es posible que las cifras de los issues os quiten las ganas de intentar resolverlos, pero si vais desde el principio cada poco, se hará mucho mas manejable.

La calidad del código es importante. Mejora su legibilidad, lo que nos ayudará en un futuro si queremos volver a ver qué hicimos y cómo, pero también ayudará a los demás si nuestro proyecto es de Código Abierto. Además, un código de calidad nos da un cierto aire de profesionalidad que siempre viene bien si queremos dedicarnos profesionalmente a estos menesteres.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: