Cómo incluir Performance Testing en un ciclo de integración continua...
¿Has pensado en hacer esto alguna vez? ¿Es posible? ¿Para qué sirve? ¿O no es necesario? ¡Ven, te cuento!
Primero, ¿qué dice la teoría?
La teoría dice un montón de cosas, pero te lo voy a resumir. Incluir un script de performance dentro de un pipeline de CI/CD te ayuda a 4 cosas principalmente:
1️⃣ Medir el rendimiento básico de una funcionalidad. Es decir, que cumpla con los criterios de aceptación.
Ejemplo: Quiero que el login soporte 150 transacciones por segundo o que se demore 2 segundos con 30 usuarios concurrentes.
2️⃣ Mantener las métricas después de un nuevo deploy. Las funcionalidades nuevas desarrolladas no deberían afectar las métricas de las funcionalidades ya existentes.
3️⃣ Las funcionalidades nuevas también tendrán su medición de performance con sus respectivos thresholds y deben convivir sin impactar a las ya existentes.
4️⃣ Hacer esto de forma periódica te ayuda a ver en el tiempo cómo evoluciona el performance de esas funcionalidades. Esto es lo que se conoce como monitoreo continuo.
Estas 4 cosas te ayudan a identificar problemas de performance o cuellos de botella desde el mismo momento en que se desarrolla la nueva funcionalidad. Así, no tienes que esperar a que el producto esté completo o totalmente integrado para medirlo, lo cual podría ser muy tarde si encuentras algo.
Ahora viene otro detalle importante... ¿Es necesario?
Posiblemente un sprint dure de 2 a 3 semanas y un deployment nuevo esté en un rango de fechas similar. Pero el cliente quiere que le muestres el comportamiento de su API 2 veces al día o al menos 1 vez al día. Esto quiere decir que incluir tus ejecuciones en el pipeline de integración continua no se ve tan necesario. ️
Puedes hacer 2 cosas...
1️⃣ Usar la misma herramienta del pipeline, como Jenkins o similares, pero tu Job de ejecución no haría parte de los Jobs del deploy. Funcionaría de forma aislada e independiente.
2️⃣ Para no complicarte con el pipeline, puedes crear un cron Job que se ejecute con una cierta frecuencia, a ciertas horas, y recolectes datos en un dashboard. De esta manera, mantienes tus ejecuciones controladas sin afectar otras herramientas.
¿Por qué pensar en esto?
He encontrado clientes que valoran ver cómo su API evoluciona en el tiempo. Hay pruebas de performance que se miden una sola vez, como para determinar capacidad, identificar cuellos de botella, hacer un benchmarking tras una migración, o medir un escalamiento. Pero pruebas con una carga moderada y cierta frecuencia se convierten en un recurso valioso para medir el impacto de performance en todo momento. ⏳
¿Te ha pasado que te toque incluir estas pruebas en ejecuciones periódicas?
¡Cuéntame tu experiencia!
SI TE GUSTÓ Y QUIERES APRENDER MÁS....
Bienvenido al Ecosistema más Poderoso de Pruebas de Rendimiento
Si quieres aprender a CREAR UN PROYECTO DE PERFORMANCE TESTING DESDE CERO, Bienvenido a la MENTORIA PERFORMANCE 360
Si quieres aprender sobre la IMPORTANCIA DE PERFORMANCE TESTING en los proyectos de desarrollo de Software desde la experiencia de los referentes más importantes en la industria, Bienvenido al PODCAST EFECTO PERFORMANCE
Si quieres aprender HERRAMIENTAS, FUNDAMENTOS y BUENAS PRÁCTICAS, Bienvenido a JOHN PERFORMANCE, mi CANAL DE YOUTUBE
Si quieres pertenecer a la COMUNIDAD DE PERFORMANCE TESTING en Español, Bienvenido al CANAL DE DISCORD
Si quieres matenerte INFORMADO, CONECTADO, en EVENTOS, NOTICIAS, TENDENCIAS, CHARLAS, etc... Bienvenido a mi PERFIL DE LINKEDIN
Si quieres CLASES GRATIS DE PERFORMANCE TESTING, BONOS DE DESCUENTOS, el ROADMAP de Performance Testing, Bienvenido a tus REGALOS GRATUITOS
Si quieres conocer el DIA A DIA DE UN PERFORMANCE TESTER, Bienvenido a mi BLOG DIARIO DE UN PERFORMANCE
Mi deber y mi pasión es fortalecer y potencializar el conocimiento de PERFORMANCE TESTING en toda la región. Podría hacerlo solo pero no tendría mucho sentido. refiero hacerlo con ustedes. Juntos llegaremos más lejos.
