Códigos De Etiquetas De Microsoft Dynamics AX 2012 Usando Ramas De Team Foundation Server (ALM-VIII)

  • Fri, Nov 20, 2015
  • 3-minute read
!
Warning: This post is over 365 days old. The information may be out of date.

Felizmente para nosotros, la integración de etiquetas con TFS en Microsoft Dynamics AX 2012 ha mejorado muchísimo hasta hacerla casi transparente, lo que es una mejora notable respecto a versiones anteriores. Cuando creamos una etiqueta en una instancia de AX gestionada por TFS, se crea un código de etiqueta personal que es único sólo en esa instancia (en la forma @$XXX).

Lo único a tener en cuenta es que en el momento de hacer check-in debemos incluir tanto el objeto donde se utiliza la etiqueta temporal, como el propio fichero de etiquetas donde este código ha sido creado. En este momento, la integración con TFS detecta el código temporal y lo sustituye por un código definitivo coherente con la versión del fichero de etiquetas en el servidor.

Hasta aquí todo correcto, pero la cosa se complica cuando utilizamos ramas de TFS, ya que al hacer check-in a la rama la versión del servidor puede que no sea una versión integrada para todos los desarrolladores, por ejemplo si utilizamos un modelo de rama por desarrollador como comentamos en el artículo anterior. La solución en este caso es indicar a nuestro AX que utilice un rango determinado de etiquetas por cada rama, para asegurarnos que no va a haber conflictos con estos códigos a la hora de hacer el merge hacia el repositorio consolidado.

Por ejemplo, en la captura le decimos que utilice el rango 2XXX en esta instancia de AX. El problema es que este cambio en la configuración genera un cambio pendiente del objeto VCSDef.xml que debemos resolver de alguna forma. Podemos dejarlo como cambio pendiente para siempre, pero lo ideal es quitarlo de ahí para que no moleste lo que desde AX sólo podemos hacer confirmándolo con un check-in o descartándolo con un deshacer, lo que volverá el fichero a su estado anterior revertiendo el cambio que acabamos de hacer.

Ninguna de estas soluciones nos sirve.

Por suerte Palle Agermark encontró una tercera opción muy sencilla y disponible a través de la consola de comandos de Visual Studio que nos permite eliminar un cambio pendiente sin confirmarlo ni deshacerlo. La sintaxis completa del comando la tenemos en está página de MSDN y la consola de Visual Studio se puede localizar fácilmente utilizando la búsqueda de Windows.

Resumiendo mucho, podemos usar un comando parecido al siguiente para detectar cambios pendientes entre ramas:

tf merge /candidate BRANCH-ORIGEN BRANCH-DESTINO /recursive

Por ejemplo:

tf merge /candidate Development/JoseAntonio Main /recursive

Podemos especificar un change set en concreto, pero como en mi caso sólo tengo este caso pendiente puedo cancelarlo de forma general de esta forma:

tf merge /candidate Development/JoseAntonio Main /discard /recursive

Esto genera a su vez otro cambio pendiente, pero este sí lo debemos confirmar con un check-in para hacer desaparecer definitivamente nuestro cambio pendiente indeseado.

Y de esta forma la herramienta de MERGE no encuentra cambios pendientes nunca más:

Este proceso habrá que repetirlo en todos los entornos de desarrollo, asignando rangos diferentes de etiquetas por desarrollador, dependiendo de nuestra estrategia de ramas, para que cada rama ofrezca códigos de etiquetas que no se van a repetir cuando se consoliden los cambios en la rama principal ya que siempre serán números diferentes y este caso se resuelve automáticamente por TFS.

Atentos porque en el próximo capítulo empezamos con los procesos build! :)

Posts in this series

Spanish ALMDevOpsDynamics AX