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

Buenos cambios para el entorno DevOps en Microsoft

Guau.. vaya con las novedades de Connect 2015, bastantes cosas en desarrollo multiplataforma, cloud, Windows… pero centrémonos en lo que corresponde a nuestro interés como DevOps y entusiastas del ALM, asi que vamos con calma….

Adiós Visual Studio Online…. hola Visual Studio Team Services, si, un nombre puede ayudar mucho, y desde que Microsoft le dio el nombre oficial a lo que originalmente conociamos con Team Foundation Service me ha sido complicado explicar que VSO no es un IDE como Visual Studio pero en el browser, sino por el contrario una herramienta ALM (Scrum, repositorio, build…), ahora este cambio de nombre puede ayudar un poco mas a entender las cosas, así que repitamoslo una vez mas: Visual Studio Team Services (VSTS).

Preview de Release Management para VSTS, una gran noticia, quienes han seguido mis artículos sobre despliegue, se habrán percatado que el proceso de paso a entornos lo había configurado como un paso final del proceso de Build, pues bien… una etapa tan importante requiere una gestión por separado que facilite no solo colocar la aplicación en el primer entorno, sino también mover las versiones de la aplicación entre diversos entornos, y ese es el objetivo de RM que ha evolucionado de ser un producto separado a ser una parte integral del entorno de VSTS, permitiéndonos entre otras cosas establecer aprobadores manuales que decidan si una versión de nuestra aplicación ya esta lista para pasar al siguiente nivel, como detalle adicional es importante indicar que no es necesario que tu ciclo de Build lo hayas gestionado con VSTS sino que tu paquete también puede provenir de Jenkins, y claro… como era de esperar nuestro entorno destino no es solo Windows. En las próximas semanas iremos desgranando un poco estas facilidades.



 

Preview de Code Search en VSTS, una ayuda que nos permitirá ubicar el código deseado de manera potente a través de nuestros repositorios via web.

Soporte para Subversion en TFS y pronto en VSTS, hay que reconocerlo a pesar del crecimiento de Git, hay muchos desarrolladores en el mundo Java que se sienten muy cómodos con Subversión, así que en breve se tendrá como opción el que nuestros Team Projects se creen con Subversión como tipo de repositorio, la cosa es tener opciones ¿no?

A seguir poniéndonos al día!

 

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

Bueno, ya salimos de Fiestas Patrias y toca cumplir lo prometido, ir conociendo el nuevo modelo de Builds que ha sido introducido en Visual Studio Online y en Tean Foundation Server 2015 (que ya esta disponible en su versión final) y como comentabamos, se usara el ejemplo Parts Unlimited, que por tener ya las cosas hechas respecto a integración con BD nos servira para dar una visión integral del despliegue.

Los pasos que seguiremos seran los siguientes:

1) Descargar el código fuente de Github, crear nuestro repositorio en VSO y hacer las pruebas en local.

2) Preparar los Resource Group y todas los recursos Azure necesarios para el despliegue desde Visual Studio, de esta manera no tendremos que crear las cosas manualmente desde el Portal, salvo que sea estrictamente necesario.

3) Preparar la Build propiamente dicha y probarla.

Lo primero es crear un proyecto en Visual Studio Online, nótese que como siempre elegimos Scrum como plantilla y en este caso usaremos Git como modelo de repositorio.
Clipboard04

Luego de esto toca conectarse a dicho proyecto desde nuestro Visual Studio, y luego proceder a clonar el repositorio (que forma parte del proyecto de VSO), en este caso el repositorio aun estará vació (a menos que hayamos creado un readme desde el portal de nuestro proyecto), en mi caso particular edite la carpeta local donde se va a clonar el repositorio pues por defecto Visual Studio intenta crear los repositorios locales de Git en el disco C:

Clipboard05Ahora viene la parte interesante, Parts Unlimited es un proyecto muy interesante que si bien empezo con ASP.NET 4.x ahora están trabajando en una version basada en ASP.NET 5, pero para efectos de esta demo de Integración Continua nos basaremos en la versión 4.X para lo cual deberemos dirigirnos a este branch en GitHub, desde donde podremos bajarnos un Zip con todo el proyecto, lo descargamos luego de lo cual estaremos listos para integrarlo en nuestro repositorio Git de VSO. Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (II)

Gestión automática de entornos de despliegue con Azure (Primeros pasos y un pequeño tropiezo)

Visto el contexto del problema y la solución potencial, decidí verificar si era posible aplicar esta solución dentro de los nuevos Azure API Apps, nueva tecnología agregada a la oferta de Azure que permite generar APIs REST a nuestra aplicación de manera sencilla, evolucionando lo que ya conocíamos de las Web API.

De primera entrada fijemos los objetivos y características de lo que trataremos de demostrar:

  1. Gestionar nuestro respositorio en Visual Studio Online, usando Git como modelo de repositorio.
  2. Efectuar despliegues automatizados a cada vez que hagamos un commit y sincronización hacia VSO.
  3. Que cada entorno desplegado utilice distintos valores de configuración, que la aplicación sea capaz de “leer” dichos valores y actuar acorde a ello.
  4. Efectuar Intercambios (swaps) entre nuestro entorno de QA, hacia Producción, verificando que si bien la aplicación se actualiza, los valores de configuración se mantienen.

Nuestro primer paso es crear un proyecto en Visual Studio Online, asi que vamos a ello:

Slots01Creado nuestro proyecto vamos a Visual Studio 2013 y nos conectamos a nuestro servidor eligiendo al Team Project que acabamos de crear:

Slots02Hecho esto, nos corresponde “clonar” (esto es terminología Git) el repositorio para empezar a trabajar

Slots03

Finish Reading: Gestión automática de entornos de despliegue con Azure (Primeros pasos y un pequeño tropiezo)

Decisiones de repositorio y workspace en TFS/VSO

Antes cuando desarrollabas SW y se te planteaba el versionar tu código fuente algunos no tenían idea de lo que se hablaba, y en el otro extremo solo había dos opciones ampliamente usadas: SourceSafe y CVS, aparte claro de opciones chapuceras como: diskettes, carpetas fechadas compartidas y USB.

Ahora mucha agua ha corrido bajo los puentes, así que el que no versiona SW es porque ha vivido aislado de la realidad, o porque de alguna manera no ve la justificación económica de ello (hace poco me comentaron que una entidad crediticia sigue manejando sus desarrollos con carpetas fechadas y comprimidas y recién iban a analizar la viabilidad de usar SVN), por lo que el problema en estos momentos es decidir que repositorio usar y las implicancias de su decisión.

En este momento me pueden decir “¡Pero tu usas TFS, ya no tienes que decidir!”, pues la verdad que no, hasta el 2010 no había que tomar muchas decisiones, pero en el momento actual también toca decidir como es que vamos a usar TFS, entonces.. vamos a ello, repasemos el escenario.

En este momento al crear un proyecto en TFS/VSO tenemos dos opciones de mecanismo de control de versiones:
 

TFVC: El mecanismo tradicional de TFS de toda la vida, heredando terminología de SourceSafe como “check-in” “check-out”, pero mucho mas potente, todo almacenado en SQL Server, permitiendo gestión de branches y merges, aparte claro esta de la integración de tus changesets con una actividad determinada. Su modelo es Centralizado al igual que Subversión por ejemplo, con todas las implicancias que eso trae, que no vamos a discutir ahora.

Lo curioso es que si optamos por usar esta modalidad hay que tener en cuenta un detalle adicional: el tipo de Workspace ya que hasta TFS 2010 solo había el workspace en servidor, vale decir que el servidor de TFS llevaba un seguimiento de cual es el estado de cada una de las maquinas que se conectaban al repositorio, lo cual debemos reconocer no funcionaba muy bien, llegando al extremo de que en algún momento el usuario sabia que no estaba sincronizado, pero el servidor insistía en que no tu workspace esta bien, y arreglar eso, complicado.

Con los workspace locales, esos problemas ya no existen, aparte de que proveen una mayor flexibilidad para trabajar sin problemas cuando el servidor esta desconectado, pero de eso nos cuenta con mas detalle El Bruno, solo debo añadir que si se opta por TFVC solo hay un escenario en el cual tendría sentido usar workspace en el servidor: cuando tu IDE aun es VS 2010 o anterior, en cualquier caso es workspace locales, ahh la decisión se hace en el IDE no en el servidor.

Git: ya hemos hablado anteriormente de este recién llegado a las plataformas Microsoft, y creo sinceramente que debemos probarlo, intentar usarlo en nuestros proyectos, pues los DVCS han llegado para quedarse y Git ya es casi el estandar de facto, proveyendo muchas ventajas; dicho esto debemos ser conscientes que a la fecha (si alguien lee esto 2 años despues puede que se ria), si bien Microsoft ha integrado totalmente el “protocolo” backend de Git en sus productos aun no ha terminado de pulirlo en cuanto a interfaz (quiero creer que la próxima versión de VS tendrá una interfaz para Git que rivalice con SourceTree) y que de momento no podemos usar una herramienta tan potente como los Code Review integrados, a los cuales me acostumbre rápidamente cuando use por primera vez TFS 2012, ni tampoco los Gated Check in a la hora de hacer Integración continua (en breve: esta modalidad permite que un cambio no se añade al repositorio si la Build falla).

Conclusión: si no tienes una demanda muy fuerte de hacer uso de CodeReview o Gated Check In, usa Git, pero de la mano ve aprendiendo los comandos aun no disponibles desde el IDE, pues seran necesarios para sacarle el jugo. En otro caso (el Code Review si que puede ser un deal breaker en muchos casos) no temer y usar los workspace locales con TFVC.

A ver cual es la situación de aquí a un año, probablemente nuestro flujo cambie para entonces.

Consideraciones al usar Git con Visual Studio y TFS 2013

En los últimos meses quienes trabajamos con tecnologías Microsoft, especialmente con TFS hemos sido arrastrados a una voragine de cambios que empezó con la herramienta Git-TF que permitia cierto grado de sincronización entre repositorios Git y TFS, pero eso fue solo el primer paso, luego vino el soporte nativo de Git en Team Foundation Service Visual Studio Online, el soporte a repositorios Git en un update a Visual Studio 2012, y ahora con Visual Studio 2013 y TFS 2013 la total integración entre Builds y repositorios Git.

Así que en los últimos meses hemos tenido que acercarnos a Git y experimentar con el, en ese sentido como primer punto de partida sugiero revisar los articulos de Eduard sobre el tema, pues nos permiten acercarnos a esta plataforma desde una perspectiva de quien ha trabajado en modo centralizado toda la vida.

Ahora bien, nuestro principal interés es tratar de seguir usando nuestras herramientas de TFS de toda la vida pero vinculado al nuevo repositorio, la buena noticia es que si, podemos tener lo mejor de ambos mundos, pero hay que tener unas consideraciones a fin de sacarle el máximo partido a nuestra nueva herramienta (Si aun dudas en usar Git, mejor lee a El Bruno) asi que aqui vamos:

  • Los repositorios Git de Microsoft (TFS on premise y Visual Studio Online) cumplen totalmente las especificaciones de Git, en ese sentido puedes conectarte a tu repositorio no solo desde Visual Studio 2013 sino también desde una herramienta como SourceTree.
  • El soporte de Visual Studio para los flujos de trabajo de Git (stash, rebase, etc) que tanto gustan a los veteranos de Git aun esta en progreso, en ese sentido nunca viene de mas poder tener un SourceTree a la mano configurado para conectarse a nuestro repositorio, si, funciona perfectamente.
  • Cuando te conectas a un Team Project con Git, se te ofrece la opción de clonar el repositorio a fin de poder empezar a trabajar, lo cual crea un repositorio Git local, y dentro de este repositorio el archivo .gitconfig queda apuntando a la ruta del repositorio online (en el caso de VSO la ruta tiene la forma de https://midominio.visualstudio.com/DefaultCollection/_git/MiTeamProject), todo bien hasta ahi, pero si por alguna razón queremos cambiar de repositorio remoto tendremos que recurrir a la edición manual del archivo en cuestión (o usar SourceTree).
  • Ya que hablo de usar linea de comandos y/o otra herramienta cabe indicar que hay que configurar nuestra cuenta de VSO para poder conectarse transparentemente a entornos diferentes a Visual Studio, para ello nos vamos a la esquina superior derecha de nuestro portal de VSO, elegimos nuestro nombre

    Le damos a “My profile”

    y veremos que tenemos un nombre de usuario primario en formato “email” que es el que usamos para conectarnos al portal de VSO, pues bien lo que toca es crear un nombre de usuario secundario (que NO debe tener formato email) el cual sera el que usemos cuando intentemos conectarnos con linea de comandos o SourceTree.

  • Como mencionaba lineas arriba Visual Studio reconoce directamente la configuración Git estandar, en ese sentido es perfectamente posible agregar un repositorio remoto adicional a nuestro archivo .gitconfig (en este caso un repositorio GitHub), o via SourceTree:

    quedando de la siguiente manera:

    [core]
    bare = false
    repositoryformatversion = 0
    filemode = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
    [remote “origin”]
    url = https://xxxxxxx.visualstudio.com/defaultcollection/_git/Applicat%C3%B3n
    fetch = +refs/heads/*:refs/remotes/origin/*
    [branch “master”]
    remote = origin
    merge = refs/heads/master
    [remote “Github”]
    url = https://github.com/fisica3/Applicaton
    fetch = +refs/heads/*:refs/remotes/Github/*

    Ocurrido esto, cuando sincronizemos nuestros cambios desde Visual Studio, se efectuara una sincronización simultanea a ambos repositorios remotos, lo cual puede venir muy bien en ciertos entornos, pero lamentablemente por ahora no tendremos la opción de elegir cuando hacer los sync por separado, seran en simultaneo.

  • Otro detalle de cuando tenemos mas de un repositorio remoto configurado en nuestro repositorio local: hay que tener cuidado pues si tenemos alguna Build Definition basada en Integración Continua esta puede no dispararse, tratare de encontrar una solución para evitar este problema, pero de momento hay esa pequeña limitante.

Pues nada, espero que estas consideraciones sobre Git en nuestro Visual Studio sean utiles para empezar a sacarle partido y empezar a trabajar, confio que en los proximos updates Microsoft mejorara el IDE para soportar flujos mas avanzados, pero de momento ya tenemos todo para empezar a trabajar, asi que si no has sacado tu cuenta en Visual Studio Online hazlo ya!.

Si tienes una duda no dejes de comentar y preguntarme.

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.