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.

Explicación de las reglas de calidad del código

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.

NOTA

Puede descargar la lista completa de las 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 mayor
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 bloqueador
Importante < C
Clasificación de mantenimiento El costo de corrección sobresaliente de los olores de código es:
  • <>
  • 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 pruebas unitarias
CF = condiciones que se han evaluado en 'false' al menos una vez mientras se ejecutan pruebas unitarias
LC = líneas cubiertas = líneas_to_cover - líneas_descubiertas

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
NOTA

Consulte Definiciones de métricas para obtener definiciones más detalladas.

NOTA

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.

Tratamiento de 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 conoce como falso positivo.

En estos casos, el código fuente se puede anotar con la anotación estándar Java @SuppressWarnings que especifica el ID de 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.

NOTA

Aunque es recomendable que la anotación @SuppressWarnings sea lo más específica posible, es decir, que solo haga anotaciones en la sentencia o bloque específico que causa el problema, es posible realizar anotaciones en un nivel de clase.

NOTA

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.

En esta página

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free