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.

Unit Testing X++ code in Visual Studio (AX 2012) [EN]

I’m pretty sure everybody who has tried will agree with me that the Unit Testing framework included in the AX 2012 development environment (aka MorphX) has some limitations. Sometimes such limits become so impacting that makes the framework almost useless when the code you need to test starts growing (let’s discuss design problems in a separate post :)).

But I’m not going to talk here about limitations, but about what we actually can do, and one of such things is to use X++ proxy classes to write our unit tests in Visual Studio, and use the native testing framework included here with all its possibilities. Let’s see how it works with an easy example.

I wrote this simple X++ class in order to have something to test:

Continue Reading…

Test Unitarios de código X++ en Visual Studio (AX 2012)

Creo que todo el que lo haya intentado estará de acuerdo en que el framework para Unit Testing integrado en el propio entorno de desarrollo de Microsoft Dynamics AX 2012 (del nuevo Dynamics AX, AX 7, hablaremos otro día) es bastante limitado. Tan limitado que resulta prácticamente inutilizable en cuanto quieres probar algo más o menos serio.

Pero hoy no quiero hablar de limitaciones sino de lo que podemos hacer, y entre estas cosas está la posibilidad de utilizar classes proxy del código X++ para poder escribir las pruebas unitarias en el propio Visual Studio, y utilizar así sus posibilidades y su flexibilidad. Veamos un ejemplo sencillo.

Voy a intentar probar una clase que he hecho en X++ específicamente para esto, con este código:

Continue Reading…

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…

[HowTo] Desplegar Microsoft Dynamics AX 7 en Azure

El nuevo Microsoft Dynamics AX, como sabemos, sólo está disponible en su versión para Azure por el momento. En cualquier caso, incluso cuando se publique la versión on-premise los entornos de desarrollo van a ser máquinas virtuales autocontenidas que podemos desplegar en Azure o montar en entornos locales.

Vamos a aprovechar que hoy Scott Guthrie (Executive VP Microsoft Cloud and Enterprise) ha anunciado la disponibilidad de la la preview pública durante la Convergence 2015 EMEA en Barcelona, para a ver cómo desplegar una de esas máquinas de desarrollo/demo y empezar a echar un vistazo a la plataforma, es muy fácil.

Microsoft Dynamics Lifecycle Services

Empezamos, como no puede ser de otra forma, en Lifecycle Services, sección Cloud-hosted environments, y seleccionamos Add. A partir de aquí seguimos el sencillo asistente para indicar el tipo de máquina que queremos desplegar, y en el último caso indicamos Azure como plataforma de despliegue. También odríamos elegir Locally para descargar el disco duro virtual de la máquina e instalarla en nuestros propios servidores.

Si seleccionamos Locally, se descarga el disco duro virtual y acaba el asistente. Si seleccionamos Azure, el asistente continúa y nos pide cuántas máquinas queremos desplegar y el tamaño de las mismas (ver tamaños de Azure aquí). Obviamente, cuanto mayor tamaño mejor rendimiento pero también mayor consumo de nuestros recursos de AX. En esta demo sólo voy a desplegar una máquina de desarrollo. Si elegimos desplegar máquinas de Build a la vez, ésta quedará configurada automáticamente mediante TFS, pero esto lo veremos en otro artículo.

Es posible que esto cambie en el futuro, pero en la versión previa de LCS disponible ahora mismo es necesario pulsar el botón Advanced settings e indicar nuestro login a VSO para que se pueda realizar a configuración del gestor de código fuente. Si no se incluye esta información el despliegue fallará. Podemos echar un vistazo a estas opciones avanzadas que nos permite configurar muchas propiedades de los servicios que se van a desplegar en Azure.

El proceso de despliegue tarda un buen rato, dependiendo de cuantas máquinas estemos creando. En cualquier caso puede tardar varias horas. Una vez terminado tendremos una página en LCS desde donde podremos realizar diferentes acciones.

  • Por un lado podemos conectar a la máquina virtual descargando un fichero RDP pulsando sobre el nombre de la máquina, desde donde podremos ejecutar las herramientas de desarrollo (Visual Studio).
  • En la página se nos muestran los usuarios y contraseñas utilizadas para el usuario Administrador.
  • Podemos iniciar y detener el entorno cuando queramos para ahorrar recursos de Azure mientras no la utilicemos.
  • Ofrece información sobre todos los recursos desplegados, que también podemos consultar desde el portal de administración de nuestra suscripción de Azure.
  • Pero lo más importante es que nos permite conectar directamente en el AX hospedado en este entorno. Recordad que AX es ahora una web, así que podemos conectar directamente a estas aplicaciones mediante el navegador web utilizando los enlaces disponibles en esta página (Login to Dynamics AX7, Login to Dynamics Retail, Login to Cloud Point of Sale) con los usuarios indicados.

Cuando la máquina se detiene desde esta sitio en LCS, las máquinas virtuales y servicios (el AOS) se detienen también, pero no el almacenamiento y otros servicios como el Directorio Activo, es normal ya que el almacenamiento sigue siendo utilizado aunque la máquina se pare (nuestros datos siguen en sus discos duros). Esto no es mayor problema ya que estos servicios son realmente baratos incluso ahora, antes de que se publiquen los packs de precios para Dynamics AX que nos permitirán ahorrarnos todos estos cálculos creando un plan de licencias por usuario sin tener en cuenta los recursos utilizados.

Una vez desplegada nuestra máquina de desarrollo, estamos listos para seguir con los siguientes artículos! 🙂