Show Menu
TEMAS×

Prueba de calidad del código

La prueba de calidad del código evalúa la calidad del código de la aplicación. Es el objetivo central de una tubería de sólo calidad de código y se ejecuta inmediatamente después del paso de construcción en todos los gasoductos que no sean de producción y producción.
Consulte Configuración de la canalización CI-CD para obtener más información sobre los distintos tipos de canalizaciones.

Understanding Code Quality Rules

En la prueba de calidad del código, se analiza el código fuente para asegurarse de que cumple ciertos criterios de calidad. Actualmente, esto se implementa mediante una combinación de SonarQube y un examen a nivel de paquete de contenido con OakPAL. Existen más de 100 reglas que combinan reglas genéricas de Java y reglas específicas de AEM. Algunas de las reglas específicas de AEM se crean en base a las optimizaciones de AEM ingeniería y se denominan Reglas de calidad de código personalizado.
Puede descargar la lista completa de reglas aquí .
Puerta de tres niveles
Hay una estructura de tres niveles en este paso de prueba de calidad de código para los problemas identificados:
  • Crítico : Estos son problemas identificados por la puerta que causan un fallo inmediato de la tubería.
  • Importante : Estos son problemas identificados por la puerta que hacen que la tubería entre en estado de pausa. Un administrador de implementación, un jefe de proyecto o un propietario de empresa pueden anular los problemas, en cuyo caso la canalización continúa, o pueden aceptar los problemas, en cuyo caso la canalización se detiene con un error.
  • Información : Estos son problemas identificados por la puerta que se proporcionan exclusivamente con fines informativos y no tienen impacto en la ejecución de la tubería
Los resultados de este paso se entregan como clasificaciones .
La siguiente tabla resume los umbrales de clasificación y error para cada una de las categorías críticas, importantes y de información:
Nombre
Definición
Categoría
Umbral de error
Clasificación de seguridad
A = 0 Vulnerabilidad
B = al menos 1 vulnerabilidad
menor C = al menos 1 vulnerabilidad grave
D = al menos 1 vulnerabilidad crítica
E = al menos 1 vulnerabilidad de bloqueador
Crítico
< B
Clasificación de confiabilidad
A = 0 Error
B = al menos 1 Error menor
C = al menos 1 Error mayor
D = al menos 1 Error crítico E = al menos 1 Error de bloqueo
Importante
< C
Clasificación de mantenimiento
El costo de corrección sobresaliente de los olores de código es:
  • <=5% del tiempo que ya ha pasado a la aplicación, la clasificación es A
  • entre el 6 y el 10 % la calificación es B
  • entre el 11 y el 20 % la calificación es una C
  • entre el 21 y el 50 % la calificación es una D
  • cualquier cosa superior al 50% es una E
Importante
< A
Cobertura
Combinación de cobertura de la línea de prueba unitaria y cobertura de condición mediante esta fórmula:
Coverage = (CT + CF + LC)/(2*B + EL)
donde: CT = condiciones que se han evaluado en 'true' al menos una vez mientras se ejecutan las pruebas unitarias
CF = condiciones que se han evaluado en 'false' al menos una vez mientras se ejecutan las pruebas unitarias
LC = líneas cubiertas = líneas_to_cover - líneasdescubiertas
B = número total de condiciones
EL = número total de líneas ejecutables (lines_to_cover)
Importante
< 50%
Pruebas unitarias omitidas
Número de pruebas unitarias omitidas.
Información
> 1
Problemas abiertos
Tipos de problemas generales: Vulnerabilidades, errores y huecos de código
Información
> 0
Líneas duplicadas
Número de líneas involucradas en bloques duplicados.
Para que un bloque de código se considere como duplicado:
  • Proyectos que no son de Java:
  • Debe haber al menos 100 tokens sucesivos y duplicados.
  • Estos tokens deben propagarse al menos en:
  • 30 líneas de código para COBOL
  • 20 líneas de código para ABAP
  • 10 líneas de código para otros idiomas
  • Proyectos de Java:
  • Debe haber al menos 10 declaraciones sucesivas y duplicadas, independientemente del número de tokens y líneas.
Las diferencias en sangría y en literales de cadena se omiten al detectar duplicaciones.
Información
> 1%
Compatibilidad con Cloud Service
Número de problemas de compatibilidad con Cloud Service identificados.
Información
> 0
Consulte Definiciones de métricas para obtener definiciones más detalladas.
Para obtener más información sobre las reglas de calidad de código personalizadas ejecutadas por Cloud Manager, consulte Reglas de calidad de código personalizado.

Tratar con falsos positivos

El proceso de análisis de calidad no es perfecto y a veces identifica incorrectamente problemas que no son realmente problemáticos. Esto se denomina falso positivo .
En estos casos, el código fuente se puede anotar con la anotación estándar de Java @SuppressWarnings que especifica el ID de la regla como el atributo de anotación. Por ejemplo, un problema común es que la regla SonarQube para detectar contraseñas codificadas puede ser agresiva sobre cómo se identifica una contraseña codificada.
Para ver un ejemplo específico, este código sería bastante común en un proyecto AEM que tiene código para conectarse a algún servicio externo:
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

SonarQube generará una vulnerabilidad de bloqueador. Después de revisar el código, se identifica que no se trata de una vulnerabilidad y se puede anotar con la identificación de regla adecuada.
@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

Sin embargo, por otro lado, si el código era en realidad esto:
@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

A continuación, la solución correcta es quitar la contraseña codificada.
Si bien es recomendable que la anotación sea lo más específica posible, es decir, que solo haga una anotación de la sentencia o bloque específico que causa el problema, es posible realizar anotaciones a nivel de clase. @SuppressWarnings
Aunque no hay un paso explícito de la prueba de seguridad, todavía hay reglas de calidad de código relacionadas con la seguridad evaluadas durante el paso de calidad del código. Consulte Información general de seguridad para AEM como Cloud Service para obtener más información sobre la seguridad en Cloud Service.