Ahora que he actualizado mi entorno de análisis de código completo con los upgrades de SonarQube, de SonarQube-Runner y de Jenkins con las últimas versiones, es hora de actualizar también mi repositorio de aplicaciones y demos.

Para mi trabajo de consultor de Calidad, tengo todos tipos de «proyectos», es decir, análisis de código fuente, para varios tipos de procesos de calidad (Integración Continua, Quality Gate, Evaluación de Calidad, etc.) y para todos tipos de tecnologías. Recordemos que SonarQube no es solamente una herramienta de código abierto que analiza Java o otros lenguajes de nuevas tecnologías, sino que también es muy útil para aplicaciones Legacy Cobol, SAP-ABAP, cliente-servidor, etc.

Así que voy a aprovechar la relativa baja de actividad de fin de año para organizar un poco mis demos … comenzando con PL/SQL. Con el tiempo, he recogido todo tipo de scripts para crear base de datos, o paquetes de programas de tratamientos de base de datos, y vamos a tener la oportunidad de:

• Ver cómo organizo mi entorno de análisis de código para realizar evaluaciones de calidad de aplicaciones,
• Configurar y realizar un análisis PL/SQL con SonarQube.
• Personalizar el perfil de reglas PL/SQL proporcionado por SonarQube.
• Examinar las diferentes reglas y benas practicas que ofrece SonarQube para el lenguaje de programación de base de datos de Oracle.

No sé cuántos articulos se necesitarán para cubrir este tema ‘SonarQube y PL/SQL’, me gusta dejar un poco de margen para improvisar si encuentro unas cosas que me parecen interesantes mientras avanzamos. Además, probablemente voy a detener esta serie temporalmente por el Año Nuevo (y celebraciones). Entonces, es probable que esto nos llevará hasta enero.

Organización del entorno de análisis

En primer lugar, recordemosnos cómo he organizado mi entorno de análisis de código. Obviamente, no es absolutamente necesario hacer lo mismo, pero aún así, recomiendo adoptar unas normas. Sobre todo si trabajas en equipo.

No quieres que te llaman durante las vacaciones, porque nadie está capaz de seguir con tu auditoría de código, que se ha retrasado por culpa del cliente para no entregar el código de su aplicación a tiempo. Y el que debe continuar con esta tarea no sabe cómo has organizado tu trabajo.

Incluso si trabajas solo, como freelance por ejemplo, es deseable seguir siempre el mismo proceso, Corres el riesgo de no recordar dónde demonios has guardado el archivo de configuración de tal análisis realizado hace 2 años, y que estás buscando ahora.

Entonces, así es como yo trabajo:

• Un directorio dedicado a todos mis análisis: ‘C:\SRC’.
• Differentes carpetas por cada tecnologia (J2EE, ABAP, Cobol, Repositorio de otras tecnos, …) y especialmente, una carpeta dedicada a mis demos: ‘C:\SRC\Demo’.
• En esta carpeta, un directorio para cada demo de cada tecnologia: ‘C:\SRC\Demo\J2EE’, ‘C:\SRC\Demo\Cobol’, …, y ‘C:\SRC\Demo\PLSQL’ para mi demo.

En cada una de estas carpetas, tengo tres directorios:

• ‘Delivery’ para guardar las diferentes versiones de aplicaciones entregadas.
• ‘Conf’ para gestionar todos los archivos de configuración, documentación, evaluaciones, hojas de calculo, presentaciones, etc.
• ‘Source’ para copiar el código que analizar.

¿Por qué no tener un solo directorio para analizar una versión? En primer lugar porque tengo que analizar las sucesivas versiones. Por ejemplo, un cliente quiere una auditoría porque no es muy contento con su proveedor y desea comprobar la calidad del código entregado. Primero vamos a analizar la versión inicial recibida por este outsourcer cuando se encargó del mantenimiento, y luego la versión final que ha realizado para el cliente. Mediante el análisis de estas dos versiones, podemos determinar las diferencias en términos de defectos, de complejidad y de capacidad de mantenimiento.

Más importante aún, a veces se necesita cambiar el código, por varias razones:

• Un archivo tiene un problema que detiene el análisis. Por ejemplo, un programa viejo, que ya no se usa, pero no compila bien y causa un error de parsing.
• Tengo que organizar el código de manera diferente. Es increíble el número de arquitectos que han reinventado las mejores prácticas de organización de paquetes y directorios.
• La entrega contiene una multitud de directorios .svn que llenan el espacio del disco duro, y retrasan el análisis.

Si tienes un servidor, te recomiendo utilizar un disco duro para los softwares y el disco más grande y más rapido para almacenar el código fuente y hacer los análisis.

Por supuesto, si trabajas en un equipo de proyecto, es probable que tengas una herramienta de gestión de la configuración (SCM) y, por tanto, un entorno diferente. El mio será ‘C:\SRC\Demo\PLSQL\Source’.

Veremos en el próximo post como configurar y realizar un análisis código PL/SQL. Hasta luego.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.