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

Durante la ejecución de canalización, el software captura una serie de métricas. A continuación, estas métricas se comparan con los indicadores clave de rendimiento (KPI) definidos por el propietario de la empresa. O bien, se comparan con los estándares establecidos por Adobe Managed Services.

Estos resultados se notifican mediante un sistema de clasificación de tres niveles.

Clasificaciones en tres niveles three-tiered-ratings

Hay tres puertas en la canalización:

Para cada una de estas puertas, hay una estructura de tres niveles para los problemas identificados por la puerta.

Prueba de calidad del código code-quality-testing-step

Este paso de prueba evalúa la calidad del código de la aplicación, que es el propósito principal de una canalización de solo calidad de código. Esto se ejecuta inmediatamente después del paso de generación en todas las canalizaciones que sean y no sean de producción. Para obtener más información, vaya a Configuración de canalizaciones que no sean de producción.

Las pruebas de calidad del código analizan el código fuente para asegurarse de que cumple determinados criterios de calidad.

El software lo implementa mediante una combinación de análisis de SonarQube, un examen de nivel de paquete de contenido mediante OakPAL y una validación de Dispatcher mediante la herramienta de optimización de Dispatcher.

Hay más de 100 reglas que combinan reglas genéricas de Java y reglas específicas de AEM. AEM AEM Algunas de las reglas específicas de la se crean en función de las prácticas recomendadas de ingeniería de códigos de la aplicación y se denominan Reglas de calidad de código personalizadas.

Los resultados de las pruebas de calidad del código se muestran como una clasificación resumida en esta tabla.

Tratar con falsos positivos dealing-with-false-positives

El proceso de análisis de la calidad no es perfecto y a veces identifica incorrectamente problemas que no son realmente problemáticos. Este escenario se denomina como 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 aumentará entonces la vulnerabilidad del bloqueador. 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.

Pruebas de seguridad security-testing

Cloud Manager ejecuta las comprobaciones de estado de seguridad de AEM existentes en el entorno de ensayo después de la implementación, e informa del estado a través de la IU. Los resultados se agregan de todas las instancias AEM del entorno.

Estas mismas comprobaciones de estado se pueden ejecutar en cualquier momento a través de la consola web o el tablero de operaciones.

Si alguno de los casos indica un error en una comprobación de estado determinada, todo el entorno falla en esa comprobación de estado. Al igual que con las pruebas de calidad y el rendimiento de código, estas comprobaciones de estado se organizan en categorías y se comunican utilizando el sistema de acceso de tres niveles. La única distinción es que no hay umbral si hay pruebas de seguridad. Todas las comprobaciones de estado se aprueban o no.

La siguiente tabla enumera las comprobaciones de estado.

Pruebas de rendimiento performance-testing

AEM Sites aem-sites

Cloud Manager ejecuta pruebas de rendimiento para programas de AEM Sites. La prueba de rendimiento se ejecuta durante aproximadamente 30 minutos. Hace circular usuarios virtuales (contenedores) que simulan que los usuarios reales acceden a páginas en entornos de ensayo para emular el tráfico. Estas páginas se encuentran mediante un rastreador.

Usuarios virtuales virtual-users

Cloud Manager mueve usuarios virtuales o contenedores según los indicadores clave de rendimiento (KPI) (tiempo de respuesta y vistas de página por minuto) establecidos por la función Propietario empresarial. Estos KPI se establecen al crear o editar el programa.

Según los indicadores clave de rendimiento (KPI) definidos, se pondrán en marcha hasta diez contenedores que simulen usuarios reales. Las páginas seleccionadas para la prueba se dividen y se asignan a cada usuario virtual.

Rastreador crawler

Antes del inicio del período de prueba de 30 minutos, Cloud Manager rastrea el entorno de ensayo utilizando un conjunto de una o más URL semilla configuradas por el ingeniero de éxito del cliente. Empezando por estas URL, el HTML de cada página se inspecciona y los vínculos se atraviesan siguiendo un equilibrio de carga en amplitud.

Conjuntos de páginas para pruebas page-sets

Tres conjuntos de páginas seleccionan las páginas. Cloud Manager utiliza los registros de acceso de las instancias de AEM en los entornos de producción y ensayo para determinar los siguientes depósitos.

Distribución del tráfico entre conjuntos de páginas seleccionados distribution-of-traffic

Puede elegir entre uno y los tres conjuntos de la ficha Pruebas de su configuración de canalización. La distribución del tráfico se basa en el número de conjuntos seleccionados. Es decir, si se escogen los tres, se destinará a cada conjunto el 33 % del total de vistas de página. Si se seleccionan dos, va el 50 % a cada conjunto. Si se selecciona uno, el 100 % del tráfico se destina a ese conjunto.

Consideremos este ejemplo.

Durante el período de prueba de 30 minutos, sucede lo siguiente:

Pruebas y creación de informes testing-reporting

Cloud Manager ejecuta pruebas de rendimiento para programas de AEM Sites solicitando páginas como un usuario no autenticado de forma predeterminada en el servidor de publicación de ensayo durante un período de prueba de 30 minutos. Mide las métricas generadas por el usuario virtual (tiempo de respuesta, tasa de error, vistas por minuto, etc.) para cada página y varias métricas de nivel de sistema (CPU, memoria, datos de red) para todas las instancias.

En la tabla siguiente se resume la matriz de prueba de rendimiento utilizando el sistema de acceso de tres niveles.

Consulte Pruebas de rendimiento autenticadas para obtener más información sobre el uso de la autenticación básica para las pruebas de rendimiento de Sites y Assets.

Pruebas de rendimiento autenticadas authenticated-performance-testing

Si es necesario, los clientes de AMS con sitios autenticados pueden especificar un nombre de usuario y una contraseña que Cloud Manager utilizará para acceder al sitio web durante las pruebas de rendimiento de los sitios.

El nombre de usuario y la contraseña se especifican como variables de canalización con los nombres CM_PERF_TEST_BASIC_USERNAME y CM_PERF_TEST_BASIC_PASSWORD.

El nombre de usuario debe almacenarse en una variable string y la contraseña debe almacenarse en una variable secretString. Si se especifican estas dos variables, cada solicitud del rastreador de prueba de rendimiento y de los usuarios virtuales de prueba contendrá estas credenciales como autenticación básica de HTTP.

Para establecer estas variables utilizando la CLI de Cloud Manager, ejecute lo siguiente:

$ aio cloudmanager:set-pipeline-variables <pipeline id> --variable CM_PERF_TEST_BASIC_USERNAME <username> --secret CM_PERF_TEST_BASIC_PASSWORD <password>

Consulte la documentación de API de Variables de canalización de usuarios de parches para aprender a utilizar la API.

AEM Assets aem-assets

Cloud Manager ejecuta pruebas de rendimiento para programas de AEM Assets cargando recursos repetidamente durante 30 minutos.

Requisito de incorporación onboarding-requirement

Para las pruebas de rendimiento de Assets, el ingeniero de éxito del cliente creará un usuario y contraseña de cloudmanager durante la incorporación del autor al entorno de ensayo. Los pasos de la prueba de rendimiento requieren un usuario llamado cloudmanager y la contraseña asociada configurada por su CSE.

Este método debe permanecer en la instancia de autor con sus permisos inalterados. Su modificación o eliminación puede provocar errores en las pruebas de rendimiento de Assets.

Imágenes y recursos para pruebas assets-for-testing

Los clientes pueden cargar sus propios recursos para realizar pruebas. Esto se puede hacer desde la pantalla Configuración de canalización o Editar. Los formatos de imagen frecuentes, como JPEG, PNG, GIF y BMP, son compatibles con los archivos Photoshop, Illustrator y Postscript.

Si no se carga ninguna imagen, Cloud Manager utiliza una imagen predeterminada y documentos de PDF para realizar las pruebas.

Distribución de recursos para pruebas distribution-of-assets

La distribución de cuántos recursos de cada tipo se cargan por minuto se establece en la pantalla Configuración de canalización o Editar.

Por ejemplo, si se utiliza una división 70/30 y se cargan 10 activos por minuto, se cargarán siete imágenes y tres documentos por minuto.

Pruebas y creación de informes testing-and-reporting

Cloud Manager crea una carpeta en la instancia de autor utilizando el nombre de usuario y la contraseña según la configuración del CSE. A continuación, los recursos se cargan en la carpeta mediante una biblioteca de código abierto. Las pruebas ejecutadas por el paso de prueba de Assets se escriben mediante una biblioteca de código abierto. Tanto el tiempo de procesamiento de cada recurso como diversas métricas de nivel de sistema se miden en la duración de las pruebas de 30 minutos. Esta función puede cargar imágenes y documentos de PDF.

Gráficos de resultados de pruebas de rendimiento performance-testing-results-graphs

Hay varias métricas disponibles en el Cuadro de diálogo Prueba de rendimiento

Los paneles de métricas se pueden expandir para mostrar un gráfico, proporcionar un vínculo a una descarga o ambos.

Esta funcionalidad está disponible para las siguientes métricas.

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 son efectivas cuando se observan ciertas restricciones de empaquetado.

La optimización clave es para proyectos que generan un solo paquete «todo», que contiene otros paquetes de contenido producidos por 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.

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.