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

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)

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (I)

Quienes trabajamos en temas de Integración y Entrega Continua, estamos muy interesados en conocer el nuevo modelo de Builds que incorporan Visual Studio Online y TFS, así como lo que nos ofrece de cara a nuestros procesos de calidad y de despliegue, pero antes de esto es bueno hacer un repaso de como hemos llegado hasta aquí.

Primero que nada ¿qué es una Build? o mas bien una Build Definition, es básicamente un proceso que definimos para nuestros proyectos de software en el cual nos aseguramos de que:

  • Los proyectos compilen
  • Las pruebas unitarias y de integración funcionen
  • Se efectue el despliegue al entorno correcto

Algo de esto hemos visto en artículos anteriores, pero la verdad es que estas cosas no fueron faciles siempre, recordemos:

Las Builds aparecen en TFS 2005, bueno, en realidad ya estaban ahí desde hace un tiempo via MSBuild, que recordemos es básicamente el «motor» detras de Visual Studio y es el que se encarga de efectuar las compilaciones, lo que permitió TFS 2005 fue calendarizar las Builds o vincularlas de manera rápida a nuestros checkins (o protecciones de código) , lo cual ya era bastante frente a lo que teniamos antes (Visual SourceSafe) pero por contra era responsabilidad de los equipos (o los preDevOps como yo entonces) preparar todo lo necesario para que las piezas funcionaran y se lograra un despliegue, para esto había que lidiar mas con MSBuild (editando archivos XML y buscando plugins) que con el propio TFS que a efectos prácticos simplemente lanzaba los proyectos y capturaba cuando había errores.

La situación fue mejorando progresivamente tanto en TFS 2008 como en TFS 2010, pero el verdadero cambio se dio en TFS 2012 (que vino de la mano con las pruebas de lo que entonces se llamo TF Service y ahora conocemos como Visual Studio Online) cuando se introdujo un modelo de Builds basado en XAML (en adelante XAML Builds) que prometía la idea de que el flujo fuera modelado siguiendo lo que ya se conocía de Workflow Foundation, en ese sentido uno modelaba el proceso y secuencia de pasos necesarios para nuestro tipo de proyecto, grababa un Template y el MSBuild era usado como etapa final, de hecho la pantalla que vemos en Visual Studio para editar nuestra Build Definition depende directamente del template usado (en el caso de esta Build Definition el template GitContinousDeploymentTemplate.12.xaml)

Clipboard01

Este modelo permitió colocar de manera explicita los procesos de Test fuera de MS Build y a la vez utilizar otros frameworks de Test (como NUnit) de manera transparente, posibilitando ademas que algunos terceros publicaran algunos template XAML con modelados específicos para ciertas necesidades; a nivel practico lo que ocurrió fue que las templates mas usadas fueron las que Microsoft fue agregando, destacando las que permiten el soporte de Git (que recordemos solo se incorporo a partir de TFS 2013) y Azure, la cual sin darnos cuenta ya hemos usado anteriormente.

A grandes rasgos este ha sido el modelo que se mantuvo en TFS 2013 y las sucesivas actualizaciones de Visual Studio Online, en el ínterin Microsoft abrazo Git, e hizo grandes esfuerzos por acercar TFS/VSO al mundo Java mediante plugins para Eclipse y avances para integrar Builds de Maven dentro de la plataforma Microsoft, la intención era clara: permitir que VSO sea un gran motor de Integración y Entrega Continua no solo para proyectos .Net sino también otras tecnologías como Java, node.js o iOS, pero lamentablemente el modelo de XAML con todas las ventajas que implicó no permite ese soporte de manera sencilla out of the box, así que desde hace unos meses se nos ha estado avisando de que Microsoft esta trabajando un nuevo modelo de Builds, que es lo que vamos a ver en este y los siguientes articulos.

Llegados a este punto, indiquemos los cambios que representa el nuevo modelo de Builds frente a las XAML Builds (que siguen funcionando perfectamente)

– Totalmente basado en Web, antes podíamos gestionar todo el proceso de las XAML Builds desde el IDE de Visual Studio, siendo que ahora para crear nuestras nuevas Build Definitions debemos ir a nuestra web de Visual Studio Online o Team Foundation Server 2015, lo mismo para ver el estado de ejecución e histórico de estas, todo via web.

– Flujo pipeline, simplemente es una secuencia de pasos desenchufables, para de esta manera conectar o agregar el paso que se requiere y de ser necesario eliminar un paso no necesario, en este gráfico los 4 primeros pasos vinieron por defecto y yo agregue el ultimo paso de Azure Web App Deployment (como veremos en el próximo articulo).

Clipboard02

– Modelo extensible, como mencione anteriormente la idea es dar soporte no solo a las tradicionales compilaciones de .Net basadas en MSBuild sino a Gradle, Maven, Ant (y seguro mas por venir) etc… miren nomas:

Clipboard03

– Hay que hacerlo todo explicito, si bien el proceso que conocemos para enlazar directamente nuestras Web de Azure con un proceso de CI en VSO resulta muy practico, a la hora de hacer cosas mas avanzadas (como integración con BD) tenemos que parametrizar MSBuild, asi que en este modelo debemos precisar todas las piezas que formaran parte de nuestro proceso en la sección correcta, pero esto lo veremos con mas detalle en la siguiente entrega.

Bueno, ya tenemos definido el marco teórico para empezar a trabajar, para esto nos valdremos del ejemplo Parts Unlimited que esta disponible en GitHub y que ha sido explicado inicialmente en ingles por Charles Sterling en cuyo trabajo me basare (y al que agradezco por permitirme su uso) y agregare algunas cosas que fui descubriendo en el proceso de implementar el ejemplo, ¡espero sus comentarios!

Team Foundation Service, tu mejor opción en ALM :)

Si algo se me ha pasado es compartir esta presentación con la que introduje Team Foundation Service en el ultimo Agile Open Lima, así como a algunos compañeros de trabajo

En este tiempo lo que ha cambiado es que TFS ya es RTM, por lo cual ahora si que se tienen los planes de licenciamiento, y algo muy interesante, ahora esta integrado con GIT. No queda sino animarlos a probar Team Foundation Service, el cual es gratis para equipos de hasta 5 personas y por supuesto seguir los blogs de El Bruno y Jersson, que siempre nos estan informando novedades sobre esta potente herramienta.

¡Y se viene el Agile Open Lima VI!

Por si no lo saben, el próximo domingo 26 de Agosto se viene el VI Agile Open Lima, asi que por si no te has apuntado ya te estas demorando demasiado :), este evento es peculiar pues por primera vez se hace en domingo y en las afueras de Lima (si, aun mas lejos que Surco o La Molina) concretamente en Ñaña en la sede de Universidad Peruana Union, lo cual permitirá realizar algunos juegos agiles al aire libre. Para esta ocasión estoy proponiendo las siguientes sesiones:

 Estoy muy entusiasmado con estas sesiones, llevo varios meses probando la versión Beta de Team Foundation Service, y me ha sorprendido gratamente sus capacidades para llevar a cabo integramente la gestion del Ciclo de Vida de las Aplicaciones, desde la toma de requerimientos y gestion del Backlog hasta la automatización del despliegue (y por supuesto haciendo la Build en la nube), si creías que TFS es solo un «source safe mas potente»… esto te hara pensar ;).

Sobre la segunda charla, intentare replicar un estilo «reality show» que pude ver en acción por parte del maestro Angel Medinilla en el Agile Open Spain del 2009, compartiendo las experiencias que hayamos tenido trabajando con equipos distribuidos, ya sea como cliente o como proveedor, en un momento en que el desarrollo de proyectos offshore esta creciendo en nuestro país, sera algo muy interesante para ver como mejoramos nuestra forma de desarrollar esta clase de proyectos desde un enfoque agil.

Así pues cuento con ustedes en este nuevo Agile Open Lima y en particular con sus votos para poder llevar a cabo estas sesiones :), ¡nos vemos en Ñaña!!.

_DSC8580.jpg IMG_5890.jpg _DSC8807.jpg

Otro motivo mas para no usar Word como editor grafico

A pesar de las opiniones en contra, sigo creyendo que es malisima idea usar MS Word como editor grafico, si algunos me diran que es lo mas simple, que no hay que hacerse complicaciones y todo eso, pero experiencias recientes no me han hecho sino insistir en este tema.

Como dije, una de las razones por las que se realizan capturas de pantalla es para documentar errores que se encuentran en las aplicaciones, pues bien esa tarea de documentacion y reporte es facilitada enormemente mediante el uso de Team Foundation Server, herramienta sobre la cual nuestro amigo El Bruno se explaya frecuentemente para alivio nuestro, al usar dicha herramienta nos es posible describir textualmente la situacion que nos afecta como usuarios y de ser necesario, incluir un archivo adjunto para complementar dicha descripcion.

El problema se presenta cuando, como testeadores, revisamos el bug encontrado y vemos que se ha adjuntado un documento de Office, generalmente Word, el cual presenta un pequeño inconveniente: la apertura de archivos pasa por Internet Explorer (como me explico el Bruno, el abrir un archivo desde Team Explorer invulcra el invocar Web Services) por lo cual se hace necesario verificaciones de seguridad, y siendo que potencialmente un documento de Office podria contener contenido peligroso, las aplicaciones no hacen sino que cumplir su rol preguntando hasta 3 veces el usuario y password que tengamos en el TFS, todo comprensible desde el punto de vista tecnico (a pesar de lo irritante que pueda ser el retipear a cada rato) hasta que nos percatamos de dos pequeños detalles:

  • Los archivos JPG al no ser contenido potencialmente peligroso se abren directamente en el Internet Explorer.
  • La mayoria de los archivos de Office adjuntos solo incluian una captura de pantalla y ningun contenido adicional.

Queda claro que si no se va a usar los documentos de Office para algo de veras importante, como una especificacion funcional por ejemplo, no tiene sentido seguir usandolo para captura de pantallas pudiendo usarse el ya comentado Irfanview o el clasico Paint, el cual ha sido muy remodelado en Windows 7.