Prueba de calidad del código code-quality-testing
Descubra cómo funcionan las pruebas de calidad del código de las canalizaciones y cómo pueden mejorar la calidad de las implementaciones.
Introducción introduction
Las pruebas de calidad del código evalúan el código de la aplicación en función de un conjunto de reglas de calidad. Es el propósito principal de una canalización solo de calidad de código y se ejecuta inmediatamente después del paso de compilación en todas las canalizaciones de producción y no de producción.
Consulte la Configuración de la canalización de CI/CD para obtener más información sobre los distintos tipos de canalizaciones.
Reglas de calidad de código understanding-code-quality-rules
Las pruebas de calidad del código analizan el código fuente para asegurarse de que cumple determinados criterios de calidad. Una combinación de SonarQube y un examen a nivel de paquete de contenido usando OakPAL implementa este paso. AEM Hay más de 100 reglas, que combinan reglas genéricas de Java y reglas específicas de la. AEM AEM Algunas reglas específicas de los se basan en las prácticas recomendadas de ingeniería de códigos y se conocen como reglas de calidad de código personalizadas.
Puede descargar la lista completa actual de reglas mediante este vínculo.
Clasificaciones en tres niveles three-tiered-gate
Los problemas identificados por las pruebas de calidad del código se asignan a una de las tres categorías.
-
Crítico: problemas que causan un fallo inmediato de la canalización.
-
Importante: problemas que hacen que la canalización entre en estado de pausa. Un administrador de implementación, un administrador de proyectos o un propietario empresarial pueden anular los problemas y permitir que continúe la canalización. De forma alternativa, pueden aceptar los problemas, lo cual haría que la canalización se detenga con un error.
-
Información: problemas que se proporcionan exclusivamente con fines informativos y que no afectan la ejecución de la canalización
Clasificaciones ratings
Los resultados de este paso se entregan como Clasificaciones.
En la tabla siguiente se resumen las clasificaciones y los umbrales de fallo de cada una de las categorías críticas, importantes e informativas.
B = Al menos 1 vulnerabilidad menor
C = Al menos 1 vulnerabilidad importante
D = Al menos 1 vulnerabilidad crítica
E = Al menos 1 vulnerabilidad de bloqueo
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
Definido por el coste de corrección pendiente de los olores de código como un porcentaje del tiempo que ya ha pasado a la aplicación
- A = <=5 %
- B = 6-10 %
- C = 11-20 %
- D = 21-50 %
- E = >50 %
Definido por una combinación de cobertura de línea de prueba unitaria y cobertura de condición mediante la fórmula:Coverage = (CT + CF + LC)/(2*B + EL)
CT
= Condiciones que se han evaluado comotrue
al menos una vez al ejecutar las pruebas unitariasCF
= Condiciones que se han evaluado comofalse
al menos una vez al ejecutar las pruebas unitariasLC
= Líneas cubiertas = líneas_por_cubrir - líneas_descubiertasB
= número total de condicionesEL
= número total de líneas ejecutables (líneas_por_cubrir)
Se define como el número de líneas involucradas en bloques duplicados. Un bloque de código se considera duplicado en las siguientes condiciones.
Proyectos que no son de Java:
- Debe haber al menos 100 tokens sucesivos y duplicados.
- Estos tokens deben propagarse por lo menos:
- 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 Java:
- Debe haber al menos 10 instrucciones sucesivas y duplicadas, independientemente del número de tokens y líneas.
Las diferencias en la sangría, así como en los literales de cadena, se omiten al detectar duplicados.
Tratar con falsos positivos dealing-with-false-positives
El proceso de digitalización de la calidad no es perfecto y a veces identifica incorrectamente los problemas que no son realmente problemas. Este estado se denomina falso positivo.
En estos casos, el código fuente se puede anotar con la anotación de Java estándar @SuppressWarnings
que especifica el ID de regla como atributo de anotación. Por ejemplo, un falso positivo común es que la regla SonarQube para detectar contraseñas codificadas puede ser agresiva sobre cómo se identifica una contraseña codificada.
El siguiente código es bastante común en un proyecto de 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 genera una vulnerabilidad de bloqueo. Pero después de revisar el código, se reconoce que este problema no supone una vulnerabilidad y se puede anotar el código con el ID de regla adecuado.
@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";
Sin embargo, si el código era realmente como se indica a continuación:
@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.
@SuppressWarnings
sea lo más específica posible (por ejemplo, anotar solo la instrucción o el bloque que causa el problema), también es posible realizar anotaciones en el nivel de clase.Optimización del análisis de paquetes de contenido content-package-scanning-optimization
Como parte del proceso de análisis de calidad, Cloud Manager realiza un análisis de los paquetes de contenido producidos por la compilación de Maven. Cloud Manager ofrece optimizaciones para acelerar este proceso, que es eficaz cuando se observan ciertas restricciones de empaquetado. La optimización más significativa se dirige a proyectos que producen un único paquete "todo", que contiene varios paquetes de contenido de la compilación, que se marcan como omitidos. Cuando Cloud Manager detecta este escenario, en lugar de desempaquetar el paquete “todo”, los paquetes de contenido individuales se analizan directamente y se ordenan según las dependencias. Por ejemplo, considere la siguiente salida de compilación.
all/myco-all-1.0.0-SNAPSHOT.zip
(content-package)ui.apps/myco-ui.apps-1.0.0-SNAPSHOT.zip
(skipped-content-package)ui.content/myco-ui.content-1.0.0-SNAPSHOT.zip
(skipped-content-package)
Si los únicos elementos dentro de myco-all-1.0.0-SNAPSHOT.zip
son los dos paquetes de contenido omitidos, entonces los dos paquetes incrustados se analizarán en lugar del paquete de contenido “todo”.
Para los proyectos que producen decenas de paquetes incrustados, se ha demostrado que esta optimización ahorra más de 10 minutos por ejecución de canalización.
Se puede producir un caso especial cuando el paquete de contenido “todo” contiene una combinación de paquetes de contenido omitidos y paquetes OSGi. Por ejemplo, si myco-all-1.0.0-SNAPSHOT.zip
contenía los dos paquetes incrustados mencionados anteriormente, así como uno o más paquetes OSGi, entonces se construye un nuevo paquete de contenido mínimo con solo los paquetes OSGi. Este paquete siempre tiene el nombre cloudmanager-synthetic-jar-package
, y los paquetes contenidos se colocan en /apps/cloudmanager-synthetic-installer/install
.
- Esta optimización no afecta a los paquetes que se implementan en AEM.
- La coincidencia entre paquetes de contenido incrustado y paquetes de contenido omitido depende de los nombres de archivo. Esta optimización no se puede producir si varios paquetes omitidos comparten el mismo nombre de archivo o si el nombre de archivo cambia durante la incrustación.