Hace unos meses, me encontraba en un cliente hablando de la posibilidad de sustituir su conjunto de aplicativos para ALM (Application Lifecycle Management o gestión del ciclo de vida de las aplicaciones) por el potente TFS de Microsoft. Se mostró fascinado por la herramienta: estuvimos navegando por el portal, mostrándole las gráficas y lo fácil que era gestionar todo el trabajo. No obstante, el líder tecnológico era escéptico y no confiaba en las capacidades del entorno que estábamos proponiendo.
Así que le retamos a proponernos el escenario más complejo que podríamos encontrarnos en su empresa. Tras unos segundos de silencio, su respuesta fue concisa: macbook air, programando en Java y que use Maven.
Challenge accepted
Desempolvé el mac-mini y en lo que se instalaba el eclipse, creamos un nuevo proyecto dentro de la cuenta de Team Foundation Service de Programando en .Net.
Alguno puede pensar que pecamos de soberbia, utilizando un entorno más adverso incluso que el propuesto. Pero en realidad, era lo único de lo que disponíamos sin gastar demasiado tiempo y dinero. Nuestro escenario se componía de:
- Un mac-mini de una generación tan antigua que no recuerdo ni el número. Pero actualizado a un Mac OS X 10.7.3.
- En lugar del TFS2012, decidimos usar el TFS en azure, para no perder tiempo buscando un equipo medio potente y tener que instalarlo. Sabiendo que esta versión carece de ciertas características, y lo que es más importante, que se encuentra en la nube, por lo que no podemos hacer "trampas".
- Para desarrollar usamos eclipse, en la ultima versión del momento. Y el Maven que viene instalado por defecto en el sistema operativo de la manzana. </ul>
El siguiente paso fue crear el proyecto de Java para Maven, con el arquetipo de "quickstart", desde eclipse:
Añadimos un pequeño "hello world" para no complicarnos demasiado el reto. Comprobamos que compilaba y se ejecutaba correctamente, y llegó el momento de añadirlo al control de código fuente de Team Foundation Service.
Para ayudarnos ha hacerlo tuvimos que instalar un plugin para eclipse. Antiguamente era conocido como "Visual Studio Team Explorer Everywhere", pero hoy en día lo encontraremos con el nombre de "TFS Plugin for eclipse":
Lo mejor de este plugin es que para los que estemos acostumbrados a Visual Studio, la única dificultad que vamos a encontrar, es mostrar la ventana de "Team Explorer". Y es que eclipse viene lleno de ventanas por defecto y tendremos que hacer una pequeña búsqueda para encontrar la nuestra:
Una vez la hemos activado veremos exactamente el mismo control, con todas (en realidad no todas, faltan las nuevas opciones de code review) las características que podemos encontrar en la versión, por así llamarla, original:
Para conectar con el proyecto que creamos al inicio del artículo, solo tuvimos que crear una nueva conexión añadiendo la dirección del TFS. En este caso, como usamos la versión de azure, introducimos la URL con "https://" por delante. Después seleccionamos el proyecto adecuado en el listado. Y ya teníamos acceso a todos los work items, las builds y control de código fuente.
Para continuar, lo que teníamos que hacer era indicarle a eclipse que el código proyecto actual iba a ser gestionado por TFS. Por lo que en el explorador de paquetes, seleccionamos la raíz del proyecto y buscamos la opción de compartir con Team Foundation Server:
Al realizar esta asociación, automáticamente se actualizó la información de la ventana de Team Explorer con los datos del proyecto listos para hacer check in.
Así que ya teníamos la mitad del camino recorrido. Habíamos conseguido conectar el entorno y subir el código fuente para que a partir de ahora fuera TFS quien lo gestionara. Pero a partir de aquí las cosas se iban a poner más difíciles, porque TFS "de fabrica" no puede crear builds de proyectos en lenguajes que no sean de la plataforma de Microsoft. Aunque si que nos facilita integrarnos con otras tecnologías.
Para crear una build automatizada de integración continua, lo primero que tenemos que hacer es exactamente lo mismo que en cualquier sistema: instalar las herramientas. En este caso las herramientas que usamos erán la JDK y Maven. Y un detalle importante que hay que tener en cuenta, es que TFS está instalado en máquinas Windows, por lo que tuvimos que descargar las versiones para ese sistema operativo.
El caso de Maven fue muy sencillo, porque directamente desde su página web pudimos descargar los binarios. Pero en cuanto al SDK de Java, tuvimos que pivotar en un ordenador con Windows. Ahí instalamos las herramientas y las copiamos en un pen drive, para al final tenerlas en el mac.
Creamos una carpeta llamada "tools" en el directorio local, que contenía el jdk y el Maven. Y en el control de código fuente creamos la misma estructura de directorios, pero vacía, para poder sincronizarlos. Acto seguido nos dirigimos al "Team Explorer", al panel de "Pending Changes" y en acciones buscamos la opción de detectar cambios. Así conseguimos sincronizar ambas carpetas.
En adición, comprobamos que cuando insertábamos código erróneo (concretamente borramos un ";") la build fallaba. Así ya podíamos estar seguros de que todo estaba correcto en nuestro entorno.
Conclusiones
Con la satisfacción de haber conseguido superar el reto en unas horas, presentamos los resultados a nuestro cliente. Y aunque aún no sabemos si ha decidido migrar o no, estamos seguros de que, al igual que nosotros, habrá aprendido mucho de esta prueba de concepto.
Team Foundation Server, a parte de sus conocidas virtudes, se ha mostrado como una herramienta muy potente y válida para equipos mixtos: con diferentes lenguajes de programación y entornos de trabajo. Y en definitiva, seguiremos recomendándola siempre que un cliente nos pregunte por una buena herramienta que le ayude en la gestión de sus proyectos.