Aun es tiempo de DevOps… pero…

Hace unos meses comentaba sobre el interés creciente de las organizaciones sobre el concepto de DevOps y como estas debían enfocarse en la sinergia y colaboración a fin de mejorar la eficiencia de sus procesos de despliegue, lo cual implica todo un reto.

El problema es que en este tiempo he podido percibir que la percepción respecto a DevOps se ha quedado en la parte técnica del asunto, reduciendo DevOps a aplicar correctamente los scripts de despliegue, usar Docker y/o Infraestructura como Código, monitoreo, control de código fuente ahhh y si todo lo hacemos en la nube, mejor aun.

Y claro, así como en su momento surgio el boom de las certificaciones de los frameworks de proyectos, de liderazgo, de escalamiento, de cambio, era cuestión de tiempo que se implantaran por aquí los cursos y/o certificaciones de DevOps, con el sabor que se desee, contexto en el cual es difícil separar la paja del trigo.

En todo caso creo que debemos distinguir lo que propugna el enfoque DevOps: colaboración y sinergia en búsqueda de mejora de resultados, de una potencial implementación especifica en la cual ya pasamos directamente a las herramientas que se pueden utilizar, siendo que no hay recetas únicas sino el elegir adecuadamente el stack correcto según las necesidades y realidad de las aplicaciones y/o organización, por ejemplo… si uno “aprende DevOps” basandose en containers  ¿esos conceptos nos servirán para coordinar las mejoras para desplegar servicios Windows? (o viceversa).

Otro tanto viene con los procesos de reclutamiento de personal, la confusión es tal que como mencionaba Nico Paez se ve a “DevOps” como un perfil,  no como “mindset” (personalmente yo prefiero llamarlo “enfoque”) y como indique en mi sesión “En búsqueda del DevOps perdido” los reclutadores ven la palabra “DevOps” y te contactan preguntando por tecnologías que no están tu perfil; y por el otro lado pasa lo mismo, cuando me ha tocado entrevistar a postulantes por roles relacionados, al preguntar sobre el entendimiento respecto al enfoque DevOps no ha sido raro que lo primero que les vino a la mente fue … automatización!

Al final casi siempre termino regresando a la “definición” que en su momento hizo Carlos Peix respecto a como definir un “rol” para DevOps: “Para mí el nombre del rol debería ser “Facilitador de mentalidad DevOps”. Eso es lo que yo he hecho y hago en varios casos.

Sin duda, para cumplir ese rol, me viene muy bien saber de bash, de firewalls, de DMZs, de TCP/IP, de herramientas de automatización, lenguajes de programación, etc. También me viene bien haber sufrido mucho con el trabajo manual repetitivo, cometido errores y haber creado soluciones artesanalmente. Por último, también me ha sido útil desarrollar habilidades de facilitación de debate, procesos de diálogo y de discusión, de divergencia y de convergencia.” Y claro, el detalle es que en una certificación no te viene la experiencia de haber desplegado manualmente, el sufrir con organizaciones en las que el divorcio entre áreas sea tal que las ventanas para desplegar sean estrechas y escasas (¡alguien dijo silos?), ni el saber como son las cosas que uno quiere evitar para lograr la mejora.

En ese sentido, si uno va a estudiar herramientas para DevOps, pues genial, pero teniendo en cuenta que al final ese stack puede ser el valido en un contexto, pero que en otro corresponderá aplicar los criterios de colaboración y comunicación con tu equipo para entender el contexto y así poder definir correctamente el flujo y el stack necesario, pues son justamente esas capacidades de comunicación y de preguntar correctamente las que te permitirán adaptarte pronto a escenarios con herramientas que no hayas visto antes; y es que también de eso se trata el enfoque DevOps: no ser el super sabelotodo que domina tanto los stacks de desarrollo como de infraestructura sino de, con mucha humildad, poder plantear esquemas de colaboración y multicapacidad de los equipos.

Los retos de la agilidad en el Perú para el 2018

Pues si, se acaba el año y aunque no soy muy fan de estas revisiones y mirada hacia adelante que rodean estas fiestas, creo que en esta ocasión corresponde hacerlo a fin de reflexionar por donde estamos yendo como comunidad agilista, así que tratare de repasar lo que he visto en base a las interacciones en diversos entornos y encuentros… vamos a ello.

  • Interés creciente, ya ser ágil no esta siendo una curiosidad, sino una tendencia cada vez mas visible lo que ha hecho que las personas estén buscando cursos, las empresas buscando Scrum Masters y coaches..
  • Mucha conversación acerca de implementar/adoptar/etc la agilidad en grandes organizaciones, lo cual ha derivado en atención hacia los frameworks de escalamiento
  • La búsqueda externa de la piedra filosofal o como dice mi amigo Uzi “las empresas quieren un coach mágico y divertido” en lugar de promover el crecimiento interno
  • DevOps se ha vuelto la palabra de moda, debido a un legitimo interés en automatizar los despliegues, pero olvidando el factor cultural y de colaboración que involucra
  • Ganas por retomar la excelencia técnica como pilar de la agilidad
  • Mas dudas sobre los problemas en el día a día que sobre como implementar por primera vez
  • Profesionales que antes veían la agilidad como otra opción mas (equiparándola a cascada a veces) empiezan a preguntarse sobre ella
  • Grandes organizaciones están haciendo sus experimentos de innovación basándose en la agilidad y volviéndose referentes en el camino

Entonces, puede que Perú este llegando un poco tarde a la fiesta del crecimiento (si nos comparamos con nuestros amigos de Colombia, por ejemplo), por lo que toca plantearnos como comunidad como podemos contribuir hacia los cambios propuestos de la agilidad de la mejor manera, así que planteo unas ideas sueltas.

  • Tener siempre en mente que no hay recetas únicas, a algunos les puede ir mejor arrancando con Kanban a otros con Scrum o algún hibrido, pero debemos estar atentos a que lo que funciono en una organización u equipo puede no funcionar en otra, asíi que lo que toca es ir generando los contextos para que vaya surgiendo y recordar que “You can do better than the Spotify Model”.
  • Estar alertas con las implementaciones top-down impuestas que no involucren a los equipos y tomar todo con pinzas a pesar de la popularidad del framework propuesto, pues esta no es indicativo de calidad sino que puede ser resultado de búsqueda de algo que mantenga lo existente sin procurar realmente el cambio necesario.
  • Enfatizar la necesidad de una base técnica solida como pilar de la agilidad, se nos ha recordado mucho a los desarrolladores acerca del desarrollo de las habilidades blandas, pero por otro lado poco se hace para recordar a los Scrum Masters y coaches sobre la importancia del entendimiento del rol que juegan las decisiones técnicas en la buena marcha de un proceso de desarrollo de software, ya que como decía Hernan Wilkinson en el pasado Agiles 2017 “si solo hacemos Scrum y no mejoramos en la parte técnica vamos a seguir haciendo la misma porquería pero vamos a estar todos más felices“.
  • Estar alertas ante los vendedores de humo, y discernir entre quienes solo venden horas de consultoría y certificaciones, pero no se aplican el cuento a si mismos y quienes si efectivamente se involucran en lograr mejores resultados.
  • Recordar que DevOps va mas allá de automatizar y entregar de manera continua, que involucra mucho lo que es colaboración y cierto cambio cultural, a estar atentos cuando alguien empiece a hablar de DevOps vinculándolo a nube o a procesos de despliegue y no se mencione sobre la necesidad de colaboración dentro y entre los equipos. Personalmente siempre he creído que los profesionales de la tecnología vivimos permanentemente en un contexto de “Todos somos genios. Pero si juzgas a un pez por su habilidad de trepar árboles, vivirá toda su vida pensando que es un inútil” ya que se nos ha enfatizado en las mediciones basadas en nuestras habilidades blandas y hasta cierto punto en una extroversión que no tenemos, lo cual impide la valoración adecuada de muchos de nosotros; pero, dicho esto, creo firmemente que en el apoyo a enfoques DevOps se requiere tratar de tener el pie en ambos lados.
  • Ser más proactivos para entender y apoyar los contextos complicados, muchas de las reflexiones y propuestas que se vienen dando últimamente parten del marco supuesto en que toda la organización esta involucrada en una transformación técnica y cultural, pero poco se habla por ejemplo de como lograr hacer la transición hacia la agilidad (y mejorar el desempeño) en equipos que mantienen (y lo seguirán haciendo por un tiempo) aplicaciones legadas pues la respuesta no puede ser simplemente que se limpiara esa tecnología (ahí nos olvidamos del factor humano) sino procurar la forma de que estos equipos sumen al resultado final, o como trabajar lo más ágil posible con equipos en los cuales la permanencia de sus miembros está supeditada a contratos de tres o seis meses (renovables o no), o como ayudar a esa pequeña consultora que depende de entregar un presupuesto cerrado para un potencial contrato del cual depende su continuidad, ya que es muy fácil y cómodo desde una posición consolidada que se debe optar por otro tipo de clientes.
  • Evitar caer en el cargo-cult, si en un pasado se vio el dejar la línea técnica para irse a gestión (y llegar a ser Project Manager o similar) como una mejora de carrera profesional, ahora corremos el riesgo de caer en una variante de lo mismo al dar mucho énfasis en cómo ser o efectuar el rol de coaches y su importancia (o considerar que un Agile Coach es un Scrum Master junior), olvidándonos que lo realmente importa es el cambio y evolución de todos los integrantes de un equipo u organización.
  • Estar seguros de si lo que se está efectuando es efectivamente innovación o no.
  • Empezar a pasar de un enfoque basado en proyectos (y por ende en costos fijos) a uno basado en equipos que van construyendo productos que generan valor a la organización, esto tomara mas tiempo, pero es algo que debemos tener siempre presente.

Retos y alertas que hay que tener en mente para seguir en el camino emprendido… a estar en ello en este 2018 que esta por empezar.

 

 

Pongamos una Wiki en nuestros Team Projects

Bueno, esto podría sonar no tan novedoso si tenemos en cuenta que desde hace buen tiempo las plataformas de tipo Wiki se han popularizado como una forma practica de compartir información entre organizaciones y/o proyectos, pero curiosamente esto era una asignatura pendiente en VSTS, lo cual no deja de ser curioso puesto que hace rato TFS (la versión On Premise) cuenta con dicha herramienta “out of the box” (bueno, si instalas los módulos vinculados a Sharepoint), pero en todo caso esta es una buena noticia, desde hoy podemos agregar una Wiki a nuestros Team Projects.

Y empezar a trabajar con la Wiki, es sencillo, solo tenemos que loguearnos como administradores de nuestra instancia de VSTS y veremos la opción disponible en la barra de herramientas, hacemos clic ahí y solo habrá que seguir las instrucciones:

Y bueno, luego a editar, para lo cual habrá que seguir las guías de marcado correspondientes:

Es todo para empezar, ya se vienen nuevas características como buscador transversal dentro de los diversos proyectos, filtrado, mejoras en el marcado, etc.

Seguiremos informando 😉

Relanzamiento de www.agile-peru.net

Para nadie es un secreto que desde que regrese a Perú he estado involucrado en Agile Perú, primero como asistente y luego como parte de su organización, en este lapso hemos tenido nuestras altas y sus bajas, sacando adelante los Agile Open Lima que tanto impulso Lennon, y sobre todo, nuestro recordado y fatigado Ágiles 2013, y en los ultimos años nuestras clasicas reuniones mensuales.

Pero a todo esto, había algo que habiamos pasado por alto, y era nuestra pagina web, que si, que nuestra lista de correo y nuestro Facebook están muy activos, pero si que hace falta un medio propio para poder ir registrando nuestras actividades, facilitar contenido a la comunidad, etc… es asi que desde el 12 de mayo nuestra web esta online nuevamente, en nuevo host WordPress, donde de momento iremos publicando nuestras actividades (como nuestro reciente Agile Open Lima VIII) asi como la discusión de los planes futuros de nuestra comunidad.

Como buenos agilistas hemos empezado con una versión básica que de momento nos permite ir posteando, pero que esperamos vaya creciendo para incorporar secciones y diseño funcional para nuestro publico, en eso estamos, paso a paso….

Las perspectivas PaaS Linux sobre Azure

Si hace unos años me hubieran dicho que estaría comentando sobre lo que menciona el titulo, me hubiera puesto a reír, pero el contexto tecnológico cambia de manera constante y este es el escenario en que los desarrolladores debemos tener claras nuestras opciones a la hora de considerar Linux como plataforma.

De mas esta comentar sobre las oportunidades que nos ofrece .Net Core para poder llegar a escenarios en los que tradicionalmente Windows estaba vedado, pero también debemos tener en cuenta las perspectivas de poder integrarnos y trabajar con otros stacks, así que si… Linux nos va a rodear bastante a los que trabajamos con .Net.

Ahora bien,  trabajar con Máquinas Virtuales Linux siempre ha sido posible desde que los proveedores de cloud empezaron a ofrecer IaaS, pero si uno basa su estrategia cloud en depender de máquinas virtuales que básicamente replican la arquitectura que se tenía on premise, no se está sacando partido de las potencialidades de la nube (optimización de costos y escalamiento) ni  tampoco se esta asumiendo un enfoque pragmático frente a los retos (o limitaciones) inherentes a la nube, como pueden ser los niveles de servicio asegurados por el proveedor (SAL), lidiar con las latencias, etc, esto y la necesidad de brindar a nuestros equipos de desarrollo con plataformas que aceleren su productividad nos deben obligar a mirar la nube más allá del IaaS.

Es con esta mirada que debemos analizar la propuesta PaaS que nos da Azure en el entorno Linux; recordemos que tradicionalmente si queríamos implementar una Web App lo que estábamos provisionando “por detrás” era una MV Windows con un IIS especialmente configurado para permitir las ventajas como slots, escalamiento, kudu, etc… lo cual nos va bien para aplicaciones .Net pero por ejemplo no nos permite correr aplicaciones Ruby, aparte de que existen escenarios en que se requiere cierta librería PHP que ¡oh sorpresa! tiene una fuerte dependencia con el sistema operativo Linux, así que era natural que Microsoft Azure venga a ofrecer una solución de Web Apps basada en Linux como una opción para los desarrolladores, misma que en este momento esta en versión de prueba.
top-level-create
Finish Reading: Las perspectivas PaaS Linux sobre Azure

Reflexiones a proposito del #CentenarioPUCP (2): La Ingeniería Informática en perspectiva

Habiendo ya comentado respecto a lo que significa mi alma mater en el contexto actual, toca reflexionar sobre la situación actual de nuestra especialidad, la Ingeniería Informática, su perfil, su evolución y sobre todo sus retos a futuro.

17499173_1885665281678573_8201655322192449166_n Finish Reading: Reflexiones a proposito del #CentenarioPUCP (2): La Ingeniería Informática en perspectiva

Empezando bien el año: MVP

Pues si, este año empieza bien pues hoy recibí el correo que me informa que se me ha otorgado el reconocimiento Microsoft Most Valuable Professional (MVP) en la categoría Visual Studio and Development Technologies, esta designación me motiva mas para seguir este proceso de compartir conocimiento en lo que son las practicas ALM y DevOps, así que nos espera un año con un reto bastante exigente. Muchas gracias a todos los que me apoyaron en este proceso, tanto de Microsoft Perú como de las diversas Comunidades Microsoft.

mvp

DevOps: ¿el proceso o la sinergia como objetivo?

Hace un tiempo que vengo metido en el tema de la filosofía DevOps, y es inevitable toparme con concepciones erróneas al respecto:

  • Perfil DevOps = IT Pro con nuevos skills
  • Objetivo DevOps = Automatización y Despliegue continuo
  • DevOps = Agilismo para IT Pros

Esto me quedo en evidencia cuando en una charla, a la que asistí hace pocas semanas, el orador compartió su experiencia en una gran implementación DevOps, donde si bien incluyo en la charla el tema de los conflictos usuales entre Dev y Ops(*), a la hora de aterrizar el tema no hizo el énfasis de que DevOps es búsqueda de sinergias, o sea… personas sobre procesos, eso si, explico un buen pipeline de Entrega Continua y lo que habían conseguido, pero me quede con el regusto de que fue algo como top down (una decisión enteramente planificada desde gerencia) y no partir de mejorar las formas de trabajar.

Este hecho me hizo recordar los tiempos en cuando preparaba mi sesión “El reto del DevOps ágil“, donde a pesar del titulo dejaba abierta la pregunta sobre si DevOps era algo que iba mas allá del agilismo, y no lo pude ver claramente, lo reconozco, pero si partimos del hecho de que DevOps debe entenderse como una conversación de tres etapas en la que las personas se ponen de acuerdo sobre los procesos para finalmente decidir sobre las herramientas a usar, queda claro que el Manifiesto ágil en su principio de “Individuos e interacciones sobre procesos y herramientas” cobra mas fuerza que nunca.

Entonces no es que no haya una definición en si de DevOps, sino que probablemente no te sientas cómodo con el paquete completo o no entendiste The Phoenix Project, así que antes de aceptar algunas definiciones pase un buen tiempo, quedándome con estas:

  • “DevOps es la búsqueda de la sinergia derivada de Desarrolladores trabajando con IT Pros y demás personal de Operaciones”
    Andrew Binstock (Dr. Dobb’s)
  • “Unión de personas, procesos, y productos que facilitan la entrega continua de valor a nuestros usuarios finales”
    Donovan Brown (Microsoft)

devopshumano
Así pues regresamos a la casilla de arranque, debiéndonos quedar claro el punto de partida de toda transformación DevOps debe partir por las personas, el buscar una sinergia tal vez inexistente de momento, pero imprescindible para el logro de los objetivos de la organización, con este punto de partida los procesos para entregar valor llegaran a su debido momento… pero claro, a veces estamos acostumbrados a empezar la casa por el tejado.

Update (14/11/2016)

Justo hoy recibí una publicidad para un curso de Implementación DevOps, el temario es el siguiente:

  1. Control de Código Orientado a DevOps
  2. Integración Continua en la Nube
  3. Infraestructura como Código
  4. Soluciones de Entrega Continua
  5. Monitoreo y Supervisión
  6. Contenerización de Aplicaciones
  7. Pruebas de IU Automatizadas

Como se puede ver, enfoque técnico casi al 100%, pero de integración de equipos, búsqueda de objetivos y generación de sinergias.. mas bien poco… o por lo menos una introducción a la problemática que deriva en la necesidad de DevOps… pero no.

(*) Gracias a la traducción de unas laminas que hice de Microsoft Virtual Academy.

¿Por qué debemos generar contenido técnico en español?

Desde hace un tiempo he visto algunas opiniones de informáticos peruanos motivadas en generar contenidos técnicos en… ingles, las razones son varias: hay un publico objetivo mayor, potencialidad de clientes, uno debe esforzarse en aprender la lingua franca, etc… el caso extremo fue el de un programador peruano que en un foro peruano contestaba las preguntas hechas en español… en ingles, según él para motivar a los demás a comunicarse en ingles… en fin (*).

whyLas razones esgrimidas son validas, pero considero que no cubren todos los aspectos a considerar si queremos efectivamente lograr evangelizar y mejorar el ecosistema de nuestros países, esto lo digo porque muchas veces al irnos en una narración en ingles, nuestro contenido puede ser correcto, pero… frio, carente de los matices que pueden hacer atractivo (aparte de necesario) un texto técnico, miren este ejemplo peninsular que me encanta, ¿se dan cuenta? un texto muy muy técnico pero con comentarios coloquiales, dosis de suspenso, y lo mejor no acaba en el post, los comentarios van en esa onda, y es a esa clase de nivel al que debemos aspirar en Latinoamérica, diálogos profundos sin sacrificar la riqueza de nuestro lenguaje, logrando esa proximidad que pueda permitir que alguien se interese en nuestra experiencia al lidiar con la tecnología.

Y si, el ingles es muy necesario (y si vas a publicar un “paper” no te queda otra) y a ciertos contenidos solo podemos acceder en ingles, pero mientras vamos en el camino de aprenderlo, no podemos dejar atrás a quienes tienen potencial informático a la espera de que puedan leer mejor un texto ingles, así que si estamos en la voluntad de compartir lo aprendido o experimentado debemos considerar cual es la manera en la que logramos mayor impacto en nuestro entorno, si como influenciadores logramos motivar a introducirse en las nuevas tendencias de manera profunda, directa, y sobre todo, estableciendo conexión mediante nuestro estilo, habremos ayudado bastante a mejorar la escena local.

(*) Ya el caso extremo es cuando para “reírse” en un texto usen “ha ha ha” en lugar de “ja ja ja” o similares…

Y ahora verificando la performance (I)

Varias cosas han pasado desde que empezamos a probar en nuevo modelo de Builds en VSTS, primero creamos una build sencilla que desplegaba a una Azure Web App, luego probamos como usar los Resource Groups para desplegar entornos, luego retiramos el paso de despliegue de la Build para trasladarlo a Release Management luego de su integración con VSTS, y hace poco agregamos Sonar como parte del proceso de análisis de nuestro código dentro de la compilación.

Y como el ciclo de evolución del proceso DevOps nunca para, en esta ocasión veremos como hacer algo a lo que le he tenido bastante respeto desde la época de las builds con el modelo XAML, en este caso la evaluación de la performance y estabilidad de nuestras aplicaciones web desplegadas.

En corto, la posibilidad de probar nuestras aplicaciones Web precede aun a .Net, recuerdo cuando probé Web Application Stress Tool (Homer) para hacer unas pruebas sencillas sobre ASP Clásico, de ahí le perdí el rastro pero la cosa se puso interesante desde Visual Studio 2013 se permite que los tests de carga se basen en las capacidades de la nube, lo cual significa que durante nuestras pruebas se provisionaran las maquinas virtuales que hagan falta para cubrir la cantidad usuarios y peticiones deseadas, esto ya lo había probado desde Visual Studio (revisar aquí y aquí), con buen resultado, pero… ¿como hacer que estas pruebas se ejecuten cuando se produzca cierto tipo de despliegue?

Antes de proseguir hay algunas consideraciones a tener en cuenta:

Los recursos que Azure provisiona para efectuar estas pruebas tienen un costo (si se va por encima de los minutos de carga incluidos con nuestra suscripción de VSTS) por lo que hay que tener cuidado de no lanzar estas pruebas por cada commit que los desarrolladores efectúen, así que la sugerencia general seria tener un sitio de DEV donde se despliegue continuamente pero sin efectuar las pruebas de cargar, luego definiríamos un sitio QA (por ejemplo) al cual se desplegara ya sea de manera manual o de manera programada el contenido existente en DEV (con Release Management lo que se despliega son paquetes que no necesariamente son recién compilados) y al efectuar ese despliegue se lanzaran las pruebas de carga, las cuales si son exitosas indicar que en el proceso de despliegue esta listo para ser sometido a aprobación (si lo hemos definido así) para decidir su pase a otro entorno.

Con estas consideraciones en mente procederemos con nuestra primera prueba para lo cual no sera necesario usar Visual Studio simplemente agregar un paso adicional a nuestro proceso de despliegue, esto es porque a veces lo que nos interesa es simplemente ver que tan bien resiste una URL en concreto a cierta petición.

Para esto vamos a la pestaña de Release de nuestra instalación de VSTS, elegimos nuestro plan actual, seleccionamos el “entorno lógico” sobre el cual agregaremos nuestra prueba de carga y agregamos el Step de Cloud-based Web Performance Test, así:

Clipboard01

Clipboard02

Ok, ahora toca parametrizar el paso para lo cual dejaremos los parámetros mas o menos así, en breve explicare el significado de cada parámetro:

Clipboard06

Antes de proseguir prestemos atención al parámetro Registered connection, lo que ocurre es que cada prueba de carga se hace con cargo a los recursos y facturación de una cuenta de VSTS y podría darse el caso de que la organización tenga mas de una instancia de VSTS, así que corresponde indicar explícitamente dicha cuenta, así que hagamos clic sobre el enlace que dice Manage, que nos abrirá una nueva pestaña en el navegador para agregar un Endpoint (como ya hicimos anteriormente para enlazar Sonar y la cuenta de Azure), y en este caso elegiremos Generic, así:

Clipboard04Y llenamos los parametros de configuración de nuestra instancia de VSTS, pero ojo, al hacerlo deberemos utilizar los datos de nuestra conexión alterna a VSTS, algo de lo que hablamos hace tiempo cuando empezamos a trastear con Git.

Clipboard05

Listo, ya hemos enlazado nuestra prueba de carga a nuestra cuenta de VSTS,  personalmente yo agregaria un checkbox que permita usar la instancia actual y no hacer nada mas, pero siempre es bueno tener una conexión alterna a VSTS especialmente de cara a la integración con herramientas de terceros en Git.

Ok, antes de grabar repasemos los parámetros que estamos configurando:

  • Registered connection: como lo vimos, la instancia de VSTS sobre la cual se hara la facturación de esta prueba de carga.
  • Website Url: La dirección que vamos a probar, en este caso estoy probando la raiz del site (o mejor dicho del slot) en que acabo de hacer el despliegue, cabe indicar que tranquilamente podria haber colocado cualquier URL interna de nuestro site, o peor aun, una URL totalmente externa no manejada por nosotros, pero eso no queremos ¿verdad?
  • Test Name: El nombre con el que identificaremos a esta prueba.
  • User Load: La cantidad de usuarios supuestos que se estarán conectando a nuestra URL.
  • Run Duration (sec): El tiempo de duración de la prueba.
  • Load Location: La zona geográfica de Azure desde donde se hará la prueba, es muy interesante y conveniente hacer la prueba desde una zona que no sea la que aloja a nuestro site, en mi caso la URL esta alojada en East-2, así que la prueba la estoy lanzando desde West.

Marcamos Enabled y grabamos, ya estamos listos para empezar, asi que lo mas sencillo sera hacer un cambio en nuestro codigo fuente, lanzar una nueva Build manualmente, o si queremos divertirnos relanzar un paquete antiguo al ciclo de Release, en todo caso esperamos un poco y veamos cuando nuestra Release se empieza a ejecutar y llega al paso que hemos agregado:

Clipboard08

Para después terminar:

Clipboard09Normalmente pasaríamos a aprobar o rechazar esta Release, pero ahora me interesa conocer los resultados de nuestra prueba, así que vamos a la pestaña Tests, y elegimos la opción LoadTest, para luego seleccionar la prueba mas reciente (en mi caso tengo algunas pruebas anteriores, pero si es la primera vez deberías tener una sola prueba en tu lista).

Clipboard10

Y así entramos a un detalle de los resultados de la prueba:

Clipboard11

Notemos algo interesante, aparentemente nuestra prueba salio ok (o sea, no hubo errores 500 o timeouts) pero el panel nos indica 2 errores, así que veamos el detalle:

Clipboard12

En mi caso el mensaje de error dice “The value 85.10138 exceeds the warning threshold value of 75“, lo cual nos viene a indicar no un error en el sitio que estamos probando sino un exceso en la capacidad de la instancia provisionada para hacer la prueba, esto apunta a que forzamos la maquina dandole 250 usuarios concurrentes, lo cual se relaciona a las pocas opciones de configuración que ofrece este tipo de prueba.

Listo, sencillo y ya podemos empezar a sacar conclusiones, pero como verán esta prueba es muy sencilla y en adición al ya mencionado problema del threshold no permite saber si por ejemplo el comportamiento es diferente desde un browser u otro, desde un tipo de red, etc, para lograr este tipo de análisis lo que se nos ofrece es la posibilidad de crear un test muy detallado desde dentro de Visual Studio y que cuando se efectúe el despliegue Visual Studio Team Services pueda “leer” todos estos parámetros archivados y ejecutar tras bastidores las pruebas programadas, esto sera tema de nuestro próximo post, de momento sugiero familiarizarse con este tipo de prueba, pues los conceptos siguen siendo validos cuando los escalemos, aparte de que estas pruebas tienen su lugar si  hacemos peticiones Get que luego repercuten a nuestra BD, o queremos probar la mejora si usamos un servicio de cache, etc.

Espero sus comentarios 😉