Control del código fuente con TFS en Microsoft Dynamics AX 2012 (ALM-VI)

En anteriores capítulos de esta serie ya hablamos de cómo instalar y/o configurar nuestra instancia de Microsoft Team Foundation Server, y también sobre cómo usarlo para gestionar nuestras tareas y requerimientos. Este artículo es la última parte acerca de la funcionalidad básica de la integración entre Microsoft Dynamics AX 2012 y TFS, para poder empezar en los siguientes post con temas más avanzados.

En este artículo veremos como trabajar con TFS para la gestión de versiones del código fuente (VCS), que es el primer paso para poder utilizar las funcionalidades más avanzadas del sistema en cuanto a sus capacidades de ALM. Básicamente, el control de versiones pretende que cualquier cambio realizado sobre los objetos del sistema quede registrado, así como la fecha, el autor de dichos cambios, qué otros objetos se modificaron a la vez y por qué (mediante los comentarios en durante el check-in).

Esto nos permite revertir los cambios, volver a una versión anterior, comparar el estado actual de un objeto con una versión anterior, revisar los cambios realizados un determinado día por un desarrollador (para realizar revisiones de código), asociar los cambios a una determinada tarea para ver todos los cambios que ha requerido finalizarla, y un largo etcétera.

Las tres operaciones más evidentes que requiere cualquier control de versiones son: añadir nuevos objetos, check-in y check-out (traducidas en AX como Proteger y Desproteger respectivamente) y Sincronizar.

Agregar nuevos objetos

En Microsoft Dynamics AX no se añade todo el código al gestor de código fuente, al contrario que en otros VCS. No tendría sentido añadir todos los objetos que forman parte de la aplicación estándar ya que esto supondría un desperdicio notable de recursos. Por eso, sólo se añaden los objetos nuevos o aquellos objetos estándar que se han modificado, suponiendo que si un objeto no está controlado por el control de versiones es que es un objeto estándar que nunca ha sido modificado. En resumen, se añaden todos los objetos que no forman parte de las capas o modelos del sistema.

Para añadir un objeto al gestor de código fuente, TFS en este caso, se hace botón derecho sobre el mismo y Añadir al control de versión. Es importante recordar esta operación ya que no se realiza automáticamente. Si un objeto no se agrega al control de código, provocará errores e incoherencias cuando otros desarrolladores sincronicen nuestros cambios y no obtengan todos los objetos, por lo que es muy importante hacer de esta tarea un hábito y añadir los objetos a TFS cuanto antes, a ser posible justo después de crearlos, para no olvidarlo.

AX2012 vs TFS - Añadir a control de versión

Como se puede ver en la imagen anterior, los proyectos de MorphX también se consideran objetos y, por tanto, hay que agregarlos manualmente. No es recomendable añadir proyectos privados al control de versiones. En cualquier caso, dejarían de ser privados en TFS, donde se almacenarían como un objeto más.

Check-Out (Desproteger)

Cuando necesitemos modificar un objeto existente que está gestionado por el control de versiones, antes debemos desprotegerlo para que se permita su edición. Si en algún momento nos damos cuenta de que las opciones para editar un objeto (por ejemplo la opción de Eliminar o Duplicar en el menú contextual) han desaparecido, probablemente es debido a que el objeto está protegido y no permite ser editado hasta que no se le haga un check-out. El editor de X++ aparece sombreado en color gris en este caso, y desde el propio editor podemos hacer check-out del objeto mediante los botones a tal efecto situados en la barra de acciones del editor.

AX2012 vs TFS - Editor de código X++

Cuando utilizamos la opción Proteger obre un objeto, un mensaje del InfoLog nos avisa de que el objeto esta disponible para ser editado, y que éste se ha añadido a la lista de cambios pendientes del control de versiones. Desde este momento podremos realizar cambios libremente sobre el mismo, cambios que no se aplicarán al control de versiones hasta que no utilicemos la acción inversa: check-in.

Los objetos desprotegidos se muestran de un color diferente en el AOT, salvo que se configure específicamente de otra forma en los parámetros del control de versiones:

AX2012 vs TFS - AOT

Si después de desproteger y modificar un objeto decidimos que estos cambios ya no son necesarios, podemos utilizar sobre el la acción Deshacer desprotección (llamado en Visual Studio: Undo Pending Changes) para devolver el objeto a la versión almacenada en el servidor, deshaciendo cualquier cambio que hayamos hecho desde entonces y dejando el objeto protegido de nuevo.

Check-In (Proteger)

Cuando hemos terminado de modificar un objeto y queremos guardar estos cambios en el control de versiones, de forma que otros desarrolladores puedan recibir este cambio durante la sincronización, promover el cambio entre ramas, que este cambio pase a formar parte de la siguiente build, etc. (hablaremos de estas cosas en los siguientes capítulos), debemos realizar la acción inversa: Proteger el objeto, o hacer check-in.

En el diálogo de check-in, podemos decidir qué objetos queremos proteger. Todos los objetos protegidos que seleccionemos ahora formarán parte de un conjunto de cambios (change set) en TFS que podremos consultar en cualquier momento. Los veremos a continuación. También es muy recomendable incluir un comentario que indique el motivo de los cambios, que será almacenado en el conjunto de cambios de TFS y será muy útil en el futuro para comprender por qué se realizó un cambio en un momento dado.

Este conjunto de cambios puede asociarse con uno o varios elementos de trabajo en TFS (que pueden ser tareas, bugs, User Stories, etc.) mediante la pestaña Artículos de trabajo (una traducción poco afortunada de Work Items), de forma que podamos consultar todos los cambios que han sido necesarios para realizar una determinada tarea, la fecha, el programador que los hizo, la versión en la que fueron incluidas en el entorno de producción, etc.

AX2012 vs TFS - Asociar elementos de trabajo a un check-in

Este formulario es bastante simple de manera estándar. Demasiado simple para una utilización constante, diría yo. Pero como ya expliqué en un post anterior, se pueden modificar. Por ejemplo, en mi equipo hemos decidido que un conjunto de cambios esté asociado siempre y obligatoriamente a un work item, y sólo a uno. Para asegurar esta política, hemos añadido validaciones al formulario y, para hacerlo más usable, también hemos añadido algunos controles para filtrar por usuario y mostrar u ocultar los elementos de trabajo cerrados, cosa que empieza a ser obligatoria cuando llevas un tiempo utilizando este sistema.

Si te parece buena idea, echa un vistazo a la clase SysVersionControlWorkItemProviderTFS y el formulario SysVersionControlCheckIn y en los blogs de la comunidad, donde se han publicado otras opciones 🙂

Cuando comentábamos la configuración del VCS en MorphX en capítulos anteriores, vimos que se pueden configurar limitaciones a los cambios que TFS va a aceptar como válidos. Es muy común prohibir ciertos tipos de objetos (por ejemplo Jobs en entornos de producción, o elementos web si no utilizamos Enterprise Portal) o ciertos nombres de objeto (como los nombres por defecto como Table1CopyOfXXX). En el caso de que alguno de nuestros cambios no satisfaga esas limitaciones, obtendremos un error que cancelará el check-in:

AX2012 vs TFS - Checks durante el check-in

Estas son las opciones básicas que nos ofrece cualquier control de versiones para manejar el código. Son tareas que cualquier desarrollador realiza varias veces al día y que, llegado el momento, se realizan sin pensar, forman parte de la rutina de trabajo. Podríamos decir que solamente con esto ya tendríamos una gran ventaja respecto a no llevar ningún control sobre nuestros cambios.

Sin embargo, lo normal es que queramos sacarle más rendimiento a este sistema. A continuación comentamos las opciones más comunes que podemos realizar en MorphX:

Sincronizar

Según la configuración soportada por Microsoft para utilizar TFS con Microsoft Dynamics AX, cada desarrollador debe realizar su trabajo en un entorno de trabajo aislado del resto. En su propio servidor, sin compartir AOS ni bases de datos. Esto tiene muchas ventajas que no comentaremos ahora, muchas de ellas evidentes, pero nos deja en la situación de pensar cómo obtenemos el trabajo que otros desarrolladores están realizando en sus propios servidores.

Puesto que estos cambios se almacenan en TFS, disponemos de la opción Control de la versión > Sincronizar que descarga del control de versiones e importa en AX todos los conjuntos de cambios que no hayamos hecho nosotros mismos, sincronizando los conjuntos de cambios con los del servidor.

Si marcamos la opción Forzar de este formulario (como vimos en el capítulo IV de esta serie), descargaremos la última versión de todos los objetos que hayan sido modificados en la aplicación. Esta opción es muy útil la primera vez que empezamos a utilizar un entorno de desarrollo para una determinada aplicación (o cliente), pero es un proceso largo que requiere compilar, sincronizar la base de datos, etc.

Si no marcamos esta opción, sólo descargaremos los conjuntos de cambios realizados tras la última sincronización. Este proceso será, lógicamente, mucho más rápido, por lo que podemos realizarlo a menudo para estar seguros de que trabajamos con la última versión de los objetos, incluyendo cambios que no hayamos realizados nosotros mismos.

Podemos también obtener la última versión (el equivalente a Sincronizar) de un sólo objeto si hacemos click derecho sobre el y elegimos Obtener más reciente.

Cambios pendientes

Cuando llevamos un tiempo trabajando en un desarrollo grande, es posible perder la cuenta de cuántos objetos hemos modificado, o de si alguno no está incluido en nuestros proyectos. Para facilitarnos esta tarea disponemos de la opción Control de la versión > Objetos pendientes, que nos muestra todos los objetos que hemos modificado y todavía no han sido protegidos.

AX2012 vs TFS - Cambios pendientes

Desde esta ventana podemos realizar diversas acciones con estos objetos modificados, como iniciar un check-in o deshacer la desprotección, si algún objeto está desprotegido por error. Pero la más interesante es la posibilidad de crear un proyecto que incluya todos estos objetos.

La opción Importar volverá a importar en nuestra instancia de AX los ficheros XPO almacenados en el repositorio local de TFS en este equipo. Esta opción tiene unos usos muy limitados por lo que no entraremos en detalle ahora mismo.

Conjuntos de cambios

Ya hemos comentado que cualquier check-in se asocia a un conjunto de cambios que se almacena en TFS. Estos conjuntos de cambios pueden consultarse desde Visual Studio (desde el Source Control Explorer en la ventana Team Explorer) y desde la web de nuestro TFS (en Código > Conjuntos de cambios, dentro de nuestro proyecto) o desde Visual Studio Online. Sin embargo para nosotros es mucho más cómodo consultarlos directamente desde el entorno de desarrollo de Microsoft Dynamics AX 2012, en Control de la versión > Cambios:

Desde este formulario podemos ver todos los conjuntos de cambios registrados en nuestro TFS. Puede que algunos los hayamos realizados nosotros mismos, o bien podemos haberlos recibido durante un proceso de sincronización. Seleccionando uno de estos conjuntos de cambios, podemos ver su contenido mediante el botón del formulario, que nos presentará todos los objetos que se incluyeron en el correspondiente check-in, así como la fecha, hora y usuario que lo realizó, y el comentario incluido durante el check-in.

Desde el formulario que nos muestra el contenido podemos Obtener alguno de los objetos (lo que sobrescribirá la versión actual en nuestro sistema con la versión del conjunto de cambios, descargada de TFS), ver el Historial de cambios de ese objetos, Comparar la versión del conjunto de cambios con otras versiones (para comprobar en detalle los cambios), o abrirlo directamente en una ventana del AOT.

Historial

La ventana Historial que acabamos de comentar también puede invocarse al hacer click derecho sobre cualquier objeto en el AOT que esté gestionado por el control de versiones. También nos muestra una lista de conjunto de cambios pero en este caso centrada en el objeto seleccionado, mostrando todos los cambios que un determinado objeto ha sufrido, las acciones realizadas sobre el, fecha y hora, etc., e incluso detectar para qué tareas ha sido necesario modificarlo.

Sobre cada uno de estos conjuntos de cambios se pueden realizar las mismas tareas de antes, siendo la más habitual en este caso Comparar una determinada versión con otra, para ver qué cambios se han realizado en un objeto a lo largo del tiempo. Esto es más potente de lo que podría parecer ya que, si llevamos un buen control de versiones podremos comparar la versión que tenemos en producción con la versión actual, para prever el impacto que tendrá cuando se actualice.

Conclusiones

Creo que después de este artículo ya podemos tirar a la basura el mito de “Usar un control de versiones en AX es inútil para equipos pequeños” y también el de “la sobrecarga de trabajo no se amortiza“. Con todo lo que hemos visto hasta ahora ya se puede demostrar que usar un VCS es una necesidad incluso para un solo desarrollador. La posibilidad de almacenar cada pequeño cambio en un objeto, de tener cada conjunto de cambios asociado a una tarea, la posibilidad de deshacer cambios indeseados, son cosas que podemos necesitar en cualquier momento, seamos uno o cincuenta desarrolladores en el equipo.

Por otro lado, como hemos visto, la sobrecarga de trabajo mientras se desarrolla no es tal. Estas acciones se interiorizan cuando uno empieza a utilizarlas y se desarrollan con normalidad durante el proceso. En ningún caso estamos generando un trabajo extra, sino al contrario, imaginemos: En un entorno con AOS compartido, que es la configuración habitual si no se usa TFS ¿Cuánto costaría volver a una versión anterior debido a un error cometido por un desarrollador? Esto en el mejor de los casos, en el que en la práctica exista una versión anterior. ¿Y si nadie tubo la precaución de exportar un XPO antes de realizar ese cambio peligroso? El único trabajo extra que requiere utilizar TFS es la instalación y el mantenimiento de TFS en si mismo, trabajo que puede casi eliminarse si utilizamos su versión cloud: Visual Studio Online.

Obviamente, en equipos grandes la necesidad se agrava. En equipos grandes y multidisciplinares como el nuestro, donde tenemos desarrolladores internos y externos a la compañía (partners, desarrollos de ISV, etc.) incluso en distintos países, desarrolladores senior y también recién llegados, etc. se hace muy importante poder revisar código, decidir qué cambios pasan a los entornos de test y cuales no, la posibilidad de volver atrás en cualquier momento, averiguar quién tocó aquel objeto, cuándo y por qué (mediante los comentarios de los check-in, y las tareas asociadas), y un largo etcétera…

Conclusión:

AX2012 vs TFS - KEEP CALM!