Integrar el cliente API de JMeter con pipelines de CI/CD

Esta guía explica cómo ejecutar una prueba JMeter guardada de LoadFocus desde CircleCI, Azure DevOps, GitHub Actions, GitLab CI/CD o Jenkins, para que una prueba de rendimiento pueda aprobar o rechazar tu despliegue.

Tabla de Contenidos

• Enfoque General
• Integración con CircleCI
• Integración con Azure DevOps
• Integración con GitHub Actions
• Integración con GitLab CI/CD
• Integración con Jenkins
• Mejores Prácticas
• Solución de Problemas

Enfoque General

Independientemente de la plataforma de CI/CD, hay pasos comunes para integrar el Cliente API de JMeter de LoadFocus:

1. Instalar el cliente: Instala @loadfocus/loadfocus-api-client al inicio de tu workflow
2. Configurar credenciales: Guarda tu clave API y tu ID de equipo desde las variables secretas de tu plataforma
3. Ejecutar pruebas: Ejecuta una prueba JMeter guardada por su nombre, con umbrales
4. Procesar resultados: Lee la salida o guárdala con --format json
5. Tomar decisiones: run-test termina con el código de salida 1 cuando no se cumple un umbral o la ejecución falla, así que el paso del pipeline falla por sí solo

Los tres comandos, con --name igual al nombre exacto de una prueba que guardaste en LoadFocus:

npm install -g @loadfocus/loadfocus-api-client
loadfocus-api config set --apikey "$LOADFOCUS_API_KEY" --teamid "$LOADFOCUS_TEAM_ID"
loadfocus-api jmeter run-test --name "My_JMeter_Test" --thresholds "avgresponse<=200,errors==0"

Mejores Prácticas

Al integrar el Cliente API de JMeter de LoadFocus con tu pipeline de CI/CD, ten en cuenta estas buenas prácticas:

Seguridad

• Nunca codifiques tu clave API o tu ID de equipo directamente en la configuración de tu pipeline
• Usa el sistema de gestión de secretos de tu plataforma de CI/CD
• Restringe el acceso a los resultados de tus pruebas de rendimiento solo al personal autorizado

Configuración de Pruebas de Rendimiento

• Usa nombres de prueba descriptivos que incluyan la rama/entorno que se está probando
• Establece umbrales apropiados según los requisitos de rendimiento de tu aplicación
• Considera ejecutar diferentes perfiles de prueba para diferentes entornos (por ejemplo, pruebas más ligeras para dev, pruebas completas para staging)

Integración con el Pipeline

• Ejecuta las pruebas de rendimiento después de que las pruebas funcionales hayan pasado
• Considera ejecutar las pruebas de rendimiento en paralelo con otras tareas no bloqueantes
• Configura notificaciones para los fallos de las pruebas de rendimiento

Análisis de Resultados

• Almacena los resultados de las pruebas de rendimiento como artefactos para comparación histórica
• Considera implementar un análisis de tendencias para detectar la degradación del rendimiento a lo largo del tiempo
• Documenta las métricas de rendimiento de referencia para comparación

Solución de Problemas

Problemas Comunes

La Ejecución de la Prueba Falla

• Verifica que tu clave API y tu ID de equipo estén correctamente configurados
• Comprueba si has alcanzado el límite de pruebas simultáneas de tu cuenta
• Verifica que el nombre de la prueba exista en tu cuenta de LoadFocus

Los Umbrales No Funcionan Como se Espera

• Asegúrate de que la sintaxis del umbral sea correcta: una lista separada por comas de métrica, operador y número, por ejemplo avgresponse<=200,errors==0. Las métricas son avgresponse, errors, p95, p99, min, max y hitspersec (tiempos de respuesta en milisegundos). Los operadores son <, <=, >, >=, == (o =) y !=
• Un umbral que no se puede leer se omite con una advertencia. Si no se puede leer ninguno de los umbrales que pasas, run-test muestra un error y termina con el código de salida 1 en lugar de usar el valor predeterminado avgresponse<=100. Revisa las primeras líneas de la salida en busca de "Invalid threshold"
• Comprueba si las métricas que estás evaluando son relevantes para tu prueba
• Verifica que la prueba esté generando suficiente carga para producir resultados significativos

El Pipeline Excede el Tiempo de Espera

• Ajusta la configuración de tiempo de espera en tu configuración de CI/CD
• Usa --wait-timeout <seconds> para fijar cuánto espera el cliente a que termine la prueba (1800 por defecto). Cuando se agota, el comando falla con código de salida 1, pero la prueba sigue ejecutándose en LoadFocus
• --poll-interval <seconds> fija cada cuánto se comprueba el estado (10 por defecto)

Para más detalles de integración específicos de cada plataforma, consulta las guías dedicadas para CircleCI, Azure DevOps, GitHub Actions, Jenkins y GitLab CI/CD.