(Vídeo) Conociendo a los Build Agents

De vuelta a los contenidos y en esta ocasión (aprovechando la licencia de Camtasia) decidí probar con un video para explicar un concepto indispensable a la hora de decidir cual sera nuestra arquitectura de desarrollo y despliegue con TFS/VSTS: los Build Agents, que son, como han evolucionado, con que tipos contamos y cuales son las implicancias de elegir Agentes privados o Agentes hosteados, espero que sea de utilidad para entender este pilar de la arquitectura de TFS/VSTS

Enlaces de referencia:

Y ahora verificando la performance (II)

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í:

Clipboard26

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? Finish Reading: Y ahora verificando la performance (II)

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 😉

Completando el ciclo de ALM: Release Management (II)

Prosiguiendo con la entrega anterior, pasamos a los pasos 4 y 5 de este proceso que consiste en configurar cada uno de los entornos de despliegue en los que se va a desplegar la aplicación, la idea que implementaremos en esta ocasión sera la siguiente:

  • Cada vez que se efectué un cambio en el código fuente se disparara una Build (Integración Continua, esto ya lo tenemos bien sabido)
  • Si la Build es exitosa se disparara una Release
  • El primer paso de la Release sera desplegar automáticamente al entorno QA
  • Efectuado el despliegue a QA, un aprobador humano dará su conformidad, o no, al contenido desplegado
  • Si el despliegue en QA ha sido aprobado, recién entonces se efectuara el despliegue al entorno PRO

Obvio que este esquema puede extenderse para incorporar mas entornos, para añadir pruebas de carga en la nube, distintas categorías entre aprobadores, etc, pero para demostrar el concepto esta prueba sera suficiente.

De momento vamos a identificar correctamente nuestros entornos, así que nos vamos al entorno llamado por defecto “Default Environment” y le cambiamos el nombre…

Clipboard01

A QA:

Clipboard02

Finish Reading: Completando el ciclo de ALM: Release Management (II)

Los retos para hacer cloud en el Perú

Cloud es una interesante y validad promesa para las empresas peruanas, la promesa de reducir sus costos fijos, haciendo que buena parte de la infraestructura pase a ser costo variable pagando solo lo que se consume, es algo muy atractivo, y mas cuando un caso de éxito como el de Cineplanet llama la atención por la escalabilidad que esta logrando.

Para lograr esto hay que mirar con otros ojos a nuestras conexiones de internet, si antes se orientaba a facilitar acceso a la web y al correo, ahora… las cosas cambian, si antes el servidor de correo estaba en la red local ahora lo esta fuera, así que cada request sale fuera de la red de la organización por mencionar el detalle que podría ser mas común.

Otro escenario en que nuestra velocidad de conexión puede asomar un lado poco amable es el de la carga de datos desde nuestra organización hacia la nube, y claro como usualmente la infraestructura de la nube esta fuera de nuestro país la latencia si que es un factor a considerar, para lo cual habrá que recurrir a herramientas como Azure Speed y así determinar en que zona geográfica nos conviene mas provisionar nuestros servicios en la nube; pues como vengo insistiendo, el hecho de que haya datacenters cloud en Brasil no implica que vayamos a conseguir mejores velocidades de conexión que las que tenemos con USA.

Pero por mas de que elijamos bien la zona geográfica y aumentemos razonablemente el ancho de banda, hay otro factor que toca considerar y es que la mayoría de conexiones a Internet que se contratan son de tipo ADSL (Asymmetric Digital Subscriber Line) siendo que la A, que antes usualmente no nos importaba pues solo consumíamos contenido, nos puede jugar una mala pasada pues la Asimetría nos recuerda que la velocidad con la que nos podemos bajar contenido siempre sera mucho mayor que la velocidad de subida… upss y eso se refleja en los problemas mencionados anteriormente, de ahí que dentro del planeamiento de uso de soluciones cloud debe hacerse la evaluación de pasar de conexiones ADSL a conexiones DSL que no restrinjan la capacidad de subir contenido.

Ya en el lado que no esta mucho en nuestras manos esta el reclamar por los precios y las velocidades que se ofertan en el Perú (penosas realmente) y esperar que a se haga una NAP a nivel de la Comunidad Andina, lo cual justificaria a los proveedores de cloud el montar un datacenter en la región, o que se mejore la conexión vía fibra óptica con Brasil y así reducir la latencia con los datacenter de dicho país.

Por otro lado, corresponde hacer una mayor difusión respecto a lo que implica cloud en cuanto a generar nuevas aplicaciones (PaaS) o gestión de Infraestructura (IaaS), pues percibo que aun en los departamentos de IT se habla de cloud solo en términos de compartir información en repositorios de facil acceso o usar herramientas de ofimática basadas en Web, y como bien sabemos es mucho mas que eso, todo un reto para los informáticos en estos tiempos ¿no?

 

 

¡Mudanza!

Si has sido un visitante que ha pasado por aquí en semanas anteriores te habrás dado cuenta del cambio de estilo en el blog, lo cual ya es mas obvio, pero lo que no lo es tanto es que desde hace una semana este blog ha dejado de estar alojado en Blogger para estar alojado en Azure usando WordPress.

Las razones para ello son varias, con WordPress hay una mayor escena de temas y plugins para usar, en ese sentido Blogger se había quedado muy atrás, pero una razón muy importante es que siendo que ahora me he enfocado en Cloud Computing en general y en Azure en particular, decidí que una buena opción seria hacer uso de esas opciones y así profundizar en el uso continuo de un recurso en Azure.

La primera decisión que tome fue el tipo de servicio de Azure a usar, descartadas las maquinas virtuales (el uso continuo de procesador garantiza una factura alta) la opción obvia era elegir un Azure WebSite, y dentro de esta opción opte por un servicio de hospedaje “Compartido” (Shared).

wordpress03

La razón por la que elegí este nivel fue porque es el mas “barato” que permite asignar un dominio personalizado (en este caso consultorinternet.com) y no quedarse con el modelo sitio.azurewebsites.net que viene por defecto. Y si por alguna razón este site crece en trafico siempre podre crecer a alguno de los modelos como “Basic” o “Estandar”.

Implementar WordPress fue muy sencillo, solo tuve que elegir de la galeria que te ofrece Azure a WordPress y listo.

wordpress04

Ahora bien, en la siguiente pagina si que hay que tener cuidado en agregar todos los parámetros (son varios) que se piden, y anotar sus valores en lugar seguro.

wordpress05

Nótese que en WebScaleGroup estoy usando un plan de hosting que ya tenia previamente,  y que ya había migrado del modelo “Gratis” al “Compartido” para de esta manera poder hacer uso del tema de los dominios personalizados que ya mencione mas arriba. Con respecto a la BD si es tu primer site en WordPress tienes que crear una BD nueva, si ya tienes otro site deberás usar una BD ya existente a menos que por tu volumen requieras contratar BD extra en ClearDB.

Ya con el WordPress corriendo seguí las indicaciones de este enlace para efectuar la migración de Blogger a WordPress, todo bien pero creo que no es necesario efectuar los pasos recomendados en la sección “Redireccionar los enlaces de blogger a wordpress” (que incluye el uso de un plugin) siendo que mas practico es configurar el formato de los enlaces permanentes de esta manera:
wordpress02
Esta configuración (ojo a la palabra html que hay que agregar manualmente) es la que ya tenia en Blogger, por lo que si los buscadores tenían referenciado un enlace “antiguo” esta referencia no se perderá, lo que si se ha perdido son los enlaces que hacen referencias a entradas agrupadas por mes, bueno… no se puede tener todo.

Con todo esto listo, toca configurar los parámetros en el proveedor de dominios (en mi caso Network Solutions) de acuerdo a lo indicado en esta documentación, nótese que el tiempo en que se propagan los cambios en los valores puede variar, en unos casos en 5 minutos ya Azure “sabia” de los cambios, en otros se tardo como media hora, pero nunca ha tardado las horas que se supone que tienen de colchón para propagar los cambios.

Ya configurado el site, me percate que si bien al entrar a www.consultorinternet.com accedía al nuevo site en WordPress y ya no al de Blogger, cuando administraba el site o iba a los enlaces veía el dominio en azurewebsites.net que no era lo que esperaba, luego de revisar tanto en la consola de Azure como en Network Solutions por si había algún error, revise la administración en WordPress percatándome que tenia que editar algo tan simple como lo que se ve en el siguiente gráfico, upsss.

wordpress06

Bueno, ya esta listo, espero sus visitas y comentarios en esta nueva etapa. Lo mas probable es que en breve migre Fisica 3, el site hermano.