Microsoft Dynamics AX 2012 Application Lifecycle Management (ALM-I)

Aunque pueda parecer curioso, incluso inquietante, una gran parte de los proyectos de implantación de ERP’s entre los que podemos incluir la familia Dynamics en general y Microsoft Dynamics AX en particular no se ejecutan como proyectos de software. Quizás por la cercanía del proyecto al negocio o quizás por la orientación -más a negocio que a software- de las personas implicadas en la mayor parte del tiempo consumido, una buena parte de las veces se olvida, o se obvia, que estamos tratando de implementar un software y por tanto es conveniente tratar el proyecto como un proyecto de software y aplicar conceptos propios de la ingeniería de software para gestionar el software y la gestión de proyectos para gestionar el proyecto.

Ya he hablado en artículos anteriores de diferentes metodologías de implantación como puede ser Microsoft Sure Step o las metodologías ágiles a las que cada vez se acerca más gente, incluida Microsoft. No son las únicas, cada empresa utiliza las que conoce y considera mas apropiadas para cada proyecto como PMBOK o PRINCE2 o técnicas más específicas del software y la tecnología como CMMI o ITIL, e incluso algunas empresas “diseñan” las suyas propias. El problema es que es demasiado habitual que no se utilice ninguna o que la elegida no abarque todo el ciclo de vida de una aplicación.

Alguno podrá pensar: “¿Estás criticando la utilidad de metodologías utilizadas por la mayoría de multinacionales del mundo durante años?“. No. Claro que no. Ni siquiera conozco la mayoría de ellas como para, siquiera, tener una opinión. Lo que sí esta claro, por su propia definición, es que son propuestas orientadas a la gestión del proyecto como tal (alcance, recursos, tiempo, coste, materiales,…) pero no tienen en cuenta de manera específica los problemas propios del software, que a menudo quedan olvidados al no formar parte de los procedimientos formales. En resumen, se gestionan más las limitaciones y los riesgos (lo que no se puede hacer) que lo que SÍ debe hacerse. Dicho de otra forma, se están utilizando estas metodologías (totalmente válidas) para gestionar conceptos que NO SON el software.

Para mejorar esto hemos de recurrir a la tan olvidada ingeniería del software y a un concepto que cualquier empresa dedicada exclusivamente a producir software tiene más que asumido en su operativa diaria y en su rentabilidad: El ciclo de vida de la aplicación (o Application Lifecycle Management, o simplemente ALM).

Microsoft Application Lifecycle Management

Wikipedia da una buena definición de Ingeniería del Software (traducido). Quizás no es la mejor fuente pero es la más accesible:

[…] Ingeniería de Software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al diseño, desarrollo, operación y mantenimiento de software […]

Ahora cabría plantearse si el método que estamos utilizando en nuestro entorno (soy optimista y pienso que ya se está utilizando alguno) cumple estas sencillas directivas (sistemático, disciplinado y cuantificable) a todas las áreas del ciclo de vida (desde el desarrollo al mantenimiento, sin olvidar la gestión del cambio). Si es así, enhorabuena; si no lo es, te interesa el resto del artículo y los que vendrán a continuación…

Continue Reading…

Instalación de Team Foundation Server 2010 (ALM-II)

En la anterior entrada de esta serie vimos la necesidad de seguir una metodología de gestión del ciclo de vida de la aplicación para la gestión de las soluciones de Microsoft Dynamics AX 2012. También vimos que la principal herramienta para gestionar la parte técnica de este ciclo de vida es Microsoft Team Foundation Server. En esta entrega veremos cómo instalar y configurar el entorno para poder empezar a trabajar.

Pre-requisitos

Supongo que ya tenemos un entorno funcional de Microsoft Dynamics AX 2012 para hacer las pruebas, lo que supone tener instalados los siguientes prerrequisitos:

Para la instalación completa des Team Foundation Server, será necesario además la instalación de los servicios de SharePoint, que también podemos tener instalados en nuestro entorno Microsoft Dynamics AX 2012, o puede que no. En mi caso no lo tenía, así que he instalado:

Y para la instalación del propio Team Foundation Server, voy a instalar:

También nos puede venir bien una instancia de Visual Studio para las tareas de mantenimiento de proyectos. Lo habitual en instalaciones de Microsoft Dynamics AX 2012 es que tengamos un Visual Studio 2008 instalado en la máquina de Microsoft SQL Server (Visual Studio 2008 BIDS) y un Visual Studio 2010 en la máquina donde desarrollemos para Microsoft Dynamics AX 2012. La conexión funcionará con ambas versiones y no afectará a los proyectos creados en el servidor, pero para conectar desde Visual Studio 2008 BIDS será necesario instalar las siguientes actualizaciones:

Continue Reading…

Microsoft Dynamics AX 2012 ALM con Team Foundation Server (ALM-III)

En la anterior entrada de esta serie, vimos al detalle cómo instalar y realizar la configuración básica de un servidor Team Foundation Server 2010, y suponíamos también la instalación de un Visual Studio 2008 o 2010 configurado con las actualizaciones suficientes para conectar a este servidor. Nuestro servidor quedó instalado y configurado con una o varias colecciones de proyectos, pero ningún proyecto creado.

En esta entrada vamos a comprobar cómo un servidor de Team Foundation Server 2010 puede ayudarnos a la gestión del ciclo de vida de la aplicación a nivel funcional, sin entrar en detalles técnicos, y cómo esta funcionalidad nos ayudará desde las primeras fases del proyecto en la toma de requisitos, hasta las últimas con la gestión de incidencias o la gestión del cambio.

Lo primero que necesitamos para la gestión de nuestro proyecto es, como cabe suponer, un proyecto. La creación de un proyecto no se puede realizar desde el acceso web de TFS2010 por lo que necesitaremos conectarnos al servidor mediante Visual Studio. En este capítulo trabajaremos con Visual Studio 2010 que casi seguro tendremos instalado en nuestra máquina de desarrollo de Microsoft Dynamics AX 2012.

En la página de inicio de Visual Studio 2010 vamos a elegir la opción Connect To Team Foundation Server:

TFS2010 - Connect to Team Foundation Server

Si nunca hemos conectado a nuestro servidor (o a ninguno) no aparecerá en la lista de servidores, para añadirlo pulsamos Add y escribimos el nombre del servidor donde trabajamos en el capítulo anterior. El asistente se ocupará de completar la URL:

TFS2010 - Add server

Continue Reading…

Descargar aplicación Microsoft Dynamics AX 2012 desde Team Foundation Server (ALM-IV)

Hace ya mucho tiempo desde la última entrada de esta serie!! Pero aquí estamos de vuelta. Voy a plantear un caso real: Empezamos a trabajar con un cliente y cuando le pedimos los datos para conectar a su aplicación sólo nos da un usuario y una contraseña y una URL correspondiente a un proyecto de Team Foundation Server. ¿No puede ser tan complicado verdad? Pues no lo es, incluso apuntando esa URL a un TFS en la nube (ahora Visual Studio Online, durante un tiempo llamado Team Foundation Service).

El primer paso es preparar el repositorio local donde se van a almacenar los ficheros descargados desde TFS. Para esto simplemente hay que crear una carpeta en el disco duro, yo suelo hacerlo en c:\TFS_Repo y dentro de esta carpeta creo una estructura con la forma \Proyecto\(Rama)\Aplicacion\Modelo. Como en este caso no voy a utilizar ramas, creo la carpeta c:\TFS_Repo\AX2012\Main (Main es mi nombre para la aplicación, en este caso). Esta estructura puede variar según las necesidades y los gustos de cada uno, yo lo hago así porque dentro de la carpeta TFS_Repo puedo almacenar otros proyectos de TFS independientes de AX 2012, y todo queda ordenado.

A continuación, en el entorno de desarrollo de mi aplicación AX 2012 (que está recién instalado, sin ningún cambio), vamos a Control de la versión > Parámetros de control de versión, o Ctrl+Shift+V:

AX2012 TFS - Parámetros TFS

Continue Reading…

Leer elementos de Team Foundation Server desde Microsoft Dynamics AX 2012 (ALM-V)

Vuelvo brevemente sobre una de mis series de post mas largas hasta la fecha, lo referente a la integración de AX 2012 con Team Foundation Server, no sólo para la gestión del código fuente, sino también como herramienta de gestión del trabajo del equipo. En capítulos anteriores ya vimos cómo se instala y configura TFS (esto cambia entre versiones, también vimos que no necesitamos instalar nada si utilizamos la versión en la nube) y cómo podíamos crear elementos de trabajo en TFS (WorkItems) para gestionar el trabajo desde esta herramienta.

Al hacer un check-in de código desde Microsoft Dynamics AX 2012 se nos plantea la posibilidad de asociar ese check-in a algunos elementos de trabajo de TFS. Esto es casi obligatorio para poder llevar un buen control de para qué se realiza cada cambio, pero la herramienta que nos ofrece AX es bastante limitada. Sin embargo, gracias al API de TFS, podemos ampliarla e incluso desarrollar nuestras propias herramientas e informes en AX 2012 obteniendo datos del servidor de TFS (sí, también desde Visual Studio Online).

Una funcionalidad muy interesante para ahorrarnos tiempo de desarrollo es poder ejecutar desde AX 2012 consultas que están guardadas y utilizamos en TFS. Esto nos permite tener las mismas vistas de datos en los dos entornos, lo que facilita el trabajo. Profundizaré sobre esto en los siguientes post sobre este tema, pero ahí va un código de ejemplo para realizar esta tarea.

NOTA: Para que estos ejemplos funcionen, es necesario tener instalado el SDK de Visual Studio de la versión de TFS que estemos utilizando. En mi caso es el SDK de la versión 2013 porque estoy utilizando Visual Studio Online, pero esto puede variar en cada instalación. Se puede descargar del siguiente enlace:

Después de instalar el SDK, hay que añadir las referencias necesarias al AOT para que AX 2012 pueda utilizarlas:

Add references to AOT

Ahora si, el código:

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…