¿Por qué deberías usar Team Foundation Server para la gestión del ciclo de vida de Dynamics AX?
Si ya usas Team Foundation Server en tus proyectos de Dynamics AX, aprovechando todos los beneficios que puede aportar a tus equipos, o si ya estás convencido de usarlo pronto, entonces este artículo no es para ti.
Puede que no estés convencido o, peor aún, que no estés de acuerdo en que sea beneficioso para tus metodologías y comportamientos de equipo. Puedes intentar desafiar mis puntos con las circunstancias de tu proyecto que hacen que TFS sea inaceptable. Está bien. ¡Solo te pido que leas el artículo completo primero!
Team Foundation Server (o Visual Studio Team Services*) es una herramienta, y como tal, te permitirá lograr las mismas tareas más rápido y con menos esfuerzo. Además, TFS también te dará la capacidad de ejecutar tareas cruciales que solo están disponibles usando este tipo de herramientas. Esas tareas están principalmente relacionadas con el trabajo de desarrollo y la gestión del código fuente, lo que facilita la vida del desarrollador, pero algunas de ellas también ayudan a los jefes de proyecto y consultores, y apoyan la guía y validaciones de Aseguramiento de la Calidad, pruebas y todos los demás pasos del Ciclo de Vida de la Aplicación, sea cual sea la metodología utilizada para gestionar nuestros proyectos: Microsoft SureStep, Agile, Scrum, …
Sin mencionar que el uso de TFS es obligatorio en el nuevo Dynamics 365 for Operations, por lo que incluirlo en nuestros procesos de ciclo de vida hoy facilitará la transición y pondrá en marcha un conjunto de Buenas Prácticas que mejorarán tu equipo desde el primer día.
Echemos un vistazo a los beneficios de TFS en las tres principales categorías de la Gestión del Ciclo de Vida de la Aplicación:
1. TRABAJO
El módulo TRABAJO está destinado a apoyar las tareas de gestión de proyectos, pero podemos obtener mucho más de él si lo hacemos parte de la caja de herramientas de nuestro equipo.
Es un gestor de Elementos de Trabajo simple, genérico pero efectivo, que puede usarse eficazmente dependiendo de la metodología utilizada para gestionar cada proyecto. Por defecto, el sistema crea Tipos de Elementos de Trabajo como Epic, User Story, Task, Test Case, Bug, y así sucesivamente, pero lo más importante es que estos elementos están aquí para apoyar nuestras necesidades, así que úsalos en consecuencia.
No es obligatorio gestionar tareas y requisitos, pero te ayudará a mejorar la trazabilidad de la Gestión de Proyectos en todo el equipo (incluso puedes crear estos elementos desde Microsoft Project Server). Permite vincular cambios de código y metadatos realizados por un desarrollador, con una descripción completa que cualquiera puede entender. Así, en cualquier momento, todos sabrán por qué se hizo un cambio y podrán proporcionar información sobre el estado de pruebas y despliegue de cada solicitud recibida de usuarios, clientes o quienes sean nuestros interesados.
Aquí tienes algunos ejemplos de preguntas críticas que solo pueden responderse cuando se usan Elementos de Trabajo:
- ¿Quién hizo este cambio? ¿Se cambió algo más al mismo tiempo?
- ¿Por qué se modificó este objeto? ¿Este cambio está relacionado con algún requisito de negocio, una corrección de error, una solicitud de cambio de cumplimiento?
- ¿Cuándo se modificó este objeto por última vez?
- ¿Cuántas veces se ha modificado este objeto? ¿Cuáles fueron las motivaciones de cada cambio?
- ¿Cuál era la versión de la aplicación en el momento en que se introdujo este cambio o corrección? (El mantenimiento de hotfixes y actualizaciones será un post aparte)
- ¿Cuáles son las diferencias entre el estado actual de la aplicación y el que tenía cuando se hizo este cambio?
- Estimar posibles conflictos de hotfix o actualizaciones de código basándose en los cambios que puedes ver en el control de código fuente.
Este es un pequeño conjunto de preguntas que puedes responder con el uso más básico de la integración del control de código fuente con Elementos de Trabajo. La lista crece cuando empiezas a usar Ramas y una práctica adecuada de compilación, como veremos en próximos posts.
Además, puedes mapear tus procesos BPM desde Lifecycle Services con los Elementos de Trabajo de TFS para sincronizar elementos y facilitar al equipo el acceso a su información usando su herramienta preferida.
2. CÓDIGO
Este es el módulo de TFS utilizado por los desarrolladores durante los cambios de código y metadatos (cambios en el AOT), y donde se almacenan las “versiones” de la aplicación.
El sistema de Control de Código Fuente proporcionado por TFS hace la vida del desarrollador más fácil y segura y, por lo tanto, más rentable para sus empresas. Es poco probable ver a un desarrollador negándose activamente a usar cualquier sistema de control de código fuente. Esas ventajas son significativamente más importantes cuando hablamos de equipos de desarrollo, y sorprendentemente mejores cuando hablamos de equipos distribuidos trabajando en diferentes ubicaciones, diferentes países, diferentes empresas (partners) o incluso diferentes zonas horarias. Cuanto más complejo sea el equipo, más beneficios obtendrán de cualquier mecanismo de control de código fuente implementado.
Puedes argumentar que TFS genera trabajo extra a los desarrolladores. Y eso es cierto en teoría, pero expliquemos cómo este trabajo “extra” se amortiza rápidamente. Pasos extra para los desarrolladores que usan un sistema de control de código fuente:
- Check-Out: Antes de modificar un objeto, el desarrollador debe indicar al sistema que este objeto va a ser modificado. El sistema descargará la última versión del servidor, por si algún otro desarrollador lo ha modificado, para que podamos trabajar con la versión más reciente.
- Check-In: Después de que los cambios estén hechos y validados por un desarrollador, un check-in enviará esos cambios al servidor para que otros desarrolladores puedan ver nuestra versión modificada, y liberará el Check-Out previo hecho a este objeto.
- Merge: Como muchos desarrolladores pueden estar trabajando con diferentes versiones del mismo objeto en sus entornos de desarrollo aislados al mismo tiempo, haciendo cambios en la misma pieza de código sin saber el trabajo en curso de los demás, la versión final del objeto puede necesitar ser fusionada manualmente. Durante el proceso de fusión, un desarrollador sube su versión al servidor y tendrá que tomar decisiones sobre la versión final, consolidada del objeto si hay conflictos. Esos conflictos pueden ocurrir si alguien más ha hecho cambios en la versión del servidor desde que el desarrollador actual descargó la última versión durante el Check-Out. Todos los sistemas de control de código fuente tienen herramientas para hacer que el proceso de fusión sea fácil y seguro, incluso automático si los cambios son lo suficientemente simples.
No parece mucho trabajo extra. Ahora analicemos lo que obtenemos a cambio y será aún mejor:
- El mecanismo de Check-In/Check-Out permite que varios desarrolladores trabajen en el mismo objeto sin molestarse entre sí. Mientras modifica un objeto, un desarrollador necesita guardarlo y ejecutarlo muchas veces hasta que la versión final esté lista. No será hasta que el desarrollador haga check-in de esta versión terminada que el resto de desarrolladores verá esos cambios. Cuando un desarrollador sincroniza cambios de un colega, siempre obtendrá un conjunto de cambios completo, por lo que no se verá afectado por errores inesperados debidos a cambios inacabados, algo común en entornos de desarrollo compartidos.
- Fusionar cambios puede ser molesto en algunos casos. Pero siguiendo una buena metodología siempre será más fácil que importar archivos XPO, ya que la herramienta de fusión de Visual Studio es mucho más sofisticada, potente y rápida que la MorphX Compare Tool (es justo decir que el rendimiento ha mejorado mucho en las últimas versiones). De todos modos, el resultado de este proceso de fusión siempre se guardará en el servidor como un nuevo conjunto de cambios. Si algo sale mal, siempre se puede ver exactamente qué se ha fusionado, arreglarlo o volver atrás a una versión anterior. Nada de esto está disponible cuando se nos pide importar un archivo XPO. Después de importar el archivo no podemos deshacer ningún cambio ni siquiera saber cuál era el estado anterior.
- Cada Check-In se guarda en el servidor como un conjunto de cambios. Este conjunto de cambios vincula todos los cambios realizados al mismo tiempo en código y metadatos a múltiples objetos, y puede vincularse a un Elemento de Trabajo o a más de uno, como mencionamos antes. Con un esfuerzo mínimo (como proporcionar un código de Elemento de Trabajo durante el proceso de check-in, ver la captura anterior), estamos creando un conjunto de cambios totalmente descriptivo que contiene objetos nuevos, modificados y eliminados, y la Tarea/Error/Requisito que motivó esos cambios. Esto proporcionará trazabilidad completa para cada cambio realizado y puede ser aún mejor si seguimos algunas reglas sencillas para fusionar entre Ramas permitiendo, por ejemplo, hacer revisiones de código usando esos conjuntos de cambios de ramificación.
- Guardar todos los conjuntos de cambios en el servidor permite que todos en el proyecto inspeccionen el historial de cambios de cualquier objeto de la aplicación, comparando diferentes versiones para ver qué ha cambiado con el tiempo y, si está vinculado a Elementos de Trabajo, quién y por qué se cambió.
Como ejemplo, en la imagen de abajo tenemos un conjunto de cambios completo tal como lo muestra el portal de VSTS (también se puede acceder desde Visual Studio), mostrando objetos nuevos y modificados, el enlace con 2 elementos de trabajo y cambios detallados de código y metadatos resaltados en diferentes colores:
Como esta vista es pura herramienta de TFS, cualquier miembro del equipo, independientemente de su conocimiento o acceso a una instancia de Dynamics AX (por supuesto TFS tiene su propio sistema de acceso y seguridad), podrá ver y revisar este historial de cambios para siempre, ya que esto se almacena en el servidor de control de código fuente independientemente de lo que ocurra con las instancias de prueba o desarrollo de Dynamics AX. Un sistema de desarrollo de Dynamics AX 2012 basado en cualquier versión almacenada en el servidor TFS (incluyendo cualquier Rama) puede desplegarse en cualquier momento, como veremos al hablar del módulo BUILD & RELEASE.
El mismo ejemplo visto arriba, pero esta vez desde la perspectiva de un entorno de desarrollo de Dynamics AX 2012 se muestra a continuación:
Esta es una herramienta invaluable para que los desarrolladores puedan ver rápidamente el historial de cambios de cualquier objeto y navegar a esta versión en el AOT, comparar con la versión actual o cualquier otra versión del objeto y ver qué ha cambiado, o incluso revertir el estado actual a una versión anterior para deshacer cualquier cambio involuntario o erróneo. A cualquier desarrollador le encantará eso, no hay mucha discusión aquí.
Toda esta trazabilidad de código solo es posible cuando se usa TFS para rastrear los cambios. Dynamics AX es una aplicación tan crítica para el negocio que cualquier cambio de código debe ser descrito, controlado y rastreado. Quién, cuándo y por qué se hace un cambio debe ser claro y fácil de acceder. Los clientes sin tal trazabilidad se ponen en un camino peligroso para problemas de regresión e inestabilidad del código.
Aún no estamos considerando el concepto de Ramas, estrechamente relacionado con cualquier sistema de control de código fuente, que representa en términos generales diferentes versiones de toda la aplicación que podemos gestionar de forma independiente. Permite mantener un historial de versiones detallado (¿Cuál era el estado de mi aplicación en un momento específico?) que va en línea, pero mucho más en profundidad que la típica granularidad Dev/Test/UAT. Las ramas son un tema interesante pero extenso, así que le dedicaremos un post completo en el futuro si nuestros lectores están interesados en el tema.
3. COMPILACIÓN Y DESPLIEGUE
Debo admitir que el módulo de compilación es mi tema favorito: es donde el ciclo de vida del desarrollo se cierra y los beneficios de usar un proceso completo de Gestión del Ciclo de Vida de la Aplicación (ALM) pueden apreciarse de manera clara y obvia por todo el equipo. Pero también es un tema bastante grande, así que dejaré los detalles para un próximo post.
En resumen: En Dynamics AX 2012, podemos trabajar con un sistema de control de código fuente para desarrollar cambios de código y metadatos, y luego exportarlos como un modelo (no considero los archivos XPO como un artefacto de promoción válido). Eso funciona de serie, pero podemos ir un paso más allá y poner en marcha algunas herramientas automáticas para hacer que nuestros despliegues sean más rápidos, fáciles y predecibles. Cuanto más predecible es un proceso, más fácil es automatizarlo. Cuanto más automático, más robusto y a prueba de errores.
Imagina que todos los cambios realizados por nuestro equipo de desarrollo distribuido se compilan, empaquetan y despliegan cada noche en un AOS de pruebas consolidado, de modo que todos los cambios finalizados por nuestros desarrolladores el día anterior estén disponibles para los testers cada mañana: Ese es el tipo de automatización que podemos hacer con la capacidad de COMPILACIÓN Y DESPLIEGUE.
Hay mucho de qué hablar sobre la automatización de COMPILACIÓN Y DESPLIEGUE y sus posibilidades, pero este post ya se está alargando más de lo esperado. Lo continuaremos en los próximos.
Si aún quieres demostrarme que estoy equivocado sobre el uso de TFS, estaré encantado de discutir casos individuales contigo. Yo mismo trabajé como desarrollador y líder de equipo de desarrollo usando TFS, así que soy muy consciente de algunas limitaciones respecto a la infraestructura física necesaria para entornos aislados, por ejemplo. Pero, por favor, considera siempre que evitar activamente el uso de un sistema de control de versiones en proyectos de software (y una implementación de Dynamics AX es tal proyecto) tiene un precio que alguien tendrá que pagar.
Dale una oportunidad**. Empieza simple y evoluciona a medida que descubras posibles mejoras para tu ciclo ALM. Analiza pros y contras, siempre intentando sacar el máximo partido a las herramientas.
* Uso el acrónimo TFS independientemente de la versión de la que hablemos, ya sea local (llamado Team Foundation Server) o en la nube (llamado Visual Studio Team Services, o VSTS) ya que son prácticamente equivalentes con pequeñas diferencias mientras los cambios continuos desplegados en la versión en la nube finalmente se liberan como una nueva versión para la versión local. Dynamics AX 2012 es compatible con ambas versiones pero se necesitan algunas versiones o hotfixes específicos para algunas combinaciones. Consulta Prerequisitos de Dynamics AX para detalles específicos.
** Probar TFS nunca ha sido más fácil. Desde la perspectiva de la implementación, usando VSTS no necesitas instalar ni desplegar ningún componente tú mismo ya que funciona como un servicio; En cuanto a costes, VSTS es gratuito hasta 5 usuarios, más que suficiente para probar con un equipo piloto, y el coste total se ha reducido mucho incluso si necesitas comprar más licencias. Además, la licencia está incluida en las Suscripciones de Visual Studio (antiguas suscripciones MSDN) ¡así que puede que ya la tengas licenciada!
Publicado primero en “Dynamics AX in the Field”, el blog del equipo de Premier Field Engineering de Microsoft.
Publicaciones en esta serie
- Publica Tus Paquetes De Dynamics 365 for Finance and Operation en LCS Con Azure DevOps Pipelines
- ¿Por Qué Deberías Usar Team Foundation Server Para La Gestión Del Ciclo De Vida De Dynamics AX?