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.
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