Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

En esta versión normativa "PRE-RELEASE" se establecen los siguientes alcances y actualizaciones para la verificación de la calidad del código fuente:

1. Actualización de Sonarqube:

   • La herramienta Sonarqube se actualiza de la versión 7.9.4 a la versión 9.9 LTS.
   • Esta actualización incluye mejoras significativas en la plataforma, proporcionando herramientas más avanzadas para la evaluación y mejora de la calidad del código.

2. Nuevas Características y Mejoras de Sonarqube 9.9 LTS:

   • Nueva Métrica "Security Hotspots Reviewed":
     • Introducción de la métrica "Security Hotspots Reviewed" que permite identificar y gestionar áreas del código que pueden ser vulnerables a problemas de seguridad.
   • Actualización de Umbrales de Calidad:
     • Los umbrales de calidad se revisan y actualizan para incorporar las capacidades avanzadas de Sonarqube 9.9 LTS, garantizando una evaluación más precisa y rigurosa de la calidad del código.
     • Los umbrales ahora incluyen la nueva métrica "Security Hotspots Reviewed" para una mejor gestión de la seguridad del código.

3. Tabla de Plugins Instalados:

   • Se actualiza la lista de plugins instalados en Sonarqube para reflejar las versiones más recientes y compatibles con Sonarqube 9.9 LTS.
   • Los plugins proporcionan funcionalidades adicionales y soporte para múltiples lenguajes y herramientas específicas, mejorando la capacidad de análisis y detección de problemas.

4. Inclusión de SonarLint:

   • Se incluye un nuevo apartado dedicado a SonarLint, una herramienta de análisis estático que se integra con entornos de desarrollo integrados (IDE) como Eclipse, IntelliJ IDEA y Visual Studio.

   • SonarLint permite a los desarrolladores identificar y corregir problemas de calidad y seguridad en tiempo real, durante el proceso de desarrollo, asegurando que el código cumpla con los estándares establecidos desde las primeras fases del desarrollo.

   • Características de SonarLint:

     • Detección Temprana de Errores
     • Integración con Sonarqube
     • Soporte para Múltiples Lenguajes
     • Análisis Instantáneo y Sugerencias de Corrección

Con esta versión normativa "PRE-RELEASE", se busca establecer una base sólida para la verificación de la calidad del código fuente, mejorando tanto la seguridad como la eficiencia del desarrollo del software. Las herramientas actualizadas y las nuevas métricas aseguran que los desarrolladores cuenten con los recursos necesarios para mantener altos estándares de calidad en sus proyectos.

Esta actualización aclara el manejo de la rama support  en escenarios que requieren versiones en paralelo (por ejemplo, evolución de la aplicación y evolución tecnológica ejecutadas en paralelo) 

Se incluyen las siguientes puntualizaciones en la Pauta 14,  sobre el manejo de la rama de soporte:

a. La rama de soporte se crea desde la rama master. Concretamente desde el tag del que se desea mantener una versión en paralelo.

b. La evolución del producto que vaya a mantenerse viva, estará contenida en las ramas develop y master. La de soporte se utilizará para aquel mantenimiento y/o evolución que tenga una fecha de finalización. 

c. La rama de soporte realizará funciones de "develop" y "master" para la evolución funcional de la aplicación.

d. La rama support se crea siguiendo la nomenclatura support/version, teniendo versión como máximo 2 dígitos W.X. , donde W: Identifica el dígito mayor de la versión. X: Identifica el dígito medio de la versión. Será el jefe de proyecto quien decida el nombre de la rama y los dígitos de la misma.

e. Los tags en la rama support continuarán siendo de 4 dígitos. Sonarqube trabaja con tags, por lo que el análisis de código no se verá afectado.

f. Cuando se finalice la evolución tecnológica, si es necesario, habrá que "volcar" en develop, la rama soporte. Para hacerlo, se crearán previamente una rama de mejora en develop y una rama de mejora en support,  haciendo el merge de dichas ramas y resolviendo los conflictos u adaptaciones que sean necesarios.

g. Las ramas de soporte, nunca se cerrarán directamente sobre la rama develop.

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible

 En caso de no estar publicado el componente que necesita puede consultar y utilizar temporalmente los componentes de los siguientes Storybooks

• SB RRHH
• SB Ecofin

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura( l-arquitectura.stic.sspa@juntadeandalucia.es ) y trataremos de daros soporte con la mayor brevedad que nos sea posible