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…

El año 2015 (en plena era Satya) se lanza TFS 2015 y un nuevo modelo de despliegue de aplicaciones basado en pipelines (que ya hemos comentado en detalle anteriormente), lo cual luego derivo el cambio de nombre de VSO a Visual Studio Team Services, y finalmente en la introducción de Release Management lo cual permitió definir a la etapa de despliegue (con su gestión de entornos, pruebas y aprobaciones humanas) como un paso posterior al proceso de Builds, lo cual (de la mano con una creciente cantidad de conectores para diversas tecnologías no Microsoft) permitió la consolidación de VSTS como una de las mas potentes herramientas para las diversas necesidades de un ciclo DevOps.

Estos tres últimos años han sido frenéticos especialmente en la incorporación de nuevas funcionalidades, soporte Docker, Tests de performance, Deployment Groups, etc… lo cual ha derivado en situaciones de confusión entre antiguos usuarios y potenciales nuevos clientes: «solo funciona para proyectos en .Net/Visual Studio» «Yo ya uso XX para mi gestión de proyectos» «¿necesariamente tengo que usar el repositorio que te da VSTS?, mi código esta en GitHub» «Mis  aplicaciones son para Linux ¿VSTS no es solo para Windows?», así que Microsoft se planteaba un reto de como hacer el producto mas asequible a las necesidades concretas de cada tipo de cliente, enfatizando el mensaje de una plataforma potente en un abanico amplio de tecnologías, ya no solo Windows y .Net sino también Linux, PHP, Node.JS, Java, etc, lo cual nos lleva al anuncio de hoy.

Y entonces, ¿como quedan las cosas a partir de hoy?

VSTS pasa a llamarse Azure DevOps, para de esta manera separar la imagen del producto de Visual Studio y reforzar el mensaje de que no es algo exclusivo de .NET. Azure se ha vuelto la plataforma que los desarrolladores asocian como moderna y cross-platform, así que con este movimiento se espera consolidar la posición de Azure DevOps como plataforma multi plataforma, multi cloud y multi lenguaje.

En este mismo proceso Azure DevOps pasa a representar una suite de servicios integrados, y ya no un producto/servicio monolítico, para que de esta manera los usuarios puedan seleccionar que servicios en concreto quieren utilizar o, si así lo prefieren trabajar con una linea completa end to end para su ciclo de desarrollo de aplicaciones. Los servicios quedan organizados de esta manera:

 

Azure Boards	Una potente herramienta para el trabajo de equipos, que permite usar un enfoque ágil para planear, hacer seguimiento y discutir el trabajo.
Azure Repos	Repositorios de código privados ilimitados alojados en la nube, tanto en Git como en el clásico TFVC.
Azure Pipelines	En mi opinión personal el servicio estrella de la suite, pues es una plataforma que permite un proceso CI/CD muy potente para cualquier, nube, lenguaje o plataforma siendo el único proveedor CI que ofrece pools tanto en Linux como macOS y Windows, pudiendo conectarse no solo a Azure Repos sino también a GitHub y a cualquier otro proveedor Git, como lo he comprobado hace poco conectándome a Gitlab sin ningún problema. Este sera el servicio en que me seguiré enfocando tanto en el blog como en mis actividades comunitarias.
Azure Test Plans	Una plataforma para la gestión diversos tipos de Test: Manual, exploratorio y de carga, garantizando una trazabilidad end-to-end.
Azure Artifacts	Facilita la creación, alojamiento y distribución de paquetes dentro de nuestros equipos, integrando este proceso dentro de nuestros pipelines CI/CD.

 

Oye, el producto se llama Azure DevOps y tu me dices que es multi cloud ¿no es algo contradictorio?

Si, Microsoft ha tenido un problema similar para romper la asociación «natural» que tenían TFS y VSTS con .Net, y en el momento actual (visto el éxito de Azure) se considera que la marca Azure ha logrado ser bien relacionada con lo que es innovación, por lo que ha decidido aceptar el tradeoff que representa colocar a esta familia de productos el nombre de su plataforma de nube (*), en ese sentido es bueno indicar que el soporte para despliegue de aplicaciones para AWS desde VSt… Azure DevOps es excelente, lo he estado testeando últimamente y espero poder compartir algunos ejemplos para demostrar que la promesa de que Azure DevOps es multicloud es una realidad, para muestra un botón:

Como se puede ver estamos «haciendo push» hacia el Registry de AWS (ECR) desde Azure DevOps, y de la misma manera he podido publicar una aplicación Web (no basada en Docker) en una instancia de Elastic Beanstalk mediante el uso de S3.

¿Qué pasara con Team Foundation Server?

El producto continuara evolucionando pero no habrá cambios de branding sobre las versiones actuales, solo cuando se lance la nueva versión del producto (la que correspondería a un supuesto ‘TFS’ 2019) pasara a denominarse Azure DevOps Server, la idea de tener el servicio disponible tanto para nube como on premise es poder ofrecer la mejor propuesta de valor «híbrida» en el mercado.

¿Qué tan potente y escalable es este producto?

La mejor evidencia de que Azure DevOps es una solución adecuada para las necesidades CI/CD a gran escala es la adopción interna que se ha producido dentro de Microsoft, con mas de 90,000 usuarios la plataforma sirve para el desarrollo de productos y servicios como Windows, Office, Visual Studio, y obviamente el propio Azure DevOps, a un ritmo de 90,000 despliegues por día. De la misma manera, empresas como Shell, Accenture y Columbia han adoptado Azure DevOps logrando acelerar sus ciclos de despliegues.

Pero ¿como podemos confiar en este producto si la semana pasada hubo una importante caída en Azure?

Efectivamente, la semana pasada tuvimos un momento de tensión debido a la caída del datacenter de South Central US, caída debida a que una tormenta eléctrica afecto los sistemas de enfriamiento de los equipos, lo cual afecto a la disponibilidad de los servicios de VSTS, durante este lapso Microsoft estuvo comunicando periódicamente el estatus de recuperación de los sistemas, de este hecho debemos notar que ha sido la ocasión en que la clásica pregunta de «Que pasaría si el datacenter es afectado por un <inserte desastre natural aquí>?» toma realidad por primera vez desde la aparición de la cloud, corroborando que ninguna organización esta totalmente segura y que tan importante como la defensa y prevención ante estas caidas es la capacidad técnica de volver a poner los sistemas en linea, lo cual en este caso se logro en un plazo razonable; este episodio definitivamente generara muchas lecciones tanto sobre como la arquitectura de los datacenters como de las estrategias de protección y recuperación de desastres a considerar en el futuro inmediato.  En este sentido es valido preguntarse cual es la capacidad real de nuestras organizaciones para salir airosas de un problema similar (especialmente en entornos on premise) y compararlo contra los recursos que nuestro proveedor cloud tiene para protegernos y recuperarse de manera razonable.

Acabo de entrar a mi cuenta de VSTS y no le veo mucha diferencia ¿que ha pasado?

Desde Junio, ha estado disponible en modo preview un nuevo sistema de navegación vertical, el cual define la base de la nueva experiencia de usuario que tendrá la suite, esta preview tiene que habilitarse explícitamente para empezar a trabajar con ella.

De la misma manera, todos los servicios de Azure DevOps permanecen habilitados por defecto en las cuentas existentes, por lo que corresponderá configurar en cada Team Project los servicios que estarán disponibles y visibles, asi que si por ejemplo no usaras Azure Artifacts o Azure Boards al deshabilitarlos tus usuarios ya no entraran «por error» a dichas opciones, pero OJO esta opción de filtrado de servicios solo esta disponible si has activado la opción

Las nuevas instancias de Azure DevOps empezaran con la nueva interfaz y branding desde el primer momento.

¿Qué pasara con todo lo que ya he hecho hasta ahora? ¿Como accederé a mi cuenta?

Todos sus proyectos seguirán estando disponibles como han estado hasta ahora, los enlaces miorganizacion.visualstudio.com seguirán funcionando, pero ahora estará como opción y redirect la forma dev.azure.com/miorganizacion. Las nuevas cuentas solo tendrán como URL a dev.azure.com/miorganizacion.

¿Habrá algún cambio en los precios?

Si, y es para mejor, anteriormente la capa gratuita para Pipelines (Build y Release) era de 240 minutos, ahora pasa a ser de 1,000 minutos. Aparte de que como cada producto se usa de manera independiente, así que si ahora solo estabas usando Pipelines, teniendo el repo en GitHub, no habrá facturación por Repos o Boards. Para mas detalles en cuanto a precios revisar https://azure.com/pricing/details/devops/.

¿Qué pasa con GitHub ahora que es de Microsoft?

Aun antes de la adquisición, Microsoft ya se había vuelto un usuario muy activo dentro de la comunidad GitHub, y desde hace tiempo ha hecho que sea sencillo colocar un repo GitHub como fuente de nuestras builds, pero siempre manteniendo la identidad y estilo que ha hecho de GitHub el repositorio lider en el mundo, en ese sentido a partir de ahora se ofrece como opción a los desarrolladores en GitHub poder vincular sus repos a Azure Pipelines desde el GitHub Marketplace (anteriormente el proceso solo podías empezarlo desde una instancia de VSTS) :

¿Qué pasa si tengo un proyecto Open Source? ¿tengo que pagar?

Cabe reiterar que si el proyecto es Publico, no habrá cobro por este proyecto, esperamos que esto motive a mas proyectos Open Source a usar Azure DevOps como su plataforma de trabajo. Al día de hoy se cuenta con varios proyectos Open Source que se han unido como early adopters de esta modalidad del servicio tales como VS Code, Atom, GitHub Desktop, cpython, TypeScript, libgit2, Git for Windows y Microsoft esta muy satisfecha por la recepción que se ha tenido.

En la comunidad ALM estamos muy entusiasmados por como nuestras herramientas favoritas han ido evolucionando, podemos decir sin temor a equivocarnos que Azure es el único proveedor cloud cuyo sistema CI/CD es uno de sus pilares mas fuertes y estratégicos; así que cuenten con nosotros para ayudarles en su uso, así que si tienen alguna opinión o pregunta sobre los cambios no dejen de poner su comentario.

 

Introducing Azure DevOps

Announcing Azure Pipelines with unlimited CI/CD minutes for open source

(*) Creanme, la decisión no ha sido de la noche a la mañana es algo que ha tenido meses de conversación analizando los pros y contras.