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

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!

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

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