Laboratorios Virtuales de Team System

Les dejo aquí la liga de los laboratorios virtuales de Team System, esto también les puede ser de mucha utilidad para entender mejor el funcionamiento del Team System, y sus distintas aplicaciones, los recomiendo ampliamente.

http://msdn.microsoft.com/virtuallabs/teamsystem/

Saludos y espero esto les sea de mucha utilidad!

TFS virtual

Si estas buscando hacer alguna prueba de TFS, te recomiendo correr una maquina virtual que Microsoft ofrece de manera gratuita, esto si no quieres tratar con la version Trial del TFS de 180 días, tu puedes descargar la maquina virtual desde el sitio de MSDN subscriber.

Esta maquina virtual es de Team Foundation Server beta 3 en instalación single.

Liga:
http://msdn2.microsoft.com/en-us/subscriptions/default.aspx

Contenido:
http://blogs.msdn.com/buckh/archive/2005/11/22/495875.aspx


Espero esto les sea útil!

Visual Studio Team System level 200

Para la gente que se inicia en el mundo de Team System les recomiendo empezar con los webcast del VSTS 200, aqui les dejo la liga de donde pueden descargar los webcast del nivel 200, estan muy interesantes, también les dejo las maquinas virtuales del VSTS 200, espero les sea de gran utilidad.

Webcasts


Curso de VSTS 200 con VPC

Saludos!

TfsDelete usado en proyectos corruptos

Hola como están, aquí les dejo mi experiencia con ciertos problemas al borrar proyectos corruptos.

Hace tiempo tuve un escenario muy complicado en su tiempo, realizamos una migración de la versión RC a la versión Refresh 3, y todo iba bien, todo parecía estar en orden, pero al primer proyecto que tratamos de generar vinieron los errores, nos desplegaba ciertos errores al generarlo y va, el proyecto nunca parecía en Team Explorer, esto se no hizo un poco extraño pero decidimos continuar con pruebas, revisamos el Log de el error del la creación del proyecto y nos dimos cuenta que el error estaba en nuestro Process Template, pues bien a modificarlo, y a prueba y error, generamos una serie de proyectos prueba, hasta que dimos con el problema, el problema que se nos presento después fue el borrar los proyecto que generamos de prueba, y bien aplicamos el proceso simple con el comando TfsDelete

TFSDeleteproject [/q] [/TeamFoundationServer:servername] [/force] project name


Recibimos una gran sorpresa, al correr el comando nos desplegaba que el proyecto no existía, y va la revisión de todo a fondo, en aquel tiempo no existía casi nada de información sobre el tema Team System, después de un buen tiempo revisando todo paso a paso la operación que realizaa el Team Foundation Server cuando genera un proyecto, entendimos lo que teniamos que hacer para eliminar esos poryectos corruptos, y bien les dejo aquí nuestros pasos.

1.- Entrar a la base de datos del Team Foundation server(SQL) posteriormente entrar a la base llamada TfsIntegration, después seleccionamos la tabla de "tbl_Projects" en esta veremos el nombre del proyecto, el id, y el estatus, cuando un proyecto se genera de forma corrupta no marcara como estatus "New" este estatus lo tenemos que cambiar por "WellFormed" manualmente y cerramos la tabla.

2.-La segundo cosa de hacer es conectarnos ahora a nuestro reporting services, dentro de este seleccionamos la carpeta de HOME, ya dentro de esta debemos de generar el sitio del proyecto manualmente .

3.-Ahora abrimos nuestro Visual Studio, y debemos de ver en Team Explorer que ya podemos agregar el proyecto creado corruptamente.

4.-Ahora dentro de Source Control damos un Get Lastest Version y nos debe de aparecer el proyecto dentro del Source Control Explorer.

5.- Ya como punto final y no por esto el más simple, aplicamos desde la ventana de comandos el comando TfsDelete y listo ahora si nos dejara eliminar el proyecto.

Espero esto les sea de utilidad!

Check Out en Team System

Check out en Team System

Este post esta básado y contiene textos e imagenes directamente tomados del artículo Check Out in Team System de Martin Woodward, publicado bajo licencia Creative Commons. Todos los textos en cursiva han sido 'directamente' traducidos del artículo anteriormente citado las partes que no están en cursiva son de mi cosecha. Una vez aclarado esto, vayamos al grano...

Cada vez más gente me está preguntando ¿por qué TFS cuando hace check out, no obtiene la última versión?.

El problema es que la terminología empleada varia dependiendo de cual sea el gestor de fuentes del que vienes. En Visual Source Safe o PVCS, Check Out significa "dame la ultima versión del archivo y bloqueale para que ningún otro pueda editarlo". En CVS y Subversion, Check Out significa "dame la última versión". Si estas usando las caracteristicas de control de código fuente de Team System, entonces, Check Out significa "dile al servidor que yo quiero editar este archivo y marca el archivo como escribible en mi sistema de archivos", al mismo tiempo que tu haces Check Out del archivo tambien tiene la opción de bloquerlo usando uno de tres tipos de bloque existente (none, Check Out o Check In).

Team System tiene el concepto de Workspaces. El servidor conoces tu Workspace, conoce que directorios locales has mapeado en que Workspace, que versiones de los archivos tienes en este Workspace y de que cambios pendientes has informado al servidor. Para obtener la última versión de un archivo, debes llamar explicitamente al comando Get Latest para descargar los archivos. Si alguien crea una nueva versión de un archivo, no lo verás en tu sistema local de archivos hasta que vuelvas ha ejecutar Get Latest otra vez. Y no esto no se puede cambiar, ni siquiera usando Check Outs exclusivos.

Cuando hace Check Out de un archivo, lo que realmente estás diciendo es "Servidor, estoy a punto de editar la versión 3 del archivo"

Finalmente, cuando haces Check In del archivo, coges el archivo desde tu Workspace local y le pasas hasta el servidor. Este archivo ahora se convierte en la última versión.

Ahora, imagina que no has optenido la última versión antes de hacer el Check Out. Cuando haces el Check In, el servidor sabe que los cambios fueron hechos en la versión 1 del archivo, por eso te avisa de que es un cambio conflictivo y te pide que resuelvas estos conflictos antes de hacer Check In en este archivo.

¿Por qué no simplemente obtener la última versión cuando tu hace Check Out de un archivo? El problema con este enfoque es que si obtuviesemos la última versión podríamos intruducir nuevas dependencias repecto a archivos que aun no tenemos. Team System opta por el enfoque más seguro y optiene el archivo solo cuando se lo pedimos.

Hasta aqúi las partes relevantes de como funciona el tema. Pero yo voy a ir un paso más allá que el amigo Martin Woodward, explicando que significa eso de "introducir nuevas dependendias". El problema es que cuando hacer Check Out implica obtener la última versión, nosotros perdemos el control de que es lo que realmente obtenemos. Se puede dar el caso de que simplemente para hacer una edición menor en un archivo, por ejemplo para hacer un Workarraound temporal para poder continuar con una pequeña tarea, no tengamos que bajar infinidad de ficheros solo para poder compilar. Si el archivo del que hacemos obtenemos la última versión cambio mucho, y por ejemplo, llama a nuevas partes del código que a nosotros no nos interesan, el obligar la obtencion de la última versión no obliga a bajar un motón de código que no es relevante para nuestra tarea actual.

La manera de trabajar en Team System tambien soporta algunas técnicas avanzadas de gestión de código que son dificiles de llevar a cabo con otros gestores de fuentes, como por ejemplo Golden Lines o Quality Gates, en las que puede que tu no tengas permiso para integrar código, que las integraciones de nuevo código solo se hagan en un determinado momento fijado en el tiempo o que el desarrolador ni siquiera sea quien puede integrar ese código, sino que hay un equipo exclusivamente encargado de la integración. Resumiendo hay patrones de gestión de código fuente que son dificiles o imposibles de llevar a cabo si se realiza la obtención de la última versión en el momento de realizar el Check Out.

En VSS y otros gestores que implementan el enfoque de obtener última versión al hacer Check Out, esto se solucionaba, quitando 'a manopla' el atributo de solo lectura al proyecto, lo que de todos modos te llevaba a tener que corregir una incosistencia.

Eso si, he de reconocer que este escenario no es habitual, y que no acaba de convencerme al 100% el enfoque que han elegido en Team System, sobre todo por una cuestión: se separa de el enfoque al que estamos acostumbrados. Seria simple haber puesto una opción que permitiese variar el comportamiento. Parece que esta posibilidad la introduciran en proximas revisiones/versiones de Team System, puesto que de hecho el Visual Studio 2005 Team Foundation Server MSSCCI Provider (que se usa para acceder al gestor de fuentes de TFS desde Visual Studio 2003, PowerBuilder, VB 6.0 etc...) ya soporta "GetLatest on Checkout support".

De todos modos existen algunos 'workarrounds' que nos pueden ayudar. Por ejemplo podemos añadir una macro de Visual Studio para que cuando abramos un fichero que es de solo lectura (y por tanto, es probable que este en el gestor de fuentes) se obtenga su última versión. Para ello solo tenemos que hacer Alt + F11 en visual estudio, y añadir en el archivo EnviromentEvents, dentro del modulo EnviromentEvents el siguiente código:

Public Sub DocumentEvents_DocumentOpening(ByVal DocumentPath As String ByVal Read_Only As Boolean) Handles DocumentEvents.DocumentOpening

Dim attr As IO.FileAttributes
attr = IO.File.GetAttributes(DocumentPath)
If (attr.ReadOnly) Then
DTE.ExecuteCommand("File.TfsGetLatestVersion")
End If

End Sub

Otra opción es hacer una macro similar que podemos asociar a un menu o a un botón que, nos permita de manera simultanea optener la última versión y hacer Check Out:

Sub CheckoutLatest()

DTE.ExecuteCommand("File.TfsGetLatestVersion")
DTE.ExecuteCommand("File.TfsCheckOut")

End Sub

Team Foundation Server on 64 bits

Hola como están todos, pues la primer publicación de este blog :)

Por primera vez yo creo que sera conveniente tomar un buen tema de inicio, me he topado con muchas preguntas sobre si es posible instalar nuestro Team Foundation Server en 64bits.

Les dejo unas notas interesantes sobre el Tema

What is supported at RTM Team Foundation Server?

You can install the Team Foundation data tier in a dual-server deployment on a Windows 64-bit operating system that is running a 64-bit edition of SQL Server 2005. Since the Team Foundation data tier is hosted by SQL Server, it will run natively on a Windows 64-bit operating system.
You can install Visual Studio 2005 and Team Foundation Build on a Windows 64-bit operating system; both will run under WOW64.
You must install Team Foundation Server application tier, including Team Foundation Server Proxy, on a 32-bit edition of Windows Server 2003.

64 Bits Support

Cómo muchos sabrán encontrarnos con equipos de 64 bits en las empresas se ha vuelto común y existen muchas herramientas de 32 bits, una de esas es el Team Foundation Server, hace días atrás tuve que montar un ambiente de desarrollo en equipos de 64 bits, muchos preferirían instalar Windows 32 bits y así evitarse algunos problemitas que se puede encontrar al momento de montar aplicaciones que vienen en 32 en sistemas operativos de 64 bits, pero no estaríamos aprovechando el potencial que nos brindan estos esquipos, por tal razón windows server 2003 tiene un subsistema llamado WOW el cual permite correr aplicaciones de 32bits sobre este windows de 64 bits, es por esto que esta es una muy pequeña pero elemental guía de cómo montar nuestros ambientes de desarrollo sobre estos servidores (El deploy que se hizo fue en un single server):

1. En la capa de datos, pues la instalación para SQL Server 2005 es la típica si montamos SQL Server 2005 64 bits.

2. Al momento de instalar Sharepoint deben seguir la siguientes recomendaciones:
Al momento de instalar el Internet Information Server (IIS) en un equipo que ejecuta edición de Windows Server 2003 x 64, se debe configurar IIS para ejecutarse en modo de emulación de 32 bits. Para ello, siga estos pasos en cada servidor Web de servicio de fondo que ejecuta edición de Windows Server 2003 x 64:

a. Haga clic en Inicio, haga clic en Ejecutar, escriba cmd y a continuación, haga clic en Aceptar.

b. En el símbolo del sistema, mueva carpeta \Inetpub\Adminscripts al %drive%. Tenga en cuenta que aquel %drive% es la unidad en la que está instalado Windows Server 2003.

c. En la carpeta Adminscripts, escriba el comando siguiente y a continuación, presione ENTRAR:
Adsutil.vbs cscript estableció w3svc/AppPools/Enable32bitAppOnWin64 1
Nota El valor "1" para Enable32bitAppOnWin64 especifica modo de 32 bits. El valor "0" especifica modo de 64 bits.

d. Escriba iisreset y a continuación, presione ENTRAR.

e. Cierre la ventana de Símbolo del sistema.

f. Instalar WSS SP 2

3. Y por último la siguiente recomendación al momento de instalar el TFS les recomiendo revisar el blog de Rob Caron:
http://blogs.msdn.com/robcaron/archive/2005/10/28/486302.aspx

Espero les sirva de utilidad.