Why you should be using Team Foundation Server for Dynamics AX lifecycle management?

If you already use Team Foundation Server in your Dynamics AX projects, providing all benefits it can give to your teams, or if you are already convinced to use it soon, then this article is not for you.

You may not be convinced or, even worst, you may disagree about it to be beneficial to your methodologies and team behaviors. You can try to challenge my points with your project’s circumstances that make TFS unacceptable. That’s fine. I’m only asking you to read the full article first 🙂

Microsoft Application Lifecycle Management

Team Foundation Server (or Visual Studio Team Services*) is a tool, and as such, it will allow you to achieve the same tasks faster and with less effort. Furthermore, TFS will also give the ability to execute crucial tasks that are only available by using this kind of tools. Those tasks are mostly related to development work and source code management, what makes developer’s life easier, but some of them also help project managers and consultants, and support Quality Assurance guidance and validations, testing and all the rest of Application Lifecycle Management steps, whichever methodology is used to manage our projects: Microsoft SureStep, Agile, Scrum, …

Not to mention that using TFS is mandatory in the new Dynamics 365 for Operations, so including it in our lifecycle processes today will ease the transition and will put in place a set of Best Practices than will improve your team since day one.

Let’s have a look at the benefits of TFS in the three main categories of Application Lifecycle Management:

  1. Work
  2. Code
  3. Build & Release

Read the full article at “Dynamics AX in the Field”, the blog from the Premier Field Engineering team at Microsoft.

Procesos BUILD automáticos con TFS y AX 2012 (2/2) (ALM-X)

En el artículo anterior de esta serie definimos el proceso principal para configurar una Build de Microsoft Dynamics AX 2012 en TFS, en resumen:

  • Instalar y configurar los componentes de TFS necesarios en el servidor de build (Agente, Controlador, etc.).
  • Crear un nuevo proyecto con las actividades personalizadas y la plantilla por defecto.
  • Subir todo esto al repositorio de código fuente en TFS o Team Services para que el Controlador pueda acceder a ellos.
  • Añadir estas referencias a Visual Studio para que éste reconozca las actividades nuevas.
  • Crear una nueva definición de Build utilizando la plantilla descargada.

Nos quedábamos ejecutando esta definición de Build recién creada con todas las opciones, actividades y plantilla por defecto, y tras todo lo cual recibíamos un error. Frustrante, ¿No? Puede que si, pero si lo pensamos es bastante lógico, veamos:

Una Build no es más que un workflow que ejecuta una serie de pasos en un determinado orden. Este workflow es la Plantilla (template) que nos hemos descargado, un fichero con extensión XAML que, si hemos seguido todos los pasos hasta aquí, podremos incluir en un proyecto o solución de Visual Studio y editarlo desde ahí, y que tiene este aspecto:

SimpleWorkflowTFS2013-Joris

Continue Reading…

Procesos BUILD automáticos con TFS y AX 2012 (1/2) (ALM-IX)

En los post anteriores de esta serie hemos visto cómo configurar un servidor TFS (local o en la nube) y cómo utilizarlo para gestionar nuestras tareas, controlar el código fuente y gestionar versiones mediante ramas, entre otras cosas. Para cerrar el círculo debemos procesar toda esa información, código y versiones en algo que podamos entregar a nuestros clientes/usuarios.

Aquí es donde entran en juego los procesos automáticos de construcción y compilado, llamados procesos Build. Ejecutar una Build en TFS es relativamente sencillo si trabajamos con lenguajes .NET, pero para hacerlo con AX tendremos que trabajar un poco antes para preparar el entorno e instalar los componentes necesarios en los servidores.

Tenemos un resumen bastante bueno de los componentes necesarios a nivel general en el siguiente enlace. Los componentes a instalar dependerá de si utilizamos un TFS local o en la nube.

Primero debemos familiarizarnos con algunos conceptos clave:

  • Build Service: Servicio que acepta peticiones de ejecución de Build.
    • Un servicio está asociado a una colección de proyectos en TFS.
    • Habitualmente sólo necesitamos un servicio por colección de proyectos.
  • Build Controller: Orquesta la Build y delega el trabajo en los Build Agents.
    • Un controlador está asociado a un Build service.
    • Puede que necesitemos varios controladores si tenemos varios entornos preparados para ejecutar Build. En ese caso asignaremos lo agentes a cada controlador para crear diferentes colas de proceso.
  • Build Agent: Servicio que realiza la Build.
    • Un agente se registra en un controlador
    • Debe instalarse en la misma máquina que el AOS que va a ejecutar el proceso
    • Se debe instalar un agente por cada AOS que tengamos procesando Build.

Es posible instalar y ejecutar varios servicios, controladores y agentes, pero para empezar es suficiente con instalar uno de cada. En nuestro caso es necesario que todos estos componentes estén instalados en nuestros servidores, ya que van a requerir utilizar instancias de AX. Pero el código fuente puede estar en una instancia de TFS en la nube sin ningún problema, cada componente puede estar en servidores diferentes, como se muestra en el siguiente esquema:

VSO Build Overview

Continue Reading…

Códigos de etiquetas de Microsoft Dynamics AX 2012 usando ramas de Team Foundation Server (ALM-VIII)

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.

Continue Reading…

Control de versiones en Microsoft Dynamics AX 2012 mediante ramas de Team Foundation Server (ALM-VII)

En capítulos anteriores hablamos sobre cómo instalar y configurar Team Foundation Server, así como las posibilidades que ofrece para gestionar tareas y administrar el código fuente desde nuestra instancia de Microsoft Dynamics AX 2012. Comentamos las funciones básicas ,aunque imprescindibles, para proteger y desproteger el código en el servidor y las ventajas que ello suponía en cuanto a almacenar todo el histórico de cambios de los objetos, como por ejemplo: revisar el historial de cambios de un objeto, volver a una versión anterior, descartar cambios sin confirmar, etc.

Sin embargo hay ciertos problemas que una gestión básica del código fuente no es capaz de solucionar. Por ejemplo, en una instalación normal de nuestro ERP, a la vez que damos el soporte diario y realizamos pequeñas modificaciones para solucionar problemas, estamos llevando a cabo desarrollos de mayor o menor impacto. Estos desarrollos paralelos necesitan ser integrados en el código de producción de alguna forma, pero si usamos el mismo servidor para desarrollar y para hacer el mantenimiento, tendremos que llegar a un punto en el que todos los desarrollos estén totalmente terminados para pasar a producción de forma limpia y segura.

De la misma forma, si nuestra empresa desarrolla un producto final, es necesario avanzar el desarrollo de las siguientes versiones mientras damos soporte a las versiones publicadas en el pasado, incluso para diferentes versiones de AX. ¿Cómo estar seguro que un hotfix urgente desarrollado para un cliente llega a todas las versiones de nuestro producto que la necesitan, de forma limpia y estable?

Visual Studio loves Dynamics AX 2012

Por supuesto hace falta un buen método de trabajo para que todo esto pueda realizarse de forma ordenada y sin errores, pero también hace falta la ayuda de alguna herramienta y para eso tenemos las ramas (Branches) disponibles en casi todos los sistemas de control de versiones del mercado, y por supuesto en nuestro Team Foundation Server.

Estrategias de branching

Existen infinidad de estrategias para definir las ramas que necesitamos en nuestros equipos, y ello va a depender de la cantidad de equipos que tengamos, la cantidad de productos, de versiones, etc. NO HAY una estrategia de ramas estándar o válida para todos y es algo que se debe pensar con cuidado ya que la estrategia elegida nos va a suponer ventajas e inconvenientes. Lo más recomendable es empezar por la lectura de la guía Version Control Guide escrita por el grupo Visual Studio ALM Rangers donde explican la mayoría de opciones con sus pros y sus contras.

Continue Reading…

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.

Continue Reading…