Conversemos de DevSecOps

En esta nueva sección de nuestro blog compartiremos la visión y experiencia de nuestro equipo de expertos en el ámbito del desarrollo de software y las tecnologías de información en general, quienes tocarán distintos temas relacionados con las tecnologías y metodologías utilizadas por Sovos para crear e implementar un mejor software, y entregarán tips y datos orientados a aportar valor a quienes deben trabajar en este ámbito, fundamental para las compañías que crean y utilizan soluciones para impulsar el negocio de sus clientes.


 

Pamela Ruiz, Senior QA Engineer

Utilización de Report Portal para monitoreo de pruebas funcionales

En la actualidad, cada vez poseemos más automatización en el área de pruebas funcionales, esto es, tests de API y End to End. Esto acelera el proceso de testing en regresiones y tiempo de user acceptance testing, entre otros, permitiéndonos avanzar en la implementación de CI/CD (continuous integration/continuous delivery).

Mientras mayor sea la automatización, menor será el tiempo de todo el proceso, por lo que se podrán entregar al cliente cambios de forma más rápida y segura.

La automatización genera algunos nuevos desafíos que necesitan un control; por ejemplo, pueden generarse falsos positivos, tests que fallan por inestabilidad, tests de mala calidad, etc. Por esta razón, es sumamente importante mantener un control sobre ellos.

La necesidad de mantener monitoreados los resultados de pruebas funcionales movió al equipo a realizar una investigación de herramientas disponibles.

Se encontró la herramienta de Report Portal y se llevó a cabo una prueba de concepto.
Lo primero que notamos fue su facilidad de instalación, al necesitar correr un único comando para instalar a través de Docker compose.

docker-compose -p reportportal up -d --force-recreate

Una vez ejecutado el comando, se chequean las imágenes de docker con el comando.

docker ps
01-docker-ps

En la imagen se observa la salida del comando docker ps.

 

Al levantar la aplicación de Report Portal por primera vez, y acceder a ella, nos encontramos con una pantalla de login:

02-report-portal

 

Y para acceder, utilizamos las credenciales temporales provistas por Report Portal.
Una vez ingresados al sistema podemos crear dashboards, diferentes proyectos, analizar las ejecuciones, etc.

Los dashboards son completamente configurables. En la siguiente imagen podemos ver un ejemplo:

03-dashboard-configurable

 

En este caso contamos con las estadísticas de todas las ejecuciones, dividiendo los tests en distintas posibles categorías.

Una de las propiedades más interesantes de esta herramienta es la posibilidad de ir aprendiendo en base a los análisis que realizamos (cuáles son fallos de productos, tests skippeados, fallos de ambiente, etc). Este aprendizaje está basado en inteligencia artificial.

Algunos de los problemas con los que nos enfrentamos al utilizar esta herramienta fueron los tipos de reportes soportados.

Report Portal soporta diferentes tipos de reportes, pero el de mejor visibilidad de datos fue JUnit. En nuestros tests automatizados generamos otros tipos de reportes, por lo que se realizaron scripts para adaptarlos al formato de JUnit aceptado por Report Portal:

 

04-report-portal-junit

Hay diferentes opciones de importación de datos hacia Report Portal, incluyendo la instalación de agentes, el envío de datos en tiempo real (durante la ejecución de tests), y otros.

Para evitar un aumento de tiempos en la ejecución de tests y la instalación de agentes, optamos por realizar la carga importando los reportes a través de la API de Report Portal. Desarrollamos un script para este propósito.

Lo primero es importar el archivo del reporte, ya adaptado a Junit, y comprimido en un archivo .zip:

05-junit-zip

Luego necesitábamos agregar información de la ejecución -como el número de build- y linkear al job de Jenkins ejecutado:

06-build-jenkins

Obtenemos el ID del archivo importado y agregamos la información que necesitamos incluir en los atributos y descripción del launch.

Cada nuevo reporte genera en Report Portal algo llamado launch, que es similar a una nueva ejecución. Para que la herramienta tome el historial de ejecuciones de cada test, el launch debe tener un mismo nombre. Si este se modifica, se crean nuevas versiones cada vez.

Por ejemplo, inicialmente importábamos los reportes con el número de build en su nombre,

07-build-nombre

lo que generaba el siguiente gráfico de trend:

08-grafica-trend

 

Luego extrajimos el número de build del nombre y pudimos obtener un gráfico con el historial.

09-build-grafico-histtorial

 

También nos permite ver el historial de cada test case.

010-historial-test-case

 

En conclusión, hasta ahora la herramienta de Report Portal nos sirve para mantener un constante monitoreo sobre todo tipo de pruebas funcionales, incluyendo algunos unit tests.

Pudimos enseñarle a la herramienta a reconocer ciertos tipos de resultados para clasificar futuras ejecuciones, y podemos fácilmente observar los resultados desde los gráficos dispuestos en los dashboards.

En la forma en la que lo trabajamos nos resultó útil poder utilizar diferentes tipos de reportes, adaptarlos a la herramienta mediante un script e importarlos en Report Portal con la información necesaria, tanto de los tests, como el link hacia la herramienta de ejecución, que en este caso es Jenkins.

Conversemos de DevSecOps

En esta nueva sección de nuestro blog compartiremos la visión y experiencia de nuestro equipo de expertos en el ámbito del desarrollo de software y las tecnologías de información en general, quienes tocarán distintos temas relacionados con las tecnologías y metodologías utilizadas por Sovos para crear e implementar un mejor software, y entregarán tips y datos orientados a aportar valor a quienes deben trabajar en este ámbito, fundamental para las compañías que crean y utilizan soluciones para impulsar el negocio de sus clientes.


 

Pamela Ruiz, Senior QA Engineer

Aplicación de pruebas de performance de API en proyectos de Sovos

En estos tiempos, donde el mercado es muy competitivo, la calidad pasó a un primer plano en la evaluación que realizan los clientes para elegir un producto.

La rapidez en los tiempos de respuesta de servicios o eventos ha cobrado mucha relevancia, a tal punto que -y según se ha analizado estadísticamente- es muy probable que un usuario abandone un producto si debe esperar más de 3 segundos.

Para entregar siempre las mejores soluciones a sus clientes, uno de los focos de Sovos en el área de calidad está puesto en las pruebas de performance. En esta línea se armaron equipos dedicados exclusivamente a todas las tareas no funcionales, que trabajan estrechamente con el equipo de CloudOps para contar con la infraestructura necesaria tanto para las etapas de desarrollo, como las finales, incluyendo producción.

Una de las primeras tareas que tuvo el equipo de performance fue el desarrollo, precisamente, de un framework para pruebas de performance. En Sovos se utilizan 2 herramientas open source, K6 y Jmeter, para el desarrollo de scripts para pruebas.

Los resultados de estas pruebas se guardan en InfluxDB, una base de datos especialmente diseñada para almacenar datos de este tipo. Grafana es la herramienta elegida para consumir los datos almacenados y procesarlos para mostrarlos mediante gráficos y tablas.

 

resultados-influxdb-grafana-db

 

La estrategia utilizada para el desarrollo de pruebas se basa, primeramente, en evaluar los endpoints más utilizados por los usuarios, testearlos bajo diferentes cargas y analizar los resultados, no solo en cuanto a tiempos de procesamiento, sino también, en cantidad de errores obtenidos provocados por la concurrencia.

Es recomendable que para el análisis de los resultados se cuente con herramientas de monitoreo como AppDynamics o Jaeger, que muestran en tiempo real lo que sucede con cada componente del sistema, permiten seguir el flujo de algunos requests para observar la distribución de tiempos que ocupa en todo su procesamiento e identifican si alguno de ellos está provocando cuellos de botella.

 

trace-request-jaeger

 

En la imagen se observa el trace de un request desde Jaeger.

También observamos qué sucede a nivel de base de datos; si hay bloqueos, si algún pedido necesita índices para alguna tabla, si el pool de conexiones es suficiente, etc.

 

recursos-db-appdynamics

recursos-db-appdynamics-2

 

En la imagen se observa la utilización de recursos de base de datos desde AppDynamics.

Durante esta primera etapa de análisis se realizan las tareas de forma manual, probando diferentes escenarios. Por ejemplo, aumentando los usuarios concurrentes de forma gradual, partiendo desde 10, hasta llegar a 100 o 150 usuarios sucesivamente en el caso de un ambiente pequeño.

 

A continuación, desarrollaremos un ejemplo implementado en uno de los proyectos de Sovos:

Como primer paso se desarrolla el script implementando un setup -que es común a todos los scripts- por lo que se utiliza el llamado a un script externo para evitar la duplicidad de código.

Luego de realizado el setup, se ejecuta la prueba en donde establecemos el endpoint a utilizar junto con sus headers, y también se le agrega una corroboración de que la respuesta sea la que estamos esperando. Estas comprobaciones de respuesta se aplican en todos aquellos casos en los que tenemos requests dinámicos, para asegurar no solo que devuelve el código http esperado, sino también, que contamos con la información requerida.

Generamos un reporte csv con las métricas de las pruebas, así como también un reporte de errores XML en el se registra qué datos se enviaron, el código de respuesta obtenido y el cuerpo del mensaje de respuesta.

 

test-plan-jmeter

Imagen del test plan desde Jmeter.

 

test-antes-despues-cambios-codigo

Resultados de las pruebas antes y después de los cambios de código.

 

En uno de nuestros endpoints realizamos una primera ejecución en el ambiente de QA con distintos escenarios, variando la cantidad de usuarios concurrentes entre 10 y 100 usuarios. Se encontraron mejoras para realizar a nivel de código y se ejecutaron nuevamente las mismas pruebas para poder comparar el impacto de los cambios realizados.

En este caso tuvimos una mejora notable, observando una disminución en los tiempos promedios de respuesta de 100 segundos a 30 segundos en el escenario de mayor concurrencia (100 usuarios virtuales).

De esta manera, encontramos los endpoints más críticos, para poder trabajar sobre ellos y aplicar mejoras.

Luego de esta primera etapa, procedemos a establecer corridas automáticas de forma semanal durante la noche para evitar bloquear los ambientes bajos. Estas corridas se realizan para mantener el control y detectar los problemas de performance antes de que lleguen a producción, donde principalmente observamos si los cambios realizados durante ese tiempo tuvieron impacto a nivel de performance. Luego de algunas ejecuciones, se establecen umbrales aceptables de variación, para alertar cuando en algún momento se supera alguno de esos umbrales.

Conversemos de DevSecOps

En esta nueva sección de nuestro blog compartiremos la visión y experiencia de nuestro equipo de expertos en el ámbito del desarrollo de software y las tecnologías de información en general, quienes tocarán distintos temas relacionados con las tecnologías y metodologías utilizadas por Sovos para crear e implementar un mejor software, y entregarán tips y datos orientados a aportar valor a quienes deben trabajar en este ámbito, fundamental para las compañías que crean y utilizan soluciones para impulsar el negocio de sus clientes.


 

Pamela Ruiz, Senior QA Engineer

Medición y visualización de performance para procesos batch

Por lo general, al medir performance de nuestras APIs, en Sovos buscamos obtener distintas métricas, como tiempos de respuesta, cantidad de errores, transacciones procesadas por minuto, cuellos de botella en el flujo y recursos utilizados en los servidores, entre otros. La finalidad es realizar un análisis de los datos obtenidos y aplicar mejoras en nuestros productos, para proveer la mejor calidad a nuestros clientes.

Para ello utilizamos herramientas como JMeter y K6, entre otras, para la ejecución de pruebas; AppDynamics para el monitoreo en tiempo real y Grafana e InfluxDB para la recolección y muestra de datos.

En este caso, como base de datos para almacenar las métricas, se seleccionó InfluxDB, la que es utilizada específicamente para almacenar información de métricas y datos para análisis en tiempo real. Esta herramienta de almacenamiento es plenamente compatible con Grafana, utilizada para detallar los resultados mediante gráficos.

A diferencia de las API, al medir la performance de procesos batch -que por lo general corren en modo background como servicios o procesos de Windows/Linux- no es tan relevante el tiempo de respuesta de estos procesos (aunque a veces es útil tener el dato para saber la capacidad de procesamiento de nuestro sistema), ya que el cliente no se encuentra activamente esperando una respuesta, sino que se evalúan principalmente métricas como recursos utilizados durante el procesamiento.

Para este tipo de pruebas se realizan una serie de pedidos para encolar procesos batch, y analizar el comportamiento del sistema durante el procesamiento. En nuestro caso, utilizamos JMeter para simular a usuarios realizando los pedidos.

Para la medición de recursos utilizados en un servidor usamos Telegraf, un agente que se instala en los servidores (en nuestro caso Windows) y se comunica con InfluxDB.

Dentro de los productos de Sovos utilizamos los llamados batch processing. Estos son procesos tipo batch que toman desde unos pocos minutos hasta varias horas en completar su ciclo, dependiendo del volumen de datos a procesar. Por lo general son utilizados para importar, transformar, exportar o transmitir altos volúmenes de datos.

Para su funcionamiento, el cliente envía un pedido para iniciar este proceso y recibe un acknowledgment para saber que su pedido fue tomado con éxito.

Por detrás, comienza el proceso con un orquestador de procesos que maneja los pedidos, encolándolos y derivándolos al primer procesador que se encuentre disponible, asignándoles el estado de claimed.

Los batch processing trabajan como una máquina de estados, pasando por diferentes estados. En la imagen podemos observar un esquema simplificado de los mismos.

 

batch-processing-maquina-estados

 

Para nuestro equipo era esencial contar con métricas relacionadas con estos procesos de larga duración, que incluyen:

Si bien no contábamos con ninguna herramienta para monitorear las métricas que necesitábamos en cuanto a tiempos y cantidades, notamos que durante el procesamiento se utiliza una tabla en la base de datos para registrar los distintos cambios de estado durante todo el proceso.

 

verificacion-jobs-fallas

 

El equipo de trabajo pudo tomar ventaja de ello y utilizar esta tabla como base para obtención de métricas.

Se crearon diferentes consultas a la base de datos para obtener datos tales como:

Se tomaron en cuenta los estados principales, como enqueued, running, failed y completed.

Este trabajo podía llevarse a cabo de forma manual y en el momento, pero no era un proceso eficiente a la hora de realizar un análisis de lo sucedido a lo largo del tiempo. Se requería una herramienta que pudiera procesar los datos y mostrarlos de forma amigable mediante gráficos.

De esta manera, para automatizar el proceso de análisis de los resultados y contar con un historial de información, se creó una aplicación con node.js en la que establece una conexión con la base de datos de Oracle, desde donde se extraen las métricas, y una conexión con InfluxDB, en donde se almacenan los datos una vez procesados.

 

automatizar-procesos-influxdb

 

Este proceso de node se realiza cíclicamente cada 20 segundos para recolectar los datos.

Se armó un dashboard en Grafana para mostrar los resultados, tal como muestra la siguiente imagen:

 

dashboard-grafana-resultados

 

Estos gráficos son totalmente configurables y es posible ajustar a diferentes fechas y horas, de acuerdo con lo que se necesite analizar.

Adicionalmente, esta aplicación se encuentra dockerizada para facilitar el deployment mediante Puppet. Si bien hoy en día está configurada para utilizar en un ambiente específico, en un futuro podríamos aplicar nuevas configuraciones para diferentes ambientes y base de datos según se necesite.

Además pueden agregarse nuevas consultas a la base de datos en caso de que se requieran nuevas métricas, incluyendo números de procesos cancelados por el usuario y número de procesos en algún estado en específico, entre otras.

A continuación se observa un dashboard en Grafana para monitoreo de utilización de recursos:

 

dashboard-grafana-monitoreo-recursos

 

En conclusión, se logró crear un framework de monitoreo para los procesos de larga duración basados en tecnologías open source.

Cada nuevo conocimiento y avance va sumando para tener una mejor base de monitoreo y mejor información al momento de realizar un análisis más profundo al encontrar errores o al realizar pruebas de carga, permitiendo encontrar con mayor facilidad los cuellos de botella, tanto para nuestras APIs como para nuestros procesos de batch.