Descubra cómo funcionan las pruebas de calidad del código de las canalizaciones y cómo pueden mejorar la calidad de las implementaciones.
Durante la ejecución de la canalización, se capturan varias métricas que se comparan con los indicadores de rendimiento clave (KPI) definidos por el propietario del negocio o con los estándares establecidos por Adobe Managed Services.
Estos se informan utilizando un sistema de clasificación de tres niveles como se define en la siguiente sección
Para obtener más información sobre las pruebas admitidas por Cloud Manager para AEM as a Cloud Service, consulte la AEM documentación as a Cloud Service..
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.
En una canalización de solo calidad de código, no se pueden anular los errores importantes en la puerta de calidad de código, ya que el paso de prueba de calidad de código es el último paso de la canalización.
Este paso 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, y se ejecuta inmediatamente después del paso de compilación en todas las canalizaciones que no sean de producción y producción. Consulte el documento Configuración de canalizaciones que no sean de producción para obtener más información.
Las pruebas de calidad del código analizan el código fuente para asegurarse de que cumple determinados criterios de calidad. Esto se implementa mediante una combinación de análisis de SonarQube, examen de nivel de paquete de contenido mediante OakPAL y 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. Algunas de las reglas específicas del AEM se crean en función de las prácticas recomendadas de AEM Engineering y se denominan Reglas de calidad de código personalizadas.
Puede descargar la lista completa de reglas mediante este vínculo.
Los resultados de las pruebas de calidad del código se entregan como clasificaciones. En la tabla siguiente se resumen las clasificaciones de diversos criterios de prueba.
Nombre | Definición | Categoría | Umbral de error |
---|---|---|---|
Clasificación de seguridad | A = Sin vulnerabilidades 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 |
Importante | < B |
Clasificación de fiabilidad | A = No hay errores B = Al menos 1 error menor C = Al menos 1 error mayor D = Al menos 1 error crítico E = Al menos un error de bloqueo |
Importante | < C |
Puntuación de mantenimiento | 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
|
Importante | < A |
Cobertura | 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)
|
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 | 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:
|
Información | > 1% |
Compatibilidad del Cloud Service | Número de problemas de compatibilidad con Cloud Service identificados | Información | > 0 |
Consulte Definiciones de métricas de SonarQube para obtener información más detallada.
Para obtener más información sobre las reglas de calidad de código personalizadas ejecutadas por Cloud Manager, consulte el documento Reglas de calidad de código personalizadas.
El proceso de digitalización de la calidad no es perfecto y a veces identifica incorrectamente los problemas que no son realmente problemáticos. Esto se conoce como falso positivo.
En estos casos, el código fuente se puede anotar con el Java estándar @SuppressWarnings
anotación 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 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 bloqueo. Pero después de revisar el código, reconoce que no se trata de una vulnerabilidad y 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 así:
@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.
Aunque es recomendable hacer que la variable @SuppressWarnings
anotación lo más específica posible, es decir, anotar solo la declaración o el bloque específico que causa el problema; es posible realizar anotaciones a nivel de clase.
Cloud Manager ejecuta el Comprobaciones de AEM de seguridad en el entorno de ensayo después de la implementación e informa del estado a través de la interfaz de usuario. 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 panel 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 rendimiento del código, estas comprobaciones de estado se organizan en categorías y se comunican utilizando el sistema de enlace de tres niveles. La única distinción es que no hay umbral en el caso de las pruebas de seguridad. Todos los controles de salud se aprueban o no.
La siguiente tabla enumera las comprobaciones de estado.
Nombre | Implementación de comprobación de estado | Categoría |
---|---|---|
Deserialización firewall Adjuntar preparación de API está en un estado aceptable. | Disposición de la API de anexo de cortafuegos de deserialización | Importante |
El firewall de deserialización funciona. | Cortafuegos de deserialización funcional | Importante |
Se ha cargado el cortafuegos de deserialización. | Cortafuegos de deserialización cargado | Importante |
AuthorizableNodeName la implementación no expone el ID autorizado en el nombre/ruta del nodo. |
Generación del nombre de nodo con autorización | Importante |
Se han cambiado las contraseñas predeterminadas. | Cuentas de inicio de sesión predet. | Importante |
El servlet de GET predeterminado de Sling está protegido de ataques DOS. | Sling Get Servlet | Importante |
El controlador de script Java de Sling está configurado correctamente. | Sling Java Script Handler | Importante |
El controlador de script JSP de Sling está configurado correctamente. | Controlador de script JSP de Sling | Importante |
SSL está configurado correctamente. | Configuración SSL | Importante |
Obviamente, no se encuentran políticas de perfil de usuario inseguras. | Acceso predet. del perfil de usuario | Importante |
El filtro Referente de Sling está configurado para evitar ataques de CSRF. | Filtro de referente de Sling | Importante |
El Administrador de biblioteca de HTML de Adobe Granite está configurado correctamente. | Configuración del administrador de bibliotecas HTML de CQ | Importante |
El paquete de soporte CRXDE está deshabilitado. | Compatibilidad con CRXDE | Importante |
El paquete Sling DavEx y el servlet están desactivados. | Comprobación de estado de DavEx | Importante |
El contenido de muestra no está instalado. | Paquetes de contenido de ejemplo | Importante |
Tanto el filtro de solicitud WCM como el filtro de depuración WCM están desactivados. | Configuración de filtros WCM | Importante |
El paquete y el servlet Sling WebDAV están correctamente configurados. | Comprobación de estado de WebDAV | Importante |
El servidor web está configurado para evitar el secuestro de clics. | Configuración de servidor web | Importante |
La replicación no utiliza la variable admin usuario. |
Replicación y usuarios de transporte | Información |
Cloud Manager ejecuta pruebas de rendimiento para programas de AEM Sites. La prueba de rendimiento se ejecuta durante aproximadamente 30 minutos girando los usuarios virtuales (contenedores) que simulan que los usuarios reales acceden a páginas en entornos de ensayo para simular tráfico. Estas páginas se encuentran usando un rastreador.
El número de usuarios virtuales o contenedores que Cloud Manager genera depende de los KPI (tiempo de respuesta y vistas de página/min) definidos por el usuario con la variable Propietario empresarial función durante crear o editar el programa. Según los KPI definidos, se enviarán hasta 10 contenedores que simulen usuarios reales. Las páginas seleccionadas para la prueba se dividen y se asignan a cada usuario virtual.
Antes del inicio del periodo de prueba de 30 minutos, Cloud Manager rastreará el entorno de ensayo utilizando un conjunto de una o más URL semilla configuradas por el ingeniero de éxito del cliente. A partir de estas direcciones URL, el HTML de cada página se inspecciona y los vínculos se atraviesan de forma predeterminada. Este proceso de rastreo está limitado a un máximo de 5000 páginas. Las solicitudes del rastreador tienen un tiempo de espera fijo de 10 segundos.
Las páginas se seleccionan mediante tres conjuntos de 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 bloques.
Páginas Live populares : esta opción está seleccionada para asegurarse de que se prueben las páginas más populares a las que acceden los clientes activos. Cloud Manager leerá el registro de acceso y determinará las 25 páginas más visitadas por los clientes activos para generar una lista de las principales Popular Live Pages
. La intersección de estas que también están presentes en el entorno de ensayo se rastrea en el entorno de ensayo.
Otras páginas Live : esta opción está seleccionada para asegurarse de que se prueben las páginas que no están dentro de las 25 páginas activas más populares y que pueden no ser populares, pero que son importantes para probarlas. De forma similar a las páginas en directo más populares, se extraen del registro de acceso y también deben estar presentes en el entorno de ensayo.
Nuevas páginas : esta opción está seleccionada para probar las páginas nuevas que pueden haber sido implementadas únicamente en el entorno de ensayo y que aún no están en producción, pero que deben probarse.
Puede elegir entre uno y los tres conjuntos del 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 seleccionan las tres, el 33 % del total de vistas de página se destinará a cada conjunto. Si se seleccionan dos, el 50 % va a cada conjunto. Si se selecciona uno, el 100 % del tráfico se destina a ese conjunto.
Consideremos este ejemplo.
Durante el periodo de prueba de 30 minutos:
((200 * 0.5) / 25) * 30 = 120
((200 * 0.5) / 3000) * 30 = 1
Cloud Manager ejecuta pruebas de rendimiento para programas de AEM Sites solicitando páginas como usuario no autenticado de forma predeterminada en el servidor de publicación de ensayo durante un periodo 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, así como 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 enlace de tres niveles.
Métrica | Categoría | Umbral de error |
---|---|---|
Tasa de error de solicitud de página | Importante | >= 2% |
Tasa de uso de CPU | Importante | >= 80 % |
Tiempo de espera de IO de disco | Importante | >= 50% |
Tiempo de respuesta del percentil 95 | Importante | >= KPI a nivel de programa |
Tiempo de respuesta máximo | Importante | >= 18 segundos |
Vistas de página por minuto | Importante | < KPI de nivel de programa |
Uso del ancho de banda del disco | Importante | >= 90% |
Utilización del ancho de banda de red | Importante | >= 90 % |
Solicitudes por minuto | Información | >= 6000 |
Consulte la sección 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.
Las instancias de autor y publicación se supervisan durante el periodo de la prueba. Si no se obtiene ninguna métrica para una instancia, esa métrica se comunica como desconocida y el paso correspondiente falla.
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 del sitio.
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 un string
y la contraseña deben almacenarse en un secretString
variable. Si se especifican ambos, cada solicitud del rastreador de prueba de rendimiento y los usuarios virtuales de prueba contendrán estas credenciales como autenticación HTTP Basic.
Para establecer estas variables utilizando la CLI de Cloud Manager, ejecute:
$ aio cloudmanager:set-pipeline-variables <pipeline id> --variable CM_PERF_TEST_BASIC_USERNAME <username> --secret CM_PERF_TEST_BASIC_PASSWORD <password>
Consulte el documento Parche de variables de canalización de usuarios para aprender a utilizar la API de .
Cloud Manager ejecuta pruebas de rendimiento para programas de AEM Assets cargando recursos repetidamente durante un periodo de prueba de 30 minutos.
Para las pruebas de rendimiento de Assets, el ingeniero de éxito del cliente creará un cloudmanager
usuario y contraseña 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. Esto no se debe eliminar de la instancia de autor ni cambiar sus permisos. Si lo hace, es probable que se produzca un error en las pruebas de rendimiento de Assets.
Los clientes pueden cargar sus propios recursos para realizar pruebas. Esto se puede hacer desde el Configuración de canalización o Editar en el Navegador. Los formatos de imagen comunes, como JPEG, PNG, GIF y BMP, son compatibles con los archivos Photoshop, Illustrator y Postscript.
Si no se carga ninguna imagen, Cloud Manager utilizará una imagen predeterminada y documentos de PDF para realizar pruebas.
La distribución de cuántos recursos de cada tipo se cargan por minuto se establece en la variable Configuración de canalización o Editar en el Navegador.
Por ejemplo, si se utiliza una división 70/30 y hay 10 activos cargados por minuto, se cargarán 7 imágenes y 3 documentos por minuto.
Cloud Manager creará una carpeta en la instancia de autor utilizando el nombre de usuario y la contraseña según la configuración del CSE en la variable Requisitos de integración para obtener más información. 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 varias métricas a 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.
Consulte el documento Configurar canalizaciones de producción para obtener más información. Consulte el documento Configurar el programa para aprender a configurar el programa y definir los KPI.
Hay varias métricas disponibles en la 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.
Uso de CPU
Tiempo de espera de E/S de disco
Tasa de error de página
Uso del ancho de banda del disco
Utilización del ancho de banda de red
Tiempo de respuesta máximo
Tiempo de respuesta del percentil 95
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. Lo más significativo es la optimización realizada para proyectos que generan un paquete de contenido único, generalmente denominado 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.
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, luego 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
.