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>
- $/nuestro-proyecto/demo –> $(SourceDir)\src
- $/nuestro-proyecto/demo/tools –> $(SourceDir)\tools </ul>
- <JAVA_HOME>$(SolutionRoot)\tools\jdk</JAVA_HOME>
- <M2_HOME>$(SolutionRoot)\tools\maven</M2_HOME> </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.
Después de hacer check in con estos cambios, ya teníamos disponibles las herramientas que íbamos a utilizar dentro de TFS, por lo que solo nos quedaba configurar la build. Entonces nos dirigimos al "Team Explorer", al panel de builds y ahí creamos una nueva:
Ante nosotros se abrió una ventana con un wizard que nos ayudaría a definir la build. Empezamos asignando un nombre:
Seguimos los pasos del wizard y en la segunda pantalla configuramos la planificación de la´s ejecuciones. La idea que teníamos era crear una de tipo "continuous integration", que se lanzara en cada nuevo check in, comprobando la integridad del nuevo código.
Después configuramos los directorios de trabajo. Aquí asociamos las rutas dentro del control de código fuente, con variables de ejecución de la build. Diferenciamos entre el código fuente y las herramientas:
En la siguiente pantalla definimos una carpeta dentro del control de código fuente donde almacenar los resultados de las diferentes ejecuciones. Lo que comúnmente se conoce como "drop folder".
Team Foundation Server usa proyectos de MsBuild para realizar las builds. Para poder editar el proyecto creamos una carpeta nueva en el control del código fuente y en la siguiente pantalla la configuramos. Esto implicaba que cuando termináramos de definir la build, podríamos dirigirnos a esta carpeta y explorar los archivos para modificar configuraciones a mano.
Como el sistema no encontró un archivo de proyecto en la carpeta que introducimos, nos indicó que teníamos que crear un proyecto nuevo. Así que lo hicimos presionando el botón de "create". Entonces una nueva ventana se abrió y nos dio a elegir entre una configuración basada en un archivo de build de Ant o en un archivo POM de Maven. Seleccionamos esta última y buscamos en el repositorio de código fuente, el archivo "pom.xml" de nuestro proyecto. Este archivo fue creado por el arquetipo de Maven, dentro de eclipse, de forma automática.
Una vez ya habíamos creado el proyecto de MsBuild, nos dirigimos a la última pantalla del wizard. Aquí se pueden definir las políticas de retención. Es decir, el lugar donde decidimos qué información y cuando queremos guardarla, sobre los resultados de la ejecución de la build. Nosotros dejamos las opciones que vienen por defecto.
Para finalizar tuvimos que configurar unos parámetros de entorno que desafortunadamente no tenían pantalla que nos ayudara a configurarlos. Así que buscamos la carpeta con los archivos de proyecto que definimos antes, y la mapeamos a un directorio local.
Entonces abrimos el archivo "TFSBuild.proj". Y antes de que acabará la sección de "PropertyGroup", justo antes de "ItemGroup", añadimos los directorios donde MsBuild va a buscar el JDK y Maven:
La peculiaridad es que aunque usemos diferentes versiones de Maven, la variable siempre se llamará "M2_HOME". Pero en este caso subimos la última versión del momento, una 3.
A partir de este momento ya teníamos la build configurada y lista para ser lanzada. Para probarlo nos dirigimos al panel correspondiente de "Team Explorer" y marcado la build que acabábamos de crear seleccionamos la opción del menú contextual "Queue new build".
Esperamos a que la ejecución terminara y pudimos ver en los resultados que había sido exitosa:
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.