Bueno, en nuestras ultimas series de artículos prácticamente hemos completado el ciclo de despliegue de una aplicación desde el cambio de código hasta su publicación en los entornos, pero como es lógico esto no se acaba ahí, nuestro objetivo debe ser siempre la búsqueda de calidad en lo que estamos desarrollando, y esto necesariamente involucra al código: legibilidad, mantenibilidad, seguridad, buenas practicas según lenguaje, etc.
En ese sentido la idea seria mantener unos niveles de calidad y “parar la Build” en caso que la calidad del código no cumpla unos mínimos, tradicionalmente en .Net hemos contado con la opción de definir unas reglas mediante Code Analysis, permitiendo que no se haga checkin de código si no se cumplen las reglas (si usamos TFVC) o que ciertas reglas se cataloguen como error (forzando a corregirlas si o si), alternativa muy interesante sobre la que tratare de regresar en un post futuro.
En todo caso, en paralelo a lo que veíamos en el mundo .Net iba evolucionando una herramienta muy potente que permitía explotar el análisis de código estático al máximo: Sonarqube, herramienta a la que pude conocer cuando me correspondió configurar un proyecto de Integración Continua donde me gustaron mucho sus dashboard que permitía ir analizando con detalle los diversos tipos de deuda técnica existente en nuestras aplicaciones (para verlo en acción revisa aquí) y como esta ha ido evolucionando históricamente; en ese momento si querías integrarlo en .Net tenias dos opciones: invocar manualmente el análisis, o enlazarlo a un ciclo de Integración Continua usando Jenkins, pero ahora Microsoft ha colaborado para que sea posible integrarlo con TFS y VSTS y de esto se trata este post.
Para mas razones por las cuales usar Sonarqube en nuestros desarrollos, revisar este post de Adrian.
En esta ocasión cambiare un poco el enfoque del post, en lugar de hacer la guiá paso a paso, referiré a la documentación ya existente, indicando las variantes y/o problemas con las que me he topado y como lo he solucionado.
Antes de avanzar debemos tener en cuenta que para usar Sonarqube requerimos montar todo el stack completo: Maquina Virtual y servidor Sonar, de momento no hay un servicio de tipo PaaS al cual conectarnos para efectuar el análisis, por lo que como ya se lo imaginaran usaremos Azure para crear la MV en cuestión, existe una guiá hecha por los ALM Rangers para crear una MV, pero esta guiá indica los pasos para integrar SQL Server como repositorio de nuestra instalación de Sonarqube, como prueba de concepto (que felizmente funciono correctamente) opte por usar una MV (creada bajo Resource Group y no de modo “Classic”) que solo tenia el Windows Server 2012, y para BD use el servicio SQL Database (PaaS) a fin de ahorrarme los pasos de configuración, como es lógico ambos servicios fueron provisionados en la misma zona geográfica y el mismo Resource Group, a fin de reducir la posible latencia, de esta forma:
Para la instalación en concreto de Sonarqube en nuestra MV recomiendo la lectura de este articulo, solo que habrá que tener en cuenta que el autor da los pasos asumiendo tener una instancia de SQL Server, siendo que (como ya vimos) trabajaremos con SQL Database, pero por lo demás los pasos son equivalentes ya que deberemos colocar la cadena de conexión de nuestra instancia de manera análoga en el archivo sonar.properties como podemos ver:
Como pueden ver he editado el nombre de la carpeta donde originalmente desempaquete sonarqube, que originalmente era c:\sonarquebe-5.2 a simplemente c:\sonarqube, de igual forma configure el Sonarqube como servicio, solo que en este caso no fue necesario agregar la dependencia a SQL Server que indicaba el articulo.
Hecho esto ya deberíamos tener nuestro SQ operativo y lo podemos verificar visitando http://localhost:9000 dentro de nuestra MV:
Pero claro, se supone que requerimos enlazar nuestra instancia con “el mundo exterior” y eso incluye nuestra instancia de VSTS, por lo cual deberemos exponer su puerto 9000, asi que haremos caso de la recomendación de Donovan y ejecutaremos esto en una linea de comandos (con privilegios de Administrador, claro esta):
netsh advfirewall firewall add rule name="Sonar" dir=in action=allow protocol=TCP localport=9000
Esto abrirá el puerto del firewall dentro de nuestra MV (nótese que no debemos ejecutar la apertura de puertos para SQL Server, pues simplemente no lo tenemos), pero por otra parte deberemos configurar nuestro entorno de Azure para que acepte esas conexiones, por lo que seguiremos estas instrucciones a fin de habilitar el puerto 9000 desde Azure.
Con esto ya podremos invocar http://miIPPublicatemporal:9000 desde nuestra maquina local (recordemos que Azure nos asigna una IP publica que perderemos si apagamos la MV) y conectarnos a nuestra instancia de SQ, y de paso cambiar urgentemente nuestro password, para lo cual nos loguearemos con el usuario y password por defecto: admin, admin.
Bueno, con esto nuestra instancia de SQ esta instalada y operativa, pero aun no “entiende” a los proyectos de .Net, asi que toca prepararla para ello, para esto se requiere configurar dos elementos imprescindibles: el MSBuild SonarQube Runner y el C# Plugin, los cuales tienen como requisito común el tener configurado el .Net Framework 4.52 o superior (algo sencillo ¿no?) y el MSBuild, el cual podríamos descargar como parte del Microsoft Build Tools 2013 (o 2015), pero un problema que tuve fue que el MSBuild (no los componentes de SQ) no pudieron procesar una solución que incluía el namespace Microsoft.VisualStudio.TestTools.UnitTesting asi que no me quedo mas remedio que instalar el Visual Studio 2015 Profesional y no hubo problemas.
Como dice la documentación una vez desempaquetado adecuadamente el MSBuild SonarQube Runner corresponde configurarlo y para eso toca editar el archivo C:\SonarQube\bin\SonarQube.Analysis.xml a fin de pasarle las credenciales de nuestra instancia de SQ, hay que indicar que mi configuración usa la versión 5.2 de Sonarqube por lo que no es necesario pasarle las credenciales de la base de datos, solo las credenciales de SQ, y claro, proteger adecuadamente el acceso a dicho archivo, pues estamos grabando dichas credenciales en texto plano. De igual manera es muy conveniente agregar la ruta de SQ (c:\sonarqube\bin ya que ahí es donde habremos desempaquetado los archivos respectivos) a la variable de entorno %PATH%.
Ahora toca configurar el C# Plugin, lo cual es mucho mas sencillo pues lo podemos hacer directamente desde la web de nuestra instancia de SQ, simplemente vamos a la pestaña de Administración y elegimos el combo de Update Center como se ve en la imagen:
Nos vamos a la pestaña de “Available” y buscamos el de C# que mencionabamos:
Desde ahí es mas sencillo, hacemos clic en el botón de Install y luego reiniciamos el servicio de SonarQube.
Ahora corresponde probar nuestra instancia de SonarQube, para lo cual efectuaremos un paso adicional de configuración en nuestra MV: agregaremos la ruta C:\Program Files (x86)\MSBuild\14.0\Bin a la variable de entorno %PATH% (por si esta no se hubiera agregado en la instalación de Visual Studio), lo cual permitirá el acceso al MSBuild desde cualquier linea de comandos.
Para probar nuestro entorno, lo que haremos sera copiar alguno de nuestros proyectos a la MV, para ello copiaremos desde la carpeta de incluye el archivo .sln, y abriremos una linea de comandos en esa carpeta copiada, dentro de la linea de comandos ejecutaremos tres conjunto de instrucciones:
MSBuild.SonarQube.Runner.exe begin /k:"sonarqube_project_key" /n:"sonarqube_project_name" /v:"sonarqube_project_version"
Esta linea “prepara” nuestra solución antes del análisis, nótese que los parámetros k y n (que identifican al proyecto en SQ) pueden definirse ahí mismo en la linea de comandos (alternativamente el proyecto podría haberse creado desde nuestra web de SQ) pero hay que tener cuidado de guardarlos para futuras invocaciones a fin de ir generando el histórico de la calidad de nuestro codigo fuente.
msbuild /t:Rebuild
Este paso simplemente efectuá la compilación del codigo fuente, generando copias actualizadas de los ensamblados respectivos.
MSBuild.SonarQube.Runner.exe end
Y este paso final efectuá el análisis en si, dejando listo al SQ para que nos muestre los resultados del análisis en la web, como lo podemos ver desde dentro de nuestra MV. 
Y explorando poco a poco, vemos como podemos encontrar la deuda técnica detectada:
Ok, lo que toca ahora es enlazar nuestro SQ con nuestra instancia de VSTS, a fin de que con cada Build se vayan actualizando las estadísticas de calidad, para esto debemos modificar nuestra Build Definition, y para esto agregamos 2 tareas haciendo clic en el botón respectivo:
Nos aparecerá una pantalla ya muy conocida, donde buscaremos, las dos tareas vinculadas a Sonar, y agregaremos a ambas.
Como puede entenderse es necesario agregar tanto la tarea de inicios como de fin de análisis, ya que es así como lo hemos visto al hacer la prueba desde linea de comandos, de igual manera es necesario reordenar las tareas para que la de inicio se ejecute antes que la compilación, y esta antes de la del fin del análisis, como se ve en la imagen siguiente:
De acuerdo, hemos configurado la secuencia como le gusta a SQ, pero aun no hemos hecho la configuración respectiva, asi que vamos a las propiedades de la tarea de inicio:
Como se puede ver la parte correspondiente a los no son nada del otro mundo, correspondiendo a lo que ya vimos en la prueba por linea de comandos, la diferencia fundamental esta en la configuración del , que en este caso ya tenia configurada en mi instancia de VSTS, así que vamos a ver rápidamente como hacer ese enlace, para lo cual haremos clic en el enlace que dice Manage, lo cual nos derivara a una pestaña extra, así:
Haremos clic en New Service Endpoint, elegiremos Generic:
Y entonces llenaremos los datos de conexión a nuestra instancia de SQ:
Nótese dos detalles importantes, el nombre de la conexión es SonarQube esto ha ayudado a que haya sido fácil identificar el servidor al configurar la tarea, y ademas que los datos de usuario y password son los que configuramos pasos arriba, de ahí la importancia de no quedarnos con los valores por defecto.
Perfecto, ya tenemos configurada la conexión entre nuestro VSTS y nuestro SonarQube, debemos comentar que el paso de “cierre” de análisis no requiere configuración adicional, por lo que ya tenemos configurada nuestra Build Definition para enlazarse con SonarQube, así que encolaremos una Build manualmente, luego de lo cual deberíamos poder ver en el histórico de Builds que todas las tareas hayan pasado como “verde”, así:
Revisemos los detalles del segundo paso “Fetch the Quality Profile…”
Como podemos ver, lo que se ha efectuado son tareas preparatorias: archivos de configuración, rulesets, algo sencillo.
Ahora por contra veamos el cuarto paso “Finish the analysis and upload…”
Si, bastante información, solo estamos viendo la ultima parte, y como siempre nos refiere hacia la URL donde podremos acceder a los resultados del análisis, algo a lo que también podíamos acceder desde la pantalla resumen de nuestra Build:
Listo, ya tenemos configurada la conexión, pero eso no queda ahí, ahora nos corresponde cosas adicionales, definir que nivel de calidad se considerara como inaceptable, dando como fallido el paso respectivo, excluir archivos del proceso de análisis (imprescindible si trabajamos con librerías de JavaScript), enlazar con StyleCop, análisis de históricos, etc, etc…
Como siempre, quedo a la espera de sus consultas.