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.

Integrando Continuamente Visual Studio 2012 con Hudson

Quienes me conocen personalmente saben que me encanta Team Foundation Service como herramienta ALM y de Integración Continua, pero a veces toca que por diversas razones no podamos contar con esta solución que out of the box nos ofrece muchas cosas, en este caso el stack con el que teníamos que trabajar era Subversion y Hudson, por las referencias que tenia ya varios proyectos habían utilizado el plugin de Hudson con MSBuild (y no estaba dispuesto a experimentar con Nant 😉 ), pero nuestro caso era diferente, iba a ser en Visual Studio 2012, por lo que se configuro de manera habitual (conexión de Hudson con SVN y configuración del MSBuild), nada fuera de lo habitual excepto que los builds fallaban.
clip_image001
Bueno, el primer error que pude ver en el log era que de alguna manera el MSBuild instalado “no entendia” la nueva versión de archivos .sln de Visual Studio 2012, investigando pude encontrar un caso similar, concretamente cómo hacer para que un Agent de TFS 2008 pudiera ser capaz de compilar soluciones de Visual Studio 2012, la solución que se planteaba era instalar los Agents de Visual Studio 2010, así que por analogía supuse que había que instalar los Agents de Visual Studio 2012 sobre nuestro servidor de integración, y si, eso era… el formato de VS 2012 ahora sí que era entendido por el MSBuil de nuestro Hudson.

Pero a pesar de eso la build seguía fallando, y al revisar nuevamente el log descubrí que era porque no se encontraba el Assembly System.Web.Mvc y otros mas , upss, asi que toco volver a Visual Studio y comprobé que a pesar de que había hecho un “update-package” para actualizar todas las referencias del Nuget (si no sabes de que estoy hablando revisa este interesante articulo) por ahí se me habían colado unas referencias a las librerías instaladas en mi sistema y no a las que estaban en la carpeta “packages” (que como recordaran es gestionada por Nuget), en este caso fue mas

clip_image003

sencillo, borrar las referencias e instalar las referencias en los proyectos respectivos:
En todo caso, la moraleja de esta etapa es “NuGet es tu amigo, si NuGet puede manejarlo, no lo hagas tu a menos de que estés seguro que no puede hacerlo (como puede ser una librería comercial”).
A estas alturas ya estábamos mas confiados en que saldríamos de esta, la build seguía fallando, pero esta vez el mensaje de error se encontraba al final del log:

error MSB4019: The imported project "C:Program Files (x86)MSBuildMicrosoftVisualStudiov11.0WebApplicationsMicrosoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

La búsqueda me derivo a este artículo, que si bien era enfocado a TFS nos daba una sugerencia totalmente valida: copiar esa carpeta de una máquina que tenga una instalación completa de Visual Studio 2012 (recordemos que la idea es nunca tener que instalar todo el VS en el servidor de Integración Continua, solo lo mínimo necesario), se hizo eso y.. listo!

Build succeeded.
    0 Warning(s)
    0 Error(s)
Time Elapsed 00:00:01.41
[DEBUG] Skipping watched dependency update; build not configured with trigger: xxxxxxx #16
Finished: SUCCESS

clip_image004

Bueno problema resuelto, ahora tocara ver que se puede hacer para que compile en el .Net Framework 4.5 ya que cuando coloco uno de los proyectos como 4.5 obtengo este hermoso error…

C:WindowsMicrosoft.NETFrameworkv4.0.30319Microsoft.Common.targets(983,5): warning MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

Espero que les sea de utilidad si por a o b tienen que usar un servidor de IC no hecho en .Net 😉

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.