Este articulo hace parte de una serie de artículos y podrás tener todas las consideraciones al leerlos todos.
Podemos usar varios tipos de análisis.
Cuando usamos Sonar como analizador de código estático, debemos tener en cuenta 2 conceptos:
Código Nuevo: Se refiere al código nuevo que agregamos a nuestra aplicación, aplica para los Pull Request (PRs) o para los branch de corta duración; cuando se realiza el análisis solo tiene en cuenta el código nuevo insertado o el código que hemos modificado, debemos tener en cuenta en este punto que dependiendo de los cambios que hacemos sobre el código se pueden detectar como código nuevo algunas líneas u otras, pero también podemos modificar el modo en que Sonar detecta las líneas de código nuevas (lo explicamos más adelante).
Código Completo: Se refiere a TODO el código que tenemos en nuestra aplicación, solo aplica para los branchs de larga duración definidos dentro de SonarCloud; cuando se realiza el análisis se tiene en cuenta el código nuevo configurado, pero podemos definir Quality Gates que tengan en cuenta todo el código.
Opciones para definir el código nuevo
Existen 4 opciones para definir el código nuevo:
Versión previa: Es la configuración por defecto y se refiere a un aumento de versión sobre el código. La versión puede leerse dependiendo de como realizamos nuestro análisis, así cuando usamos Maven, se lee desde el archivo pom.xml, cuando usamos Gradle se lee desde el archivo build.gradle y cuando usamos cualquier otro método de análisis, se debe especificar la propiedad sonar.projectVersion.
Versión específica: Permite especificar una versión desde la que definimos que todo el código extra que ingresa al proyecto es nuevo, así podríamos definir que el código nuevo es todo el código que se construya desde la versión 2.0.0 y siempre que se realice el análisis se determinará como código nuevo todo lo que le siga de ahí en adelante.
Numero de días: Permite definir un numero de días desde los cuales el código se detecta como nuevo, muy útil si tenemos una cadencia fija de despliegues y queremos mantener la versión durante dicho periodo de tiempo.
Fecha específica: Permite definir una fecha desde la cual indicamos que el código es nuevo, útil para casos donde podemos indicar que el código anterior es legacy y después de determinada fecha comenzamos a realizar otro tipo de prácticas.
Todas las opciones anteriores pueden definirse por proyecto, sin embargo, recomendamos tener una definición estándar para la mayoría de proyectos y solo en casos especiales ajustar con otras configuraciones.
En caso de no usar correctamente la versión del proyecto y mantenerla en la misma versión, sonar usará otros algoritmos para identificar el código nuevo, donde se tiene en cuenta si la línea de código fue modificada.
Una nota importante es que cuando hablamos de PRs, cambia un poco el concepto, ya que el código nuevo dependerá del código dentro del PR, es decir, independiente de las configuraciones anteriores, el código a tener en cuenta es el código modificado en el PR.
Ahora teniendo en cuenta todo lo anterior y que SonarCloud tiene funcionalidades muy similares a las de una licencia empresarial de SonarQube, podemos realizar los siguientes tipos de análisis y te explicamos que tener en cuenta si haces análisis desde una herramienta de CI/CD o usando el SonarScanner:
Al usar análisis automático, las propiedades no son requeridas, ya que la integración del sistema Git y SonarCloud ya lo hace por ti, pero debes ver si tu sistema Git es compatible con SonarCloud para este tipo de análisis (Puedes encontrar más información en nuestra anterior publicación del tema).
Análisis de PRs
Este tipo de análisis revisará el código nuevo generado sobre el PR y permitirá definir en nuestro sistema SCM si permitimos realizar el PR o no. Para que SonarCloud detecte que el análisis que realizar es de PRs, debes tener en cuenta las siguientes propiedades al momento de realizar el análisis:
sonar.pullrequest.key: Es el identificador único del PR (ej. sonar.pullrequest.key=5).
sonar.pullrequest.branch: Es el branch desde el que se realiza el PR (ej. sonar.pullrequest.branch=feature/my-new-feature).
sonar.pullrequest.base: Es el branch con el que se espera realizar el merge (ej. sonar.pullrequest.base=develop). Por defecto su valor es “master”.
Debemos tener muy presente que las propiedades anteriores ÚNICAMENTE deben agregarse cuando hagamos un análisis de un PR, de lo contrario confundiremos a SonarCloud y el resultado no será el definido para nuestro Workflow.
Análisis para branches de corta duración
Este tipo de análisis revisará el código nuevo incluido en el branch, teniendo en cuenta el tipo de opción que configuraste para el código nuevo en el proyecto, las propiedades que debes tener en cuenta son:
sonar.branch.name: Nombre del branch para analizar.
sonar.branch.target: Nombre del branch base o donde se pretende hacer un merge posterior. Por defecto su valor es “master”
En caso de incluir el target branch, el análisis será muy similar al de PRs.
En caso de que tu equipo realice análisis sobre PRs y todo el código se lleve a los diferentes branches usando PRs, recomendamos no usar este tipo de Análisis, ya que es exactamente igual al del PR y sería redundante; por otro lado, si cuentas con un proceso donde tienes definidos varios branchs de larga duración y realizas merges entre ellos, podrías usar este tipo de análisis para algunos de ellos y usar el de larga duración únicamente para el ambiente productivo (ej. usar análisis de corta duración para develop y release, pero de larga duración para master).
Análisis para branches de larga duración
Este tipo de análisis revisará el código nuevo del proyecto, la diferencia es que podemos podemos tener Quality Gates para el código nuevo y para todo nuestro código, por ejemplo, para código nuevo exigir una cobertura de código mínima del 80%, mientras que para el proyecto entero definimos una cobertura del 50%.
Recuerda que los Quality Gate que trae sonar por defecto solo tienen en cuenta el nuevo código.
Para este caso, la única propiedad a tener en cuenta es:
sonar.branch.name: Nombre del branch para analizar, pero el nombre del branch debe estar configurado como de larga duración en SonarCloud; por defecto el branch de larga duración de un proyecto es master, main o cualquier branch que siga el patrón: (branch|release)-.*.
Ten presente que las propiedades estudiadas anteriormente son excluyentes, es decir, si tenemos un PR no podemos enviar las propiedades de un branch de corta duración o viceversa.
Recuerda definir una estrategia de branchs para tu equipo de desarrollo y define Quality Gates y tipos de análisis apropiados para dicha estrategia.
En conclusión al utilizar una herramienta con mayor capacidad debemos definir claramente los tipos de análisis que queremos tener en nuestro workflow y el equipo de desarrollo debe conocerlos para realizar un correcto entendimiento de los issues y security spots que se puedan generar.
Comentarios