Ok, esta vez si me he demorado en la segunda parte de esta serie sobre como agregar pruebas de performance a nuestros procesos de despliegue, en nuestro articulo anterior vimos como agregar configurar una prueba de carga sencilla, básicamente registrábamos una URL, el volumen de la prueba y listo… ya podíamos hacer una prueba preliminar que nos podría ser muy útil en algunos casos (como cuando todos los parámetros de una búsqueda están en el QueryString, por ejemplo), pero si queremos mayor granularidad en los parámetros de la prueba la alternativa es usar los Web Performance and Load Test Project que han ido evolucionando y que mediante el uso de Azure nos permiten desde Visual Studio tener unos resultados de prueba muy configurables, así:

Y eso esta genial, pues nos permite (mediante nuestra cuenta de VSTS) provisionar recursos Azure que hagan la respectiva prueba mientras sea necesario, y que podamos ver dichos resultados desde nuestro Visual Studio, pero… ¿que tal si queremos que esta validación de carga decida si un despliegue ha ido bien o no? Pues eso es lo que trataremos de conseguir en este post.

En concreto lo que haremos sera agregar un proyecto de carga a nuestra solución, incluirla en el repositorio y de esta manera valernos de sus archivos para incluir un nuevo tipo de tarea durante nuestro proceso de despliegue, asumiremos que estamos trabajando con una solución Web que ya tiene configurado su repositorio asi como sus procesos de Build y Despliegue como hemos visto en anteriores artículos, ¿ok?

Asi que lo primero que haremos sera agregar un nuevo proyecto a nuestra solución

El cual, como ya hemos mencionado es de tipo Web Performance and Load Test:

Antes de proseguir debo aclarar que no es la intención del articulo explicar todas las opciones de un proyecto de este tipo, sino ver como podemos volver a este tipo de proyectos una parte de nuestro ciclo de despliegue, para lo cual se introducirán algunos conceptos básicos al respecto, queda al lector explorar con detalles sus opciones y por ejemplo ejecutar pruebas sobre un ciclo de acciones grabadas, dicho esto prosigamos.

Nuestro proyecto incluye de arranque un archivo .webtest (al cual en este caso he renombrado como WebTestDemoParts), que básicamente define la acción o acciones que queremos validar, en este caso  lo que validaremos sera una URL accedida mediante una acción GET, para lo cual hacemos clic derecho y  seleccionamos Add Request.

Por defecto nuestro Request apuntara a localhost, pero sera sencillo cambiarlo a la URL que queramos probar:

Ahora agregaremos una regla de validación haciendo clic derecho sobre nuestro Request, seleccionando Add Validation Rule… lo cual nos abrirá este cuadro de dialogo que llenaremos como se ve en el gráfico, con esta regla (nótese la variedad existente) estamos validando que efectivamente estamos llegando a donde indicamos con el Request y que no ha habido redirecciones (como consecuencia de un error 400 o 500, por ejemplo):

Muy bien, ya hemos definido QUE queremos probar, ahora toca configurar el COMO lo queremos probar para lo cual dentro de nuestro proyecto agregamos un Load Test..

Esto nos abrirá un wizard, que como podemos ver nos ofrece la opción de definir una carga desde la nube o mediante nuestra infraestructura, en este caso como es logico elegiremos nube, para lo cual usaremos nuestra cuenta de VSTS:

Luego elegimos la zona geográfica, elijo cualquiera de USA, pero diferente a donde esta nuestra aplicación, solo para agregar una razonable latencia.

Ahora definimos un escenario de carga, lo haremos de manera sencilla, elegimos distribución normal de los think times para tener una representación mas realista de la prueba:

La siguiente pantalla es muy interesante, nos indica si queremos una carga constante o si por el contrario optaremos por una carga progresiva, como en este caso:

Aquí elegimos un modelo para la prueba, elegimos el primero que es el que se recomienda para entornos de producción:

Y aquí es donde esta el enlace de los conceptos, es en esta pantalla donde elegimos el WebTest que vamos a probar (el que), esta pantalla requiere especial atención, así que aunque parezca redundante debemos tener cuidado de que en el combo de proyectos elijamos justamente el proyecto sobre el que estamos trabajando (es que en el combo también se listan por ejemplo los proyectos de pruebas unitarias), una vez elegido el proyecto veremos los posibles tests que podemos elegir.

Como en este caso solo tenemos uno, pues lo seleccionamos convenientemente:

La siguiente pantalla la dejamos como esta, pues solo hemos agregado UN test, nótese que dentro de nuestro plan de carga podríamos haber elegido mas de un test, de haberlos tenido definido, claro esta.

En la siguiente pantalla podemos jugar un poco simulando que sean distintos browsers los que “ataquen” a nuestra aplicación Web:

Y listo, con esto tenemos una configuración preliminar de nuestra prueba, por un lado tenemos un webtest, y por otro una configuración de la prueba de carga, nótese que esta ultima es muy configurable, y que sus detalles van mas allá de los objetivos de este articulo, pero si me quiero detener en algo que validé durante mis pruebas, nótese que en la zona de Scenarios contamos con una sección llamada Network Mix, la cual permite simular que el acceso a la URL que vamos a probar sea mediante DSL, red inalambrica, T1, etc el problema es que al día de hoy esas opciones no están operativas desde los tests de Azure, por lo cual nos cuidaremos de dejarlo con su valor por defecto de 100% LAN

Con esto prácticamente hemos concluido lo que corresponde a Visual Studio, solo nos resta hacer commit y dejarlo en el repositorio de VSTS, el cual deberá estar configurado para efectuar una Build y un despliegue como hemos visto antes, asi que corresponde ahora y configurando lo que haga falta para agregar el test de performance a nuestro ciclo de despliegue.

Lo primero que vamos a hacer es asegurarnos de que se copien los artefactos del Test en adición al paquete de la aplicación, para lo cual dentro de VSTS iremos a nuestra Build Definition y editaremos el paso de Publish Artifacts como se ve en el gráfico, siendo que en la sección Contents deberá listar lo siguiente:
**\*.zip
**\*.loadtest
**\*.webtest
**\*.testsettings,
de esta manera cuando los pasos del Release “lean” los contenidos no solo tendrán el .zip de la aplicación, sino también el loadtest respectivo. Un detalle adicional: en Visual Studio uno debe asegurarse que estos artefactos se copien siempre en la compilación.

Ahora nos vamos a la pestaña de Release y editamos nuestra Release Definition en el paso de QA, si tenemos un Quick Test (como el que agregamos anteriormente) lo borraremos o deshabilitaremos para seguidamente agregar un Cloud-based Load Test

Aqui pueden ver que ya he llenado los diversos parametros, asi que veremos como se hace, el primer parámetro (Registered connection) es simplemente nuestra conexión “alterna” a VSTS que revistamos en nuestro articulo anterior, reitero, puede parecer redundante pero podría darse el caso de que la organización tenga mas de una suscripción VSTS y este jugando entre ellas.

 

Ahora pasemos a la parte delicada, para llenar el parámetro Test settings file, haremos clic en los … y se nos abrirá el dialogo que vemos a continuación, el cual nos permitirá pasear por los artefactos que generan nuestras Builds, que como sabemos ahora no solo incluyen el .zip, asi que navegaremos hasta encontrar el archivo Local.testsettings, del cual aun no hemos hablado, baste saber que es un archivo que se agrega a nuestra solución cuando agregamos un proyecto de prueba de carga (como hemos hecho) y define condiciones generales para nuestros tests de carga, así que es importante para que funcione bien este paso, nótese que el mencionado archivo se ubica (de manera análoga al código fuente) en la raíz de la solución de los artefactos.

Ahora nos corresponde llenar el parámetro Load Test Files folder, asi que nuevamente exploramos bien los folders de artefactos y seleccionamos la carpeta respectiva, nótese que como ha habido una “compilación” los archivos .loadtest y .webtest fueron copiados dentro de una carpeta bin, pero NO debemos elegir esa sino el nivel de carpeta de proyecto, que en este caso es DemoPartsLoadTest.

 

Ahora solo resta especificar el archivo .loadtest, el cual deberemos editar “a mano”, lo cual no deberá ser de gran problema puesto que conocemos su nombre, este archivo sera el que luego le “dirá” a VSTS cual es el .webtest que tiene que probar.

Grabamos el paso, y ejecutamos un proceso de despliegue, ya sea actualizando el código fuente o desde la pestaña de Releases, una vez concluido el proceso (si todo ha salido bien) podemos ir al log del release y verificar que los pasos se han cumplido (y por ende estamos listos para poder aprobar el pase al entorno PRO):

Ok, todo ha ido bien, pero ¿como vemos los detalles de esta prueba?, para esto debemos ir a la pestaña de Tests en nuestro proyecto de VSTS, así:

Como podemos ver por defecto estamos viendo los planes de prueba de tipo QA, así que nos corresponde ir a la subpestaña de Load test donde como sabemos podremos ver la lista reciente de tests de carga que he realizado anteriormente

Elijo el Test respectivo (nótese que mi lista personal incluye experimentos adicionales) y listo (al igual que en la prueba rapida) podemos ver los detalles de nuestra prueba:

Listo, ya hemos agregado un paso mas a nuestro ciclo de despliegue, si la prueba de carga falla simplemente no podremos ni siquiera aprobar para que pase a producción.

Un detalle adicional, llegados a este tipo de prueba debemos de ser conscientes que cada vez que lanzamos una prueba de carga estamos consumiendo creditos de Azure, por lo que debemos estar seguros de nuestra cadencia de despliegues al entorno en que hagamos las pruebas de carga, si hacemos un despliegue con cada commit de nuestro equipo y sobre cada despliegue le aplicamos una prueba de carga, nos quedaremos sin créditos rápidamente, por lo que puede ser conveniente definir un entorno de despliegue frecuente pero sin pruebas de carga, y otro de despliegue periódico sobre el cual si efectuaremos la prueba de carga.

A ver que otro paso mas podemos agregar a nuestro proceso de despliegue, pues todo evoluciona.

Un agradecimiento especial a Donovan Brown, que en el pasado DevDays me ayudo a poner a punto este proceso de prueba, sin él esto que estoy explicando no seria posible.