Último post de nuestra serie sobre el análisis de la calidad de código PL/SQL con SonarQube.

La evaluación de la calidad de una aplicación no es sólo el análisis de código: eso, cualquiera puede hacerlo. El trabajo del consultor se basa en las siguientes preguntas: qué, por qué, cómo, cuánto.

• Qué: analizar los resultados. El tamaño, la complejidad y la duplicación de código, esto es lo que hemos visto en los articulos anteriores. Se examinan las cifras globales, el promedio, así como las tendencias en el tiempo, si hay varias versiones. Luego nos fijamos en las principales violaciónes de buenas prácticas, principalmente los Blockers y Criticals.
• ¿Por qué estos resultados?: investigamos las causas de los datos en el cuadro de mando SonarQube, el origen de los resultados encontrados.
• ¿Cómo remediar?: proponer un plan de acción. De hecho, varias propuestas de acción. Más adelante veremos que pensamos en diferentes planes en el corto, mediano y largo plazo.
• ¿Cuánto cuesta?: evaluar el coste de cada plan. Sigue leyendo →

Lo siento por el tiempo pasado desde el último post de esta serie sobre PL/SQL y SonarQube, pero estaba muy ocupado entre viajes, el trabajo y mi laptop que decidió abandonarme, por supuesto invocando la ley de Murphy para justificar fallar en el peor momento.

En los posts anteriores: después de configurar un análisis de código PL/SQL con SonarQube, hemos elaboraro nuestro propio Quality Profile con una orientación a la robustez, el rendimiento y la seguridad en las reglas Blockers y Criticals.

¿A que parece ahora nuestro dashboard SonarQube? Sigue leyendo →

Un post de síntesis, para esta serie sobre el análisis de código PL / SQL con SonarQube.

Después de configurar nuestro análisis con Jenkins, lo lanzamos y encontramos 17 defectos bloqueantes (Blockers), pero ninguna falta crítica (Criticals) con el perfil de calidad de SonarQube. De hecho, las 5 reglas Criticals eran desactivadas y también algunas otras normas de diferentes criticidades: 58 en un total de 132. Sigue leyendo →

Continuamos esta serie en el análisis de código PL/SQL con hoy las normas de tipo Majors.

Vimos antes cómo organizar nuestro entorno y configurar nuestro análisis de código con Jenkins y SonarQube.

Hemos creado nuestro propio Quallity Profile y revisado las reglas de tipo Blockers y Criticals, todas orientadas a Robustez (fiabilidad) y Seguridad.

Sigue leyendo →

En el post anterior de esta serie sobre el análisis de código PL/SQL con SonarQube, hemos visto las reglas Blockers de nuestro nuevo Quality Profile.

En esta ocasión, hemos encontrado tres violaciones de las mejores prácticas de programación PL/SQL cuyas consecuencias son tan graves que no se puede imaginar cualquier tolerancia. Lo qué justifica por tanto su condición de ‘bloqueadores’.

Tambien, se encuentra un total de 18 fallos para estas 3 reglas, y entonces este número limitado nos deja suponer que estas reglas son conocidas por el equipo del proyecto.

Por último, estos defectos pueden generar un error de lógica en la aplicación – una operación que nunca se puede realizar debido a que la condición correspondiente nunca se cumplirá – e incluso un crash de la aplicación. Sigue leyendo →

En el post anterior, hemos creado nuestro propio Quality Profile PL/SQL, activando todas las 132 reglas presentes en SonarQube. Luego, hemos ejecutado de nuevo nuestro análisis de código PL/SQL.

Pues vamos a poder trabajar con todas las normas de calidad del Quality Profile predeterminado de SonarQube y seleccionar las que nos interesan para crear un cuadro de mando para nuestro entorno de demos. Sigue leyendo →

En el post anterior, hemos configurado nuestro primer análisis PL/SQL con SonarQube y Jenkins. Lo ejecutamos, y luego podemos ver los resultados en el dashboard de SonarQube.

Será una oportunidad para examinar y explicar en los próximos articulos las reglas de SonarQube sobre las mejores prácticas de programación PL/SQL. Pero en primer lugar, vamos a ver lo que nos ofrece el Quality Profile PL/SQL de SonarQube. Sigue leyendo →

Hemos visto en el primero post de esta serie acerca de análisis de código PL/SQL con SonarQube, cómo he organizado mi entorno de análisis, con:

• una carpeta ‘C:\SRC\’ con todos mis proyectos,
• un subdirectorio por cada proyecto,
• y luego diferentes otras carpetas, incluyendo un directorio ‘..\Source’ donde localizamos el código que analizar.

Entonces, para nuestro análisis PL/SQL, el código se encontrara en la carpeta ’C:\SRC\Demo\PLSQL\Source’.

Vamos a ver ahora cómo crear y configurar un análisis SonarQube de este código PL/SQL, con Jenkins. Sigue leyendo →

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. Sigue leyendo →