miércoles, 9 de mayo de 2018

Memorias de un Arquitecto .Net - Parte 3: Herramientas

¡Hola! En esta tercera y última entrega de la serie “Memorias de…” vamos a enfocarnos en otra de las evoluciones que se vienen dando en el mundo Microsoft. En esta oportunidad, vamos a analizar qué pasó con las herramientas de apoyo a la construcción de aplicaciones que nos ofrece la compañía y cómo esto ha alterado el tablero de juego de quienes desarrollamos SW.

Trabajemos o no con .Net, no podemos dejar de reconocerle sus méritos a Visual Studio como una muy buena IDE para el desarrollo de soluciones de SW. Es cierto, como toda aplicación tiene sus aspectos a mejorar, pero la realidad es que funciona bastante bien.

Sin desmerecer las versiones previas, podemos decir que la historia de Visual Studio comenzó a pisar con fuerza con la llegada de la versión 2003, lanzada al mercado en abril de ese mismo año. Si bien era modesta, incluía varios features interesantes para la época. Desde entonces, no paró de crecer a pasos agigantados y con cada nueva versión se incluían más y mejores características que nos facilitaban el trabajo a los desarrolladores. Así siguió evolucionando, pasando por las versiones 2005, 2008, 2010, 2012, 2013 y 2015.

Finalmente llegamos al presente. Y es aquí donde quiero que prestemos atención a algo interesante: además de liberar al mercado la versión 2017, recientemente surgieron dos versiones en paralelo. Estas fueron construidas totalmente desde cero, para dos sectores de la comunidad que anteriormente no encontraban en VS un espacio de trabajo acorde a sus necesidades, y por qué no, a sus propios gustos.

En primer lugar, quiero mencionar a Visual Studio Code, la interfaz de desarrollo Open Source de Microsoft. Gracias a un sinfín de extensiones permite desarrollar prácticamente en cualquier lenguaje moderno que podamos imaginar. Está destinada a la comunidad en general, tanto a aquellos que trabajamos con .Net, como a quienes utilizan otras tecnologías: Java, PHP, Ruby, Node.JS, y la lista sigue.

Y en segundo lugar quería comentar que a comienzos del 2017 Microsoft ha lanzado al mercado Visual Studio for Mac, destinada a todas aquellas personas que desde sus Mac quieran desarrollar aplicaciones tanto para este sistema, como para los dispositivos móviles (a través de Xamarin) y para Linux y Windows. Lo mejor de todo, viene con C# y .Net Core integrado nativamente.

¿Visual Studio es la única IDE disponible hoy en día en el mercado? ¡No! Hay un montón más. Las hay propietarias e independientes. Cada una tiene sus ventajas y desventajas, y conviene usarlas o no, de acuerdo al contexto de cada proyecto. Pero no podemos negar la fuerte apuesta que está haciendo Microsoft al respecto: ofrecer plataformas de desarrollo para diferentes grupos de profesionales.

Pasemos a otro grupo de herramientas: los repositorios de código fuente. Mientras escribo me pregunto, ¿cuántos de ustedes llegaron a usar Visual SourceSafe? Yo recuerdo que fue el primer repositorio que utilicé de la mano de la tecnología .Net, y no tengo muy gratos recuerdos al respecto. Seamos objetivos, la herramienta no era mala, pero tampoco era buena. Ahora bien, en el contexto de aquella época, funcionaba y con eso nos alcanzaba.
Ya ha pasado bastante tiempo desde que Microsoft decidió discontinuar VSS en favor de Team Foundation Server (más conocido como TFS). Esta herramienta es una suite completa que permite gestionar tanto código fuente como otros artefactos relacionados con los proyectos de desarrollo. En lo que respecta al almacenamiento de código fuente, el módulo que se encarga de gestionar esta funcionalidad se llama Team Foundation Version Control (TFVC). La primera versión de TFS fue liberada en 2005, y siguió creciendo a lo largo de los años, pasando por las versiones 2008, 2010 y 2012.

Sin embargo, en línea con los cambios que se vienen debatiendo, desde la versión 2013, tenemos la oportunidad de contar con una alternativa a TFVC: ni más ni menos que la posibilidad de poder elegir Git como repositorio a la hora de generar un nuevo proyecto en el TFS. Lo interesante es que no se trata de una implementación particular de Microsoft, sino de la implementación estándar de la herramienta (la misma que utiliza GitHub).

Esta jugada de Microsoft permite que cualquier IDE que tenga soporte para Git, aunque no sea de “la familia .Net”, pueda utilizar TFS + Git como repositorio. Podemos estar desarrollando en VS Code, Android Studio o Eclipse, tanto desde Windows como desde Linux o desde una Mac, y tener nuestro código fuente (en el lenguaje que fuera) en un TFS.

En el mundo .Net no sólo usamos TFS como herramienta para gestionar el código fuente sino también para gestionar los proyectos en los cuales participamos. Tal como comentaba más arriba, TFS es una suite por lo que posee muchas otras utilidades además de TFVC y Git, por ejemplo: Reporting, Team Building, Release Management, etc.

La cuestión, desde mi punto de vista, se da en que desde hace un tiempo las metodologías de desarrollo han evolucionado y en los equipos hoy se busca ser más agiles, adoptando las nuevas tendencias. Metodologías como Scrum y Kanban hicieron que TFS tenga que salir a adaptarse para sobrevivir.

Con la llegada de DevOps y Cloud el panorama terminó de cambiar y Microsoft no perdió el tiempo. Es así que lanzó oportunamente al mercado una nueva plataforma: Visual Studio Team Services (VSTS). Esta herramienta vendría a ser como un TFS en la nube, pero con muchas más funcionalidades y el soporte continuo del equipo de Microsoft que la mantiene al día.

Más allá de no tener que instalar y mantener un TFS on premise, VSTS permite gestionar cualquier proyecto de desarrollo de SW, independientemente del lenguaje y la IDE que estemos utilizando. Permite configurar diferentes tableros, de acuerdo a si deseamos trabajar con el esquema clásico, Kanban o Scrum. Además, incluye features de CI & CD con pasos pre-configurados que permiten agilizar el despliegue de nuevas versiones de las aplicaciones que estemos construyendo con un esfuerzo mínimo. También, permite integrar todo el ciclo de vida del SW de punta a punta: desde el relevamiento y documentación de la funcionalidad a construir hasta la planificación del testing y el despliegue automático.

Es cierto, para usar VSTS profesionalmente se requiere contar con licencias para cada miembro del equipo, pero ¿cuánto nos ahorramos respecto a no tener que mantener esta infraestructura por nosotros mismos? ¿qué ventajas puedo sacar de todas las utilidades que me ofrece? ¿qué tareas me facilita o ya me provee resueltas out of the box? Estas consideraciones, entre otras, son las que debemos preguntarnos antes de optar por usarla o descartarla en nuestros proyectos.

En los últimos años hemos vivido una gran cantidad de cambios: algunos se originaron dentro de la comunidad de quienes construimos aplicaciones, otros en las nuevas tecnologías, metodologías, herramientas, procesos, etc., y otros tantos en quienes son los principales actores del mercado de SW.

Para quienes siempre trabajamos vinculados a .Net, al principio nos sorprendió el cambio de enfoque que impulsó Microsoft pero luego, con el correr de los años nos fuimos acostumbrando y hasta alegrando por las oportunidades que surgían. Ahora podemos contar con mejores herramientas y que se adaptan mejor a la forma en la que se construye SW hoy en día. También podemos desarrollar en y para la plataforma que más nos guste (Linux, Mac, Andorid, entre otras). Además podemos usar componentes open source en nuestras soluciones, guardar nuestro código en Git, etc. ¿No es acaso un panorama mucho más abierto, interesante y desafiante? Yo, al menos, creo que sí.

¿Y para quienes no trabajan directamente con .Net? Bueno, hoy cuentan con la oportunidad de poder utilizar desarrollos de Microsoft en sus proyectos, como es el caso de VSTS, TypeScript, o VS Code, entre muchos otros más. 

Es cierto, los más escépticos se siguen preguntando qué tan real o hipócrita es el cambio que viene impulsando la empresa de las ventanitas en estos últimos años. A mi entender, sólo el tiempo nos dirá si esta apuesta fue sincera y honesta, o no.

Hemos llegado ya al final de esta serie, y sólo me resta agradecerles que me hayan acompañado en la lectura y reflexión a lo largo de estos tres artículos acerca de cómo ha evolucionado el trabajo de Desarrollador .Net en los últimos años.

Mi intención está lejos de inclinar la balanza a favor o en contra de alguien; en definitiva, cada uno puede desarrollar con los lenguajes, plataformas y herramientas que más le guste. Y es ahí donde creo que al abrirse el juego de Microsoft y presentar alternativas, nos está dando la oportunidad de elegir cómo queremos hacer nuestro trabajo.

Como siempre, ¡hasta la próxima!

Autor:
Ing. Ariel Martín Bensussán
.Net Practice Manager