[# CODEPLEX] Updates for VS11 and TFS11 Integration Platform and MSBuild Extension Pack

image

Buenas,

now that we have automatic updates to the Beta of Visual Studio 11 (pending post), there are already several products that are upgrading their capabilities to be compatible with Visual Studio 11 and Team Foundation 11.

A couple of examples are as follows:

  • TFS Integration Platform, which on 16 March updated its list of controllers to support integration processes also with TFS 11.
  • MSBuild Extension Pack. In this case also include many hotfixs tasks are included to support actions with subversion, etc.

Saludos @ Home

El Bruno

image image image

Sources:

[#CODEPLEX] Actualizaciones para VS11 y TFS11 en Integration Platform y en MSBuild Extension Pack

image

Buenas,

ahora que tenemos actualizaciones automáticas para la Beta de Visual Studio 11 (post pendiente), ya hay varios productos que van actualizando sus capacidades para ser compatibles con Visual Studio 11 y Team Foundation 11.

Un par de ejemplos son los siguientes:

  • TFS Integration Platform, que el 16 de marzo actualizó su lista de controladores para soportar procesos de integración también con TFS 11.
  • MSBuild Extension Pack. En este caso además de incluir muchos hotfixs, se incluyen tareas para soportar acciones con subversion, etc.

Saludos @ Home

El Bruno

image image image

Fuentes:

[TFSINTEGRATION] HowTo: Define custom mappings for the migration between TFS2008 and TFS2010

image47dd1de4

Good,

When you work with tfs integration platform a scenario very likely:

Migrating the contents of a Team Project from Team Foundation Server 2008 at Team Foundation Server 2010.

While the basic concepts of WorkItem Tracking and Source Control remained similar between the two versions, process templates have changed considerably and the migration of WorkItems can bring us some headaches. If them you have customized or extended, so much more. In these cases, we will have to modify the definition of a migration project for it, define custom mappings to solve these cases.

Define a type of different WorkItem

The following Xml defines a configuration where all the elements of the WorkItem Type [Error] will migrate to the WorkItem Type [Bug]. In this mapping the fields of both WorkItem Types must match to run the migration process.

   1: <SettingXml>
   2:   <WITSessionCustomSetting>
   3:     <WorkItemTypes>
   4:       <WorkItemType LeftWorkItemTypeName="Error" RightWorkItemTypeName="Bug" fieldMap="@@ALL@@" />
   5:     </WorkItemTypes>
   6:   </WITSessionCustomSetting>
   7: </SettingXml>
   8: <SettingXmlSchema />

Define a type of different WorkItem with custom fields mapping

The following Xml defines a configuration where all the elements of the WorkItem Type [Error] will migrate to the WorkItem Type [Bug], using a special mapping of fields for different fields in both definitions. In this case the special mapping is called [Error2BugFieldMap] and it defines the names of the fields and the corresponding mappings between them.

   1: <SettingXml>
   2:   <WITSessionCustomSetting>
   3:     <WorkItemTypes>
   4:       <WorkItemType LeftWorkItemTypeName="Error" RightWorkItemTypeName="Bug" fieldMap="Error2BugFieldMap" />
   5:     </WorkItemTypes>
   6:     <FieldMaps>
   7:       <FieldMap name="Error2BugFieldMap">
   8:         <MappedFields>
   9:           <MappedField LeftName="Headline" RightName="System.Title" MapFromSide="Left" valueMap="" />
  10:           <MappedField LeftName="Headline" RightName="System.Title" MapFromSide="Right" valueMap="" />
  11:           <MappedField LeftName="State" RightName="System.State" MapFromSide="Left" valueMap="" />
  12:           <MappedField LeftName="State" RightName="System.State" MapFromSide="Right" valueMap="" />
  13:           <MappedField LeftName="Description" RightName="System.Description" MapFromSide="Left" valueMap="" />
  14:           <MappedField LeftName="Description" RightName="System.Description" MapFromSide="Right" valueMap="" />
  15:         </MappedFields>
  16:       </FieldMap>
  17:     </FieldMaps>
  18:   </WITSessionCustomSetting>
  19: </SettingXml>
  20: <SettingXmlSchema />

Define a custom mapping of fields with different WorkItem type and custom values

The following example extends the previous scenario as for the mapping of fields, also defines a number of dictionaries where are the mappings of values custom among the fields of each type of WorkItem (examples on lines 11 and 19).

   1: <SettingXml>
   2:   <WITSessionCustomSetting>
   3:     <WorkItemTypes>
   4:       <WorkItemType LeftWorkItemTypeName="Error" RightWorkItemTypeName="Bug" fieldMap="Error2BugFieldMap" />
   5:     </WorkItemTypes>
   6:     <FieldMaps>
   7:       <FieldMap name="Error2BugFieldMap">
   8:         <MappedFields>
   9:           <MappedField LeftName="Headline" RightName="System.Title" MapFromSide="Left" valueMap="" />
  10:           <MappedField LeftName="Headline" RightName="System.Title" MapFromSide="Right" valueMap="" />
  11:           <MappedField LeftName="State" RightName="System.State" MapFromSide="Left" valueMap="StateMapCQ2TFS" />
  12:           <MappedField LeftName="State" RightName="System.State" MapFromSide="Right" valueMap="StateMapTFS2CQ" />
  13:           <MappedField LeftName="Description" RightName="System.Description" MapFromSide="Left" valueMap="" />
  14:           <MappedField LeftName="Description" RightName="System.Description" MapFromSide="Right" valueMap="" />
  15:         </MappedFields>
  16:       </FieldMap>
  17:     </FieldMaps>
  18:     <ValueMaps>
  19:       <ValueMap name="StateMapCQ2TFS">
  20:         <Value RightValue="Active" LeftValue="Assigned" />
  21:         <Value RightValue="Active" LeftValue="Duplicate" />
  22:         <Value RightValue="Active" LeftValue="Opened" />
  23:         <Value RightValue="Active" LeftValue="Submitted" />
  24:         <Value RightValue="Resolved" LeftValue="Postponed" />
  25:         <Value RightValue="Resolved" LeftValue="Resolved" />
  26:         <Value RightValue="Closed" LeftValue="Closed" />
  27:       </ValueMap>
  28:       <ValueMap name="StateMapTFS2CQ">
  29:         <Value RightValue="Active" LeftValue="Assigned" />
  30:         <Value RightValue="Resolved" LeftValue="Resolved" />
  31:         <Value RightValue="Closed" LeftValue="Closed" />
  32:       </ValueMap>
  33:
  34:   </WITSessionCustomSetting>
  35: </SettingXml>
  36: <SettingXmlSchema />

I have taken as a reference the examples raised by willy Peter shaub in this post, for the complete migration to TFS2010TFS2008 then consult with the Brunoelements.

Greetings @ Home

The Bruno

   

[TFSINTEGRATION] HowTo: Definir mapeos personalizados para las migraciones entre TFS2008 y TFS2010

image47dd1de4

Buenas,

cuando trabajas con TFS Integration Platform un escenario muy probable es:

Migrar los contenidos de un Team Project desde Team Foundation Server 2008 a Team Foundation Server 2010.

Si bien los conceptos básicos de Source Control y WorkItem Tracking siguen siendo similares entre ambas versiones, las plantillas de proceso han cambiado bastante y la migración de WorkItems puede traernos bastante dolores de cabeza. Si los has personalizado o extendido, pues mucho más. En estos casos, tendremos que modificar la definición de un proyecto de migración para en el mismo, definir mapeos personalizados para dar solución a estos casos.

Definir un tipo de WorkItem diferente

El siguiente Xml define una configuración donde todos los elementos del WorkItem Type [Error] se migrarán al WorkItem Type [Bug]. En este mapeo los campos de ambos WorkItem Types deben coincidir para que funcione el proceso de migración.

   1: <SettingXml>

   2:   <WITSessionCustomSetting>

   3:     <WorkItemTypes>

   4:       <WorkItemType LeftWorkItemTypeName="Error" RightWorkItemTypeName="Bug" fieldMap="@@ALL@@" />

   5:     </WorkItemTypes>

   6:   </WITSessionCustomSetting>

   7: </SettingXml>

   8: <SettingXmlSchema />

 

Definir un tipo de WorkItem diferente con mapeo de campos personalizado

El siguiente Xml define una configuración donde todos los elementos del WorkItem Type [Error] se migrarán al WorkItem Type [Bug], utilizando un mapeo especial de campos para los campos diferentes en ambas definiciones. En este caso el mapeo especial se denomina [Error2BugFieldMap] y en el mismo se definen los nombres de los campos y los mapeos correspondiente entre los mismos.

   1: <SettingXml>

   2:   <WITSessionCustomSetting>

   3:     <WorkItemTypes>

   4:       <WorkItemType LeftWorkItemTypeName="Error" RightWorkItemTypeName="Bug" fieldMap="Error2BugFieldMap" />

   5:     </WorkItemTypes>

   6:     <FieldMaps>

   7:       <FieldMap name="Error2BugFieldMap">

   8:         <MappedFields>

   9:           <MappedField LeftName="Headline" RightName="System.Title" MapFromSide="Left" valueMap="" />

  10:           <MappedField LeftName="Headline" RightName="System.Title" MapFromSide="Right" valueMap="" />

  11:           <MappedField LeftName="State" RightName="System.State" MapFromSide="Left" valueMap="" />

  12:           <MappedField LeftName="State" RightName="System.State" MapFromSide="Right" valueMap="" />

  13:           <MappedField LeftName="Description" RightName="System.Description" MapFromSide="Left" valueMap="" />

  14:           <MappedField LeftName="Description" RightName="System.Description" MapFromSide="Right" valueMap="" />

  15:         </MappedFields>

  16:       </FieldMap>

  17:     </FieldMaps>

  18:   </WITSessionCustomSetting>

  19: </SettingXml>

  20: <SettingXmlSchema />

 

Definir un tipo de WorkItem diferente con mapeo de campos personalizado y valores personalizados

El siguiente ejemplo extiende el escenario anterior ya que para los mapeos de campos, además define una serie de diccionarios donde se realizan los mapeos de los valores personalizados entre los campos de cada tipo de WorkItem (ejemplos en las líneas 11 y 19).

   1: <SettingXml>

   2:   <WITSessionCustomSetting>

   3:     <WorkItemTypes>

   4:       <WorkItemType LeftWorkItemTypeName="Error" RightWorkItemTypeName="Bug" fieldMap="Error2BugFieldMap" />

   5:     </WorkItemTypes>

   6:     <FieldMaps>

   7:       <FieldMap name="Error2BugFieldMap">

   8:         <MappedFields>

   9:           <MappedField LeftName="Headline" RightName="System.Title" MapFromSide="Left" valueMap="" />

  10:           <MappedField LeftName="Headline" RightName="System.Title" MapFromSide="Right" valueMap="" />

  11:           <MappedField LeftName="State" RightName="System.State" MapFromSide="Left" valueMap="StateMapCQ2TFS" />

  12:           <MappedField LeftName="State" RightName="System.State" MapFromSide="Right" valueMap="StateMapTFS2CQ" />

  13:           <MappedField LeftName="Description" RightName="System.Description" MapFromSide="Left" valueMap="" />

  14:           <MappedField LeftName="Description" RightName="System.Description" MapFromSide="Right" valueMap="" />

  15:         </MappedFields>

  16:       </FieldMap>

  17:     </FieldMaps>

  18:     <ValueMaps>

  19:       <ValueMap name="StateMapCQ2TFS">

  20:         <Value RightValue="Active" LeftValue="Assigned" />

  21:         <Value RightValue="Active" LeftValue="Duplicate" />

  22:         <Value RightValue="Active" LeftValue="Opened" />

  23:         <Value RightValue="Active" LeftValue="Submitted" />

  24:         <Value RightValue="Resolved" LeftValue="Postponed" />

  25:         <Value RightValue="Resolved" LeftValue="Resolved" />

  26:         <Value RightValue="Closed" LeftValue="Closed" />

  27:       </ValueMap>

  28:       <ValueMap name="StateMapTFS2CQ">

  29:         <Value RightValue="Active" LeftValue="Assigned" />

  30:         <Value RightValue="Resolved" LeftValue="Resolved" />

  31:         <Value RightValue="Closed" LeftValue="Closed" />

  32:       </ValueMap>

  33:  

  34:   </WITSessionCustomSetting>

  35: </SettingXml>

  36: <SettingXmlSchema />

 

He tomado como referencia los ejemplos que plantea Willy Peter Shaub en este post, para los elementos completos de migracion TFS2008 hacia TFS2010 pues consultar con El Bruno.

 

Saludos @ Home

El Bruno

   

[TFS2010] MOVIENDO/SINCRONIZANDO CONTENIDOS ENTRE DIFERENTES TEAM PROJECTS (II)

image47dd1de4

Buenas,

hace un par de días escribí un post donde comenté como se podía utilizar TFS Integration Platform para sincronizar/mover contenidos entre 2 Team Projects. El ejemplo era bastante simple:

Copiar contenidos desde Tailspin Toys hacia TPA

El resultado fué un éxito (cosa simple cuando hay pocos datos a mover), y el post de hoy aprovecha ese punto de partida para dar solución a otro escenario

¿Qué sucede si se han generado nuevos contenidos o se han modificado contenidos en Tailspin Toys?

Pues la solución es utilizar el mismo proyecto de integración que utilizamos en el post original. Por ejemplo, si analizamos los cambios en los WorkItems podremos ver que el WorkItem 24 ha sufrido algunos cambios en el Team Project de origen:

image

De la misma forma, el archivo de la solución [Tailspin Toys\Development\Iteration 2\TailspinToys.sln] ha sufrido algunas modificaciones en el Team Project de origen:

image

Ahora bien, si lanzamos nuevamente el proyecto de sincronización desde la herramienta de TFS Integration Platform, podremos ver que en el proceso de Discovery > Analysis > Migration, hay nuevos elementos que se migran desde el Team Project de origen al Team Project de destino. De 30/113 elementos iniciales, ahora estamos en 31/121.

image

Si vemos el resultado de la migración, que ahora es más bien sincronización entre Tailspin Toys y TPA, veremos que la solución incluye el último cambio efectuado en el Source Control:

image

y el WorkItem 99 relacionado con el WI 24, tambien ha incorporado los cambios en su histórico:

image

En el próximo post, como utilizar una agenda para tener este proceso “casi automático”.

 

 

Saludos @ Home

El Bruno

   

[TFS2010] Moviendo/sincronizando contenidos entre diferentes Team Projects (I)

image47dd1de4

Buenas,

otro de los temas que surgió en la mesa redonda el miércoles con los chicos de MadridDotNet, estaba relacionado con la necesidad de mover contenidos desde un Team Project hacia otro Team Project. Si bien la plataforma de integración desarrollada por los Visual Studio ALM Rangers: TFS Integration Platform, no resuelve al 100% el problema, si nos permite mover/sincronizar los elementos del Source Control y los WorkItems entre 2 TPs.

En el siguiente paso a paso, demostraré como sincronizar los contenidos del Team Project [Tailspin Toys] que viene de ejemplo en las máquinas virtuales de Trial de Team Foundation Server 2010 hacia otro Team Project llamado [TPA].

Tutorial

1. Descargamos e instalamos la última versión de TFS Integration Platform desde CodePlex

2. Lanzamos la aplicación [TFS Integration]

image

3. Creamos un nuevo proyecto de integración seleccionado la opción [Create New]

4. Entre las plantillas de proyecto, ubicadas en

[%Program Files%\Microsoft Team Foundation Server Integration Tools\Configurations\Team Foundation Server]

seleccionamos [VersionControlAndWorkItemTracking.xml] que nos permitirá sincronizar contenidos del Source Control y WorkItems.

5. En este momento podremos ver en el formulario de configuración del proyecto que debemos completar los siguientes elementos:

  • Nombre del proyecto
  • Tipo de sincronización
  • Origen del Source Control
  • Destino del Source Control
  • Origen de los WorkItems
  • Destino de los WorkItems

6. Para este post, he definido el nombre como “Post01” y el tipo de sincronización como “One-way migration”.

7. En la sección [Version Control Selection // Left Source] seleccionamos el proveedor para conectarnos con TFS2010.

image

8. Seleccionamos el Team Project [Tailspin Toys] desde la colección correspondiente:

image

9. En la sección [Version Control Selection // Right Source] seleccionamos el proveedor para conectarnos con TFS2010 y a continuación el Team Project [TPA].

10. En este punto podemos definir los elementos del Source Control que queremos sincronizar desde un TP a otro. En este caso moveremos todo el contenido del Left Source en [Tailspin Toys] hacia una rama llamada [TfsSync] en el Team Project [TPA].

Seleccionamos esta rama:

image 

11. El mapeo del source control debería quedar similar a la siguiente imagen:

image

12. A continuación definiremos las opciones para la migración de WorkItems. En la sección [WorkItem Tracking Section // Left Source] seleccionamos el proveedor para TFS2010 y seleccionamos el Team Project [Tailspin Toys].

13. En la sección [WorkItem Tracking Section // Right Source] seleccionamos el proveedor para TFS2010 y seleccionamos el Team Project [TPA].

14. La configuración debe quedar similar a la siguiente imagen:

image

15. En la sección queries podemos definir un filtro específico para definir los WorkItems que deseamos sincronizar. Para este ejemplo, utilizaremos la opción por defecto que migra todos los elementos entre los 2 Team Projects.

16. Guardamos la configuración en la base de datos.

17. Lanzamos la sincronización con la opción [Current Migration // Start]. Esta opción nos muestra el formulario de sincronización, en el que podremos ver el progreso de la misma. Por ejemplo:

image

18. Una vez que se han descubierto los elementos a migrar, se procede a analizar el contenido de los mismos para ver si existe algún error potencial:

image

19. Finalizados los procesos de Discovery y Analysis, se procede a la migración:

image

20. Una vez finalizada la migración, podremos ver el resultado  la misma. En este punto es recomendable ver el Log de migración para comprender mejor el detalle de lo que realiza la herramienta.

image

21. Si dentro del Team Project [TPA] vemos el contenido del Source Control, veremos que se han importado los elementos desde el otro Team Project.

image

22. En el histórico de un elemento, podremos ver que se han replicado los elementos del histórico original del Team Project de origen y además en el comentario, se ha agregado información del proceso de migración/sincronización.

image

23. De la misma forma, si analizamos los WorkItems migrados, podremos ver que en el histórico de los mismos aparece la información histórica de los WI originales. En este caso, la User Story 99 del Team Project [TPA], se corresponde con el WorkItem 24 del Team Project [Tailspin Toys]. En el histórico podremos ver la referencia entre los mismos.

image

Hasta aquí un pequeño tutorial para la sincronización de datos entre 2 TPs, en el próximo post un poco más de información al respecto.

 

Saludos @ Home

El Bruno

   

[TFS2010] HOWTO: SINCRONIZAR CONTENIDOS DESDE SUBVERSION HACIA TFS2010 [II]

image47dd1de4

Buenas,

ayer escribí un post sobre como montar un escenario para sincronizar contenidos desde un repositorio de SubVersion hacia un repositorio de Team Foundation Server 2010.

Un punto interesante de la herramienta de sincronización, es que en estos cass y con un proceso de sincronización ya definido, existen unos baselines sobre los que la misma puede continuar con la sincronización y solo aplicar los cambios desde la última sincronización.

Por ejemplo, si vemos el log de un archivo del repositorio de SubVersion, podremos ver que en el mismo se han producido un par de cambios en el día de hoy.

image

 

Si lanzamos el proceso de migración desde la herramienta de TFS Integration Platform, veremos que en la misma solo se aplican los cambios en el histórico de acciones. Estos cambios se corresponden con los únicos cambios detectados desde la última sincronización.

image

 

Finalmente si accedemos al histórico de TFS2010, también podremos ver como se han sincronizado estos cambios de manera correcta.

image

 

Saludos @ Home

El Bruno

   

[TFS2010] HowTo: Sincronizar contenidos desde SubVersion hacia TFS2010 [I]

image47dd1de4

Buenas,

después de mi pequeño post de hace 2 días:

[TFS2010] HowTo: Exportar el contenido completo de un repositorio de SubVersion a otro repositorio de Subversion

hoy mostraré un pequeño tutorial para mostrar como importar al source control de Team Foundation 2010 el contenido de un repositorio de SubVersion. Para esto utilizaremos las herramientas de integratión de TFS Integration Platform.

Tutorial

1. En primer lugar, debemos instalar las herramientas de integración. Es importante seleccionar el adaptador de SubVersion (en estado Alpha), para que tengamos acceso al mismo al momento de realizar la migración.

image

Actualmente se pueden descargar desde http://tfsintegration.codeplex.com/releases/view/35476

2. El instalador requiere de una instancia de SQL Server para guardar las definiciones de integración y el progreso de los mismos. Si no tienes un SQL Server a mano, puedes instalar y utilizar la versión Express de SQL Server. http://www.microsoft.com/downloads/es-es/details.aspx?FamilyID=58CE885D-508B-45C8-9FD3-118EDD8E6FFF

3. La plataforma de integración cuenta con una herramienta que visualmente nos permite definir los procesos de migración o integración. Lanzamos la misma y creamos un nuevo proyecto desde el menú [Configuration // Create New].

4. La creación de un nuevo proyecto requiere una plantilla inicial, seleccionamos el archivo [C:\Program Files\Microsoft Team Foundation Server Integration Tools\Configurations\Subversion\Subversion_to_TFS.xml] para crear el nuevo proyecto. En este punto podremos ver el formulario de configuración del proceso de migración. Pera este ejemplo el nombre del proceso será [Subversion to TFS 2010 23]

image

 

5. Editamos la opción [Left Source] y en la misma configuramos los datos de acceso a nuestro repositorio de SubVersion. Para este ejemplo, utilizo el acceso por file system, pero puede realizarse por cualquiera de los protocolos que soporta SubVersion.

image

 

6. Configuramos el acceso al servidor Team Foundation Server 2010 en la sección [Right Source].

7. En este punto podemos acceder a paths específicos de ambos repositorios para identificar directorios a migrar.

image

 

7. Si bien la opción para la selección de subdirectorios funciona correctamente en el editor, me he encontrado problemas seleccionado subdirectorios en SubVersion al momento de migrarlos. Con la selección de carpetas de TFS 2010 no hay problema, funciona correctamente.

image

 

8. Guardamos la configuración [Save To Database]

9. Lanzamos el proceso de sincronización a través del menú [Current Migration // Start]. Dependiendo de la cantidad de elementos a migrar, este proceso puede tardar bastante (incluso días).

10. Una vez terminado podremos ver el proceso completo como muestra la siguiente imagen:

image

 

Cada una de las acciones realizadas se detalla en el gráfico historico que se muestra en la sección inferior. La siguiente imagen muestra el detalle de la 5ta revisión procesada, con la cantidad de archivos y comentario relacionados a la misma.

image

 

11. Si accedemos al histórico de algún elemento en el repositorio de subVersion podremos ver si histórico de la siguiente forma (gracias a TortoiseSvn)

image

 

Si analizamos la misma información en el histórico del Source Control de TFS2010, veremos que la información es la misma. Y a cada elemento del histórico se le ha agregado un sufijo especificando el origen desde un proceso de TFS Integration Platform.

image

En el próximo post, como actualizar los datos “en caliente” hacia Team Foundation Server 2010 cuando se ha seguido trabajando con SubVersion.

 

 

Saludos @ Home

El Bruno