Etiqueta: Azure DevOps

Hablando de Azure Load Testing (preview)

Posted on by ecardenas

Una de las cosas que no he comentado por aquí es que desde hace pocos meses he estado probando el nuevo servicio Azure Load Testing, el cual podríamos considerar como la evolución del proyecto (ya deprecado) Load Testing Pipeline with JMeter, ACI and Terraform, que también estuve probando a mediados del año pasado, ambas herramientas tienen como propósito la gestión automatizada de infraestructura para ejecutar pruebas de performance sobre nuestras aplicaciones, basándonos en un modelo estándar como es JMeter

La verdad lo que trae el nuevo servicio es alucinante: monitoreo en paralelo de los recursos de Azure involucrados, comparación de resultados entre tests previos, integración con Azure DevOps y GitHub Actions, etc, por lo que para conocer con detalle las novedades y lo que podemos hacer con Azure Load Testing hace poco tuve la oportunidad de participar en el Meetup mensual de la comunidad DevOps Perú, así que les comparto el video, mi participación esta desde el minuto 1:21.


Aprovecho para comentar las ideas fuerzas principales alrededor de este servicio:

  • A la fecha de escribir este post, el servicio aun esta en preview, pero eso no debería ser limitante para empezar a configurar nuestros planes de prueba y ejecutarlos, pues si bien no hay un SLA definido, considero (muy personalmente) que el riesgo es menor que con un servicio que si se publica de cara a nuestros usuarios.
  • Debemos recordar siempre de escribir nuestros scripts .jmx considerando que van a correr dentro de un entorno Linux, lo cual implicara una ligera adaptación si nuestras pruebas actuales están configuradas para ser ejecutadas desde PCs con Windows.
  • El limite de cada engine es de 250 hilos por segundo, por lo que si queremos golpear nuestra app a 1000 veces por segundo deberemos provisionar 4 engines simultáneos.
  • Otro detalle a considerar es que en esta preview el numero máximo de engines que se pueden provisionar en paralelo es 45.
  • Y la consideración mas critica, en este momento, es que el servicio no asigna un controlador para los engines inicializados, esto significa que si en la prueba subo un archivo .csv (para pruebas con data) de (digamos) 100 filas, y lanzo 2 engines, las filas se enviaran en su integridad a los dos engines, con lo cual tendremos 200 llamada a la aplicación a validar, si contáramos con un controlador, cada engine hubiera recibido 50 filas, pues el controlador estaría repartiendo la carga entre sus hijos. Esperemos que Microsoft mejore este detalle, pero por mientras debemos tener en cuenta la limitante que esto representa.

Bueno, espero que el video les haya sido interesante y que ya empiecen con sus pruebas! Ya saben dejen un comentario con sus opiniones que serán bien recibidas.

Desplegando Static Web Apps con Azure Pipelines

Posted on by ecardenas
Invitado especial: Bitbucket.

Hace unos meses comentábamos aquí acerca del lanzamiento de las Static Web Apps, las cuales ofrecen la facilidad de gestionar en un único servicio el backend mediante la tecnología de Azure Functions, así como el front end apoyándonos en los servicios de CDN que ofrece Azure, pero con una gestión muy sencilla, aunque seguro se habrán percatado que el despliegue se hacia con GitHub Actions y no con Azure Pipelines, por lo que, apenas este servicio se puso disponible, hubo buena demanda hacia Microsoft para conseguir el soporte hacia nuestro motor CI/CD favorito, y finalmente Microsoft lanzo el soporte y la guia para poder lograr el despliegue usando Azure Pipelines:

Tutorial: Publish Azure Static Web Apps with Azure DevOps

Y, la verdad es ocioso repetir paso a paso lo que se explica bien en la documentación, pero si que podemos profundizar algunas cosas que nos pueden ser de interes a la hora de intentar repetir este proceso, por lo que, a diferencia del tutorial, en lugar de usar un «Hola Mundo» decidí probar con una aplicación sencilla, como la que use para la demo que ven en el video que compartí hace un tiempo, así que .. no me enrollo mas:

  • El hecho de poder usar Azure Pipelines para desplegar las SWA, nos permite usar repositorios Git diferentes a GitHub, e inclusive a Azure Repos, de hecho la prueba la hice usando Bitbucket (!!), y funciono perfectamente! De igual manera, esto nos pemite valernos de la estructura de trabajo de Azure DevOps que ya conocemos bien Team Project-> Repos.
  • Lamentablemente de momento no podemos usar las características de creación de entornos temporales bajo demanda, como demostré en el vídeo, ojala lo incluyan en el mediano plazo.
  • El pipeline usado como ejemplo es muy «plano» (pero funciona) por lo que decidí acomodarlo un poco para que trabaje usando el flujo de stages y jobs propio de los YAML pipelines, el resultado lo comparto aquí, para que les sirva de base en sus trabajos, esto permite ver como logramos un flujo como el de esta imagen.
  • Hay que estar atento (como nos indica la documentación) a los parámetros  app_location, api_location, output_location, pero también a routes_location, y en este proceso puede haber cierto prueba y error (a la hora de probar alguno de los ejemplos disponibles) en mi caso me di cuenta que en el código fuente había una carpeta routes, así que tuve que pasar el parámetro respectivo, lo bueno es que el editor de Azure Pipelines nos brinda una gran ayuda para editar la task AzureStaticWebApp@0 en nuestro YAML.
  • El modo de conexión entre Azure Pipelines y las Static Web Apps es mediante un token, como se indica en la documentación, y no mediante un Service Connection (basado en RBAC/service principal), que es el mecanismo usual para poder enlazar nuestros pipelines, en este momento hay publicado un issue que pide desarrollar esta opción, asi que seria bueno darle un like para motivar a Microsoft a desarrollar esta solución.

Y bueno, como les comente, hice las pruebas usando Bitbucket en lugar de Azure Repos (que es lo que usa el ejemplo de Microsoft), ya que justamente una de las ventajas que nos ofrece Azure Pipelines es usar diversos repos Git de manera transparente, por lo que explicare como lo hice. Finish Reading: Desplegando Static Web Apps con Azure Pipelines

Azure Upward: Advanced DevOps Hands On Workshop (materiales I)

Posted on by ecardenas

El día de hoy estare participando en el Azure Upward: Advanced DevOps Hands On Workshop, organizado por Microsoft, donde hablare sobre Azure DevOps, Web App for Containers y algo sobre microservicios, y para esto he preparado una demo que basicamente consiste en contenerizar un proyecto web, desarrollado en .Net Core, publicarlo en el Azure Container Registry, y desplegarlo en dos slots de Azure Web App for Containers.

Para la demo me he basado en el código fuente de la segunda edición libro Entity Framework Core in Action de Jon P. Smith, asi que he hecho un fork para que ustedes puedan replicar la demo en sus casas, siendo así los archivos que he agregado al código original son los siguientes:

.dockerignore
azure-pipelines.yml
BookApp/Dockerfile

Como mostrare en la sesión la idea es crear un pipeline en Azure Pipelines, basandonos en un repositorio GitHub, por lo que tienen dos opciones hacer un fork del código original de Jon y agregarle una copia de los tres archivos mencionados, o hacer un fork de mi fork, queda al gusto de ustedes.

Como es logico, es necesario contar con un Azure Web for Containers, un Azure Container Registry, y enlazarlos adecuadamente a nuestro Azure DevOps, pero creo que eso me da para un video corto que voy a preparar, de momento les comento que para poder usar el pipeline es necesario definir unas variables, como se indica en este grafico, pues de lo contrario el pipeline no se ejecutara.

Bueno, espero que la sesión les sea de utilidad, cualquier consulta me la dejan en los comentarios por si hay algo que falta precisar. Feliz despliegue!

 

 

 

 

Aprendamos Azure Pipelines (con videos)

Posted on by ecardenas

Curiosamente una vez que esto de la cuarentena se hizo que las comunidades se adaptaran y empezaran a proponer eventos online, así en Agile Perú organizamos, junto al a comunidad Agile Uy, el meetup «Retros remotas desde las trincheras»   que cubrio temas muy interesantes de como enfocar nuestras retros cuando los equipos no estan juntos, situación que durara por un buen tiempo, y que creo que cubrio varias de las dudas que mencione en mi post anterior, si no han visto el video, haganlo, Camila se lucio en este meetup.

Y por el lado de las comunidades Microsoft, las cosas han estado muy activas, tan asi que el 25 de abril participe en dos eventos el Virtual Azure Community Day, organizado por el Microsoft Users Group Perú, y en el Global Azure Latinoamerica, organizado la Comunidad Xamarin en Español; en el primer caso hable sobre «Despliegue de Aplicaciones Serverless con Azure Pipelines y Azure Functions«, para luego exponer «Mejora la seguridad de tus despliegues con Environments en Azure Pipelines«, la verdad es que estaba nervioso, la expectativa sobre los eventos era alta, pero felizmente todo salio bien y además hubo algo que aprovechar….

Resulta que en mi sesión sobre Environments (tema del que ya he comentado en este blog) se me pregunto por la disponibilidad del YAML que use para mi demo, y luego me recomendaron hacer un paso a paso de como crear un multi-stage pipeline, como un paso previo a los conceptos de seguridad que explicaba sobre Environments, así que prepare este video sobre como crear tu primer multi-stage pipeline en Azure Pipelines:

Y como es lógico también comparto el YAML usado en esta demo, la cual es efectivamente una preparación para ver lo explicado en la sesión sobre seguridad y Environments:

Y ya como bonus track les dejo mi presentación sobre serverless y Azure Functions.

Espero que les sea de utilidad!! Ya en breve estaremos hablando de las novedades que se trae el Build!

¡Añade aislamiento a tus despliegues con Environments!

Posted on by ecardenas

Regresando, en plena cuarentena, a las arenas del CI/CD para hablar algo que curiosamente ayuda a lograr cierto aislamiento a tus recursos en la nube al momento de desplegar: Los Environments en Azure Pipelines, así que vamos a ello.

Repasemos un poco, cuando hemos tenido pipelines usando Designer Mode, hemos definido el despliegue (en este ejemplo hacia un Web App) mas o menos así:

Y en el caso de Multi-stage pipelines, el paso de despliegue se define así:

Si nos fijamos en ambos casos, veremos que corresponde al Pipeline definir el recurso “destino” donde haremos nuestro despliegue:Subscripción, Grupo de Recursos y Recurso (en este caso una WebApp), o sea que toda la responsabilidad recae sobre el pipeline y quienes tienen acceso a desarrollar sobre el.

Si, es cierto que podemos establecer una cierta seguridad si, cuando enlazamos nuestro Team Project contra los recursos de Azure, lo hacemos contra Grupos de Recursos acotados y no contra toda una Subscripción, algo de eso lo vimos anteriormente, pero lo que vamos a ver proporciona una abstracción adicional y funcionalidades que nos ayudaran al seguimiento de nuestros procesos de despliegue. Finish Reading: ¡Añade aislamiento a tus despliegues con Environments!

¿YAML Pipelines? Si, ¡fácil! (2)

Posted on by ecardenas

Si, la evolución de Azure Pipelines hacia el mundo YAML sigue su marcha, lo cual quedo determinado con el lanzamiento de los multi-stage pipelines en el pasado Build, lo cual es un avance pues permite incorporar al modo YAML las capacidades de despliegue que ya hemos conocido desde hace buen tiempo, pero mientras este camino continua ¿como logramos que el usuario final se sienta confortable trabajando con YAML? pues la verdad sea dicha, a muchos de nosotros el trabajar a puro texto no nos hace sentir cómodos; así que (como ya vimos anteriormente) a la capacidad de agregar snipets de texto, desde el editor de tareas, hacia nuestro editor de texto, ahora se ha incorporado una ayuda que apenas Tom la menciono me encanto inmediatamente, así que vamos a ello.

Repasemos, si nosotros usamos la capacidad de agregar porciones de texto luego de parametrizar una tarea, nos vemos en la siguiente situación ¿qué hacemos si luego resulta que queremos editar la tarea y sus parámetros?, si es solo cambiar un parámetro de texto (una ruta por ejemplo) no hay mucho problema, pero si queremos cambiar mas de un parámetro dentro de una lista de opciones la cosa cambia un poco, así que lo que hasta hace poco hacía era pegar una nueva tarea con los parámetros actualizados y según correspondía reemplazaba o toda la tarea o solo la sección afectada, y a seguir adelante.

Pues bien ahora en los últimos sprint del producto se ha liberado la capacidad de editar una tarea ya existente en nuestro pipeline, para lo cual debemos fijarnos en las letritas que dicen «settings» sobre una sección de tipo task en nuestro YAML:

En este caso he elegido una tarea que me vino con la extensión para soportar Terraform (¡Si! ahora tenemos una extensión oficial para incluir despliegue de recursos cloud usando Terraform), hago clic sobre las letritas de settings y….

Listo, ya podemos editar totalmente la tarea y actualizar los parametros que hagan falta.

Espero que esto les sea de utilidad para ir avanzando en la creación de mas pipelines YAML, a estar atentos en las novedades que vendran saliendo en cuanto a los multi-stage pipelines.

¿YAML Pipelines? Si, ¡facil!

Posted on by ecardenas

Durante este tiempo, he estado explicando como construir Pipelines (antes Build definitions) en VST.. digo Azure DevOps, y para esto he mostrado como ir agregando diversas tareas a nuestro pipeline, para lo cual nos hemos apoyado en el diseñador gráfico que facilita la herramienta, algo que facilita la productividad y la curva de entrada para empezar a desplegar automáticamente, pero claro, pese a la facilidad había una objeción recurrente, el como poder versionar y/o editar en modo texto nuestros pipelines, claro, existe la posibilidad de exportar las definiciones como JSON, pero la verdad ese modo sufre de dos problemas: no esta integrado con el repositorio de código fuente y lo mas importante, no es leible fácilmente por humanos.

En base a este problema, desde el año Microsoft introdujo la opción de editar nuestros pipelines en formato YAML (usado también por Kubernetes y otras herramientas CI/CD) lo cual fue bien recibido por la comunidad de usuarios, pero este cambio involucraba el pasar a solo editar un archivo de texto en el repositorio, perdiendo los asistentes de las tareas y el tener que saber como escribir los diversos parámetros de las tareas a usar, bueno… eso esta cambiando desde ahora.

Primero, casi desde un primer momento se ofreció la opción de exportar nuestros Build Pipelines existentes como YAML y así tener un punto de partida para empezar el versionamiento, como se puede ver en las siguientes pantallas:

El gran paso viene dado ahora, pues al editor tradicional de puro texto, se le agrega un asistente que permite usar un formulario para configurar de manera visual los parametros de una tarea, que es lo que veremos a continuación.

En este caso lo que ya tenia es un YAML que compilaba una solución en .Net Core, siendo que me interesaba que una vez que la compilación se efectuara, tuviera disponible (para el posterior paso de release) una carpeta de la solución con el codigo ARM de la infraestructura que alojara la solución a desplegar, por lo que lo que tenemos que hacer es editar nuestro YAML y elegir la tarea respectiva:

Ya estamos en la tarea deseada «Publish and Build Artifacts», asi que pasamos a editar los valores necesarios:

 

Damos clic en Add, y listo, ya tenemos la porción de código de la tarea en nuestro YAML!

Ahora toca seguir las novedades del Build donde seguramente veremos mas avances sobre como Azure Pipelines nos puede ayudar en nuestros ciclos de despliegue.

 

 

Presentando Azure DevOps

Posted on by ecardenas

El día de hoy Microsoft anuncia Azure DevOps, que a primera vista podría ser un nuevo rebranding de VSTS, pero la realidad detrás de este cambio es mucho mas compleja, así que trataremos de explicarlo haciendo un poco de historia.

Team Foundation Server es presentado el 2005 como una solución integrada para las necesidades ALM de la época, en que se empezaba a buscar herramientas que apoyaran la gestión interactiva de proyectos, así como ir desarrollando los conceptos de Integración Continua y Gestión de Pruebas, rápidamente el producto fue adoptado por buena parte de las organizaciones que ya estaban trabajando con .Net como su plataforma de desarrollo de software, las versiones 2008 y 2010 fueron una mejora incremental que fueron simplificando el trabajo de los equipos, pero aun así el configurar un proyecto de Integración Continua requería pelearse con componentes de terceros y editar archivos XML.

El primer punto de quiebre se produce 2011 con el lanzamiento del preview de Team Foundation Service (que luego seria renombrado como Visual Studio Online) que al inicio era una implementación basada en Azure de los servicios que ofrecía TFS (y que me entusiasmo mucho apenas saque mi cuenta), pero que además de proveer al publico de una infraestructura ALM sin depender de la instalación de un servidor, permitió a Microsoft acelerar sus ciclos de entrega de novedades y pruebas de nuevas funcionalidades, siendo que la versión 2012 de TFS incluía como novedad esencial (al menos para mi) un nuevo modelo de creación de Builds Definitions, basado en XAML, que efectivamente hizo mas sencillo el proceso de despliegue… si usabas las plantillas proveidas en el producto! y es que la idea original era posibilitar la creación de plantillas personalizadas para diversos tipos de entorno (recuerdo que por ahí encontré una plantilla para facilitar el despliegue con ClickOnce, pero que nunca pude hacerla funcionar), para este año ya era mas que notorio el crecimiento de Git y GitHub como plataforma preferida de los desarrolladores, así que la versión 2013 de TFS incluía su propio repositorio Git (al igual que el entonces llamado Visual Studio Online), pero los cambios recién empezaban… Finish Reading: Presentando Azure DevOps