Quality Gates de SonarQube, fomentando DevOps

Los Quality Gates realizan una importante función de protección para tu aplicación, así que aprovéchalos para mejorar su calidad y conseguir un entorno DevOps.

Cuando hablo sobre SonarQube me vienen a la cabeza principalmente 2 funciones:

  • Analizador de código: Gracias a su importante número de reglas configuradas, los lenguajes que abarca, y la posibilidad de programar nuevas reglas, SonarQube se convierte en una potente herramienta capaz de detectar los defectos que pueden tirar abajo tu software
  • Formación sobre programación: Esas mismas reglas, contienen un complemento muy importante, que es la información que facilita SonarQube con detalles como, por ejemplo: un ejemplo de código incorrecto, ejemplo del correcto, referencias a normativa o estándares, y por supuesto, una explicación de por qué ese fragmento es problemático.

Sin embargo, también cuenta con una función muy importante, y es la de los Quality Gates, o Umbral de Calidad, en la traducción a español.

Así que, hoy toca hablar de ello, y sobre cómo esta característica se convierte en clave a la hora de establecer DevOps en el desarrollo de software.

¿Qué son los Quality Gates de SonarQube?

El Quality Gate es la función que utiliza SonarQube para asegurar el cumplimiento de la Política de Calidad en tu organización.

Si buscas en la documentación oficial, hablará básicamente de si el código se puede desplegar en producción, pero si lo integras en un ciclo DevOps, puede aprovecharlo para seguir rutas alternativas.

Así que, básicamente, trataría de responder a la pregunta:

¿Puede este código seguir avanzando en el ciclo de desarrollo?

Y como siguientes pasos, podemos hablar tanto de pasar a producción, como a otro entorno de pruebas, fusionarse con otra rama, enviar notificaciones, etc…

Para responder a la pregunta anterior, un Quality Gate está compuesto de una serie de condiciones que debe cumplir el código analizado para decidir si “Pasa” o “No pasa”.

Condiciones de un Quality Gate

¿Y cómo se determinan esas condiciones?

Pues muy fácil, simplemente se debe establecer una serie de métricas, como, por ejemplo: calificación global de bugs, vulnerabilidades o code smells, porcentaje de cobertura de pruebas, de código duplicado, etc… junto al valor que consideremos oportuno y necesario para que la aplicación disponga del mínimo de calidad aceptable.

Quality Gate

Quality Gate predeterminado de SonarQube

Como he hablado alguna vez anteriormente, su filosofía es la de centrarse en el código nuevo, por eso en este caso, las condiciones se enfocarán únicamente en el código desarrollado sobre la última iteración o release.

 Y el Quality Gate predeterminado para todos los proyectos, consta de las siguientes condiciones:

  • Cobertura: Indica el porcentaje de código que está cubierto por pruebas unitarias. Así si nuestras pruebas unitarias se encargan de validar una serie de métodos que ocupan 2000 líneas en proyecto que en total contiene 10000 líneas, podemos determinar que la cobertura de nuestro código es de un 5%.

SonarQube establece en el Quality Gate predeterminado que la cobertura debe ser superior al 80%

  • Líneas duplicadas: También se trata de un porcentaje, que en este caso indica la cantidad de líneas que se repiten, en comparación con el total de líneas del proyecto. Así que espero que no seas de Ctrl+C y Ctrl+V fácil 😉

En este caso, se establece que este valor sea inferior al 3%

  • Calificación global de fiabilidad: Esta calificación se obtiene en relación a la severidad más alta de los bugs detectados.

Para esta métrica, se determina que la calificación debe ser A, lo que significa que no haya ningún bug.

  • Calificación global de seguridad: En esta ocasión, se refiere también a la severidad más alta, pero de las vulnerabilidades encontradas.

También debe ser A, lo que indica que no existiría ninguna vulnerabilidad en el código nuevo.

  • Calificación global de mantenibilidad: Esta condición difiere ligeramente de las otras dos de calificaciones globales. Y es que, en este caso, se mide el porcentaje de deuda técnica que existe en el código.

Lo que si coincide es que la calificación debe ser A, que vendría a ser que el porcentaje de deuda técnica es menor o igual al 5%.

¿Por qué son tan importantes los Quality Gates en DevOps?

Vale y ahora que ya sabes lo que son los Quality Gates y como se establecen, ¿cómo los podemos aprovechar en DevOps?

La principal ventaja sería la de determinar en qué casos, la herramienta CI/CD que estemos usando (Jenkins, Azure Devops, Gitlab, etc…) debe realizar el despliegue en el entorno escogido.

Por ejemplo, si estamos usando un pipeline en Jenkins para construir, inspeccionar y desplegar el código, el paso de inspección continua, sería el que serviría de filtro para, si pasa el Quality Gate, desplegar, o, por el contrario, si no lo pasa, notificar del error y no desplegar hasta que se corrija, se suba de nuevo al repositorio de código, y empiece de nuevo el ciclo de despliegue continuo.

Además, en este caso, uno de los elementos clave para desarrollar software de calidad, es la de contar con elementos de medición objetivos, y no subjetivos.

Por esto, si siempre aplicamos el mismo Quality Gate a cada avance de nuestro proyecto, estaremos midiendo siempre igual, y la calidad se mantendrá al evaluar los mismos factores. Factores totalmente medibles y objetivos, no basados en opiniones (me gusta o no me gusta).

Por otro lado, esta decisión de si el ciclo debe continuar, no depende de una persona que lo valide y realice una determinada acción (dé el visto bueno, escriba un email o pulse un botón), sino que es automático, por lo no solo aumentarás la calidad del producto, sino que podrás realizar un mayor número de despliegues, y por lo tanto, obtener más feedback de los usuarios.


Así que ya sabes lo que debes decirle a los errores que pretendan entrar en tu código:

Fuentes:

Imagen portada:

Macrovector en Freepik.com

Deja un comentario