SonarQube 5.x, mejorando más y más

Hace muy poco que finalizó la ronda de versiones 4.x con el anuncio de la versión 4.5.1 LTS (Long Term Support) y al mismo tiempo ya estaba el equipo de SonarSource sentado para recopilar y hablar de todo lo que esta por llegar a las versiones 5.x.

Hay muchas cosas nuevas y todas ellas son muy interesantes, en excentia, partners oficiales de SonarSource en Latinoamérica y partners oficiales y exclusivos en España, queremos compartir todas las novedades previstas con vosotros.

En la serie 5.x el objetivo de la plataforma SonarQube es convertirse en:

• Una plataforma completamente operativa para los desarrolladores: para gestionar fácilmente la deuda técnica diaria, y con características de navegación cruzada por el código "reales"

• Una plataforma mejorada para las grandes organizaciones: a través de el aumento de rendimiento y de la escalabilidad para grandes instancias, y no más acceso a base de datos durante el análisis (¡por fin!)

Gestión diaria de la deuda técnica

La página de evidencias como el centro de todo

Si un día llegas a casa y te encuentras con que tienes todo el suelo inundado de agua, ¿qué es lo primero que haces? ¿Agarras una fregona, o buscas y reparas la fuente donde está la fuga de agua? Es exactamente lo mismo con la deuda técnica. Lo primero por lo que debes preocuparte es parar el incremento de deuda (reparar la fuga) antes de ponerte a reparar la deuda técnica existente (fregar el suelo).

Hasta ahora, la plataforma siempre había sido genial para encontrar en que partes del código se localizaba la deuda técnica, pero no era el mejor sitio donde los desarrolladores pudieran gestionar la deuda técnica que introducen cada día. Actualmente lo que puedes hacer es suscribirte a las notificaciones de nuevas evidencias, pero eso es todo. Eso es un problema porque los desarrolladores deberían poder ser capaces de acudir a SonarQube para que les ayude en su día a día.

Para conseguir cambiar esto se hará que la página de evidencias sea el centro. Se va a rediseñar para permitir a los usuarios filtrar evidencias de forma eficiente gracias a las "facetas". Por ejemplo, será mucho menos costoso visualizar "todas las evidencias bloqueantes y críticas asignadas a mí en el proyecto X" con una distribución por regla. Otro ejemplo: "todas las evidencias críticas de JavaScript en el proyecto X".

Con estas nuevas capacidades, la página de evidencias sustituirá inevitablemente la antigua página de "detalle de evidencias" (Issues Drilldown) y eliminará de un plumazo todas sus limitaciones (poca flexibilidad en los filtros, conteos que no se actualizan cuando las evidencias se modifican desde la interfaz de usuario, ...). En otras palabras, a la hora de enfrentarse a las evidencias y la deuda técnica, los usuarios irán redirigidos al nuevo espacio de evidencias, y se beneficiarán de todas esas nuevas características.

Las evidencias tendrán también un mecanismo de etiquetas para ayudar a los desarrolladores a clasificar la deuda técnica pendiente. Cada evidencia heredará las etiquetas asociadas de su regla, para que sea más fácil encontrar evidencias de "seguridad", por ejemplo. Y los usuarios serán capaces de añadir o eliminar etiquetas adicionales siempre que lo deseen. Esto les ayudará a tener una visión más clara de lo que significa la deuda técnica en su proyecto: ¿se trata principalmente de defectos o simplemente de errores de convención de nombres? ¿evidencias relacionadas con un antiguo "framework-legacy" o evidencias de la nueva arquitectura de desarrollo?

El desarrollador como centro de la gestión de la deuda técnica

Todas estas características en la página de evidencias son inútiles si tú, como desarrollador, siempre tienes que acudir a la página y jugar con las diferentes "facetas" que te permiten encontrar lo que estas buscando. En lugar de eso, SonarQube debe saber que es lo que te preocupa a ti como desarrollador, por ejemplo, debe ser capaz de identificar e informar sobre "tú" código. Esta es la principal razón por la que el plugin SCM Activity acabará muriendo y resurgirá como una funcionalidad del núcleo en SonarQube - con soporte para Git y Subversion (y otros gestores a través de plugins dedicados). Esto permitirá que SonarQube sepa los cambios que pertenecen a cada desarrollador, y automáticamente se asignen las evidencias a los usuarios correspondientes. Ya no hará falta que tengas que navegar por todo la deuda cada día para encontrar la que tú has generado.

Navegación cruzada "real" por el código

Desde hace algún tiempo SonarQube es capaz de enlazar ficheros bajo determinadas circunstancias - a través de duplicados (puedes navegar por los ficheros que tienen bloques en común con tu código) o a través de los métodos de test (cuando la cobertura por test está activada, puedes navegar por el fichero de test que cubre tu código, viceversa). Pero esta navegación es limitada, y el concepto de espacio de trabajo asociado es la prueba que lo demuestra: el contexto está restringido al contexto del visor de componentes.

Gracias a todas las mejoras incluidas en los plugins de lenguajes, ahora SonarQube será capaz de saber si una variable o función está definida dentro o fuera del fichero actual, y llevarte a su definición. Esta nueva funcionalidad puede ayudar a los desarrolladores a entender las evidencias mucho más rápido y mejor aún, sin necesidad de abrir el entorno de desarrollo (IDE). Nunca más tendrás que imaginarte donde un atributo que no debe ser nulo pero lo es está definido. Serás capaz de moverte a la definición de la clase desde la interfaz de usuario. Y si navegas muy lejos del punto inicial, SonarQube te ayudará a recordar el camino, y te dará acceso rápido a los ficheros que has accedido recientemente - independientemente de donde estén. De hecho, el objetivo es conseguir que SonarQube sea el punto central en el que se pueda echar un vistazo al código sin invertir mucho esfuerzo en ello (sin tener que acudir a un equipo de desarrollo, abrir un IDE, hacer un pull del código del repositorio, compilar, ...).


Escalabilidad y rendimiento

SonarQube comenzó como una aplicación pequeña que ha ido progresando gradualmente hasta conseguir ser una aplicación para grandes organizaciones. Pero todavía tiene un talón de Aquiles que es la base de datos relacional de la que depende. Este es el cuello de botella cada vez que se intenta mejorar la escalabilidad y el rendimiento. Y lo que es peor, dar soporte a cuatro diferentes fabricantes de base de datos multiplica la complejidad de escribir sentencias SQL eficientes. Así que incluso manteniendo la base de datos como el lugar donde asegurar la integridad de los datos, actualizar esos datos con los resultados de los análisis deberían hacerse a través del servidor, y las búsquedas tienen que usar una tecnología diseñada para hacer consultas a grandes cantidades de datos. La tecnología utilizada ha sido Elasticsearch (ES).

A través de las versiones 5.x, la mayoría de dominios se irán indexando lentamente en ES, y como resultado se obtendrá una mejora sustancial del rendimiento a la hora de requerir esos datos. Esto además permitirá abrir nuevos frentes para implementar funcionalidad que era inaccesible con una base de datos relacional - como las "facetas" incluidas en las páginas de reglas y evidencias. Y como ES está diseñado para escalar, SonarQube se beneficiará de su habilidad para obtener un rendimiento espectacular cuando se añadan nuevas funcionalidades en instancias grandes con millones de evidencias y líneas de código.

Desacoplando los análisis de la base de datos

El asunto más votado en JIRA es uno de los principales retos cuando se trata de configurar SonarQube en grandes compañías: ¿por qué se hacen tantas consultas a la base de datos cuando se hace un análisis? ¿por qué incluso se necesita una conexión? Esto provoca problemas de rendimiento (cuando los análisis se realizan en maquinas que no están "cerca" de la base de datos) y también problemas de seguridad (los credenciales de base de datos son necesarios para los análisis y algunos puertos especiales deben estar abiertos).

Las versiones 5.x irán progresivamente eliminando las dependencias con la base de datos para que al final el análisis simplemente genere un informe que se envía al servidor para procesarlo. Esto no solo permitirá evitar los problemas de rendimiento y de seguridad, sino que también permitirá mejorar el diseño de toda la arquitectura de la plataforma, estableciendo diferentes componentes con sus propias responsabilidades. Al final, el análisis solamente tendrá que invocar a los analizadores que proveen los plugins de lenguajes, consiguiendo que el análisis sea tremendamente rápido. Todo lo relacionado con la agregación de datos y los históricos (que requieren muchos accesos a la base de datos) se manejarán desde un motor dedicado en la parte servidora. La integración en el IDE también se beneficiará de esta separación porque solo se ejecutarán los plugins de lenguajes en lugar de todo el proceso, permitiendo la oportunidad de ejecutar análisis en tiempo real.

Mecanismo mejorado de autenticación y autorización