Aquí puedes leer mi guía completa sobre Dynamics 365 for Finance and Operations y Azure DevOps.

Con la llegada de Dynamics 365 el uso de un sistema de control de versiones se ha convertido en obligatorio. En anteriores versiones disponíamos de Morph VCS en AX 2009 y la posibilidad de integrar TFS en AX 2009 y AX 2012, pero no existía ninguna obligación de usar ninguno de los dos. En realidad, siempre según mi experiencia, creo que la mayoría de proyectos se llevaban a cabo sin ningún tipo de control de versiones aparte de, con suerte, comentarios en el código.

El AOT antes de la llegada del control de versiones
El AOT antes de la llegada del control de versiones, de cazapelusas.com

Azure DevOps en MsDyn365FO

En Microsoft Dynamics 365 for Finance and Operations el control de versiones que nos ofrece Azure DevOps no es un simple control de versiones, sino una LA herramienta que hará un poco de Anillo Único en nuestros proyectos (solo que, espero, no para atarnos en las tinieblas). Y es que el cambio no solo afecta al equipo técnico. Desde dirección de proyecto a funcionales pueden implicarse en el uso de Azure DevOps para la gestión del proyecto.

La sincronización del BPM y creación de todas las tareas, planificación del equipo, gestión del código, builds automatizadas y releases que veíamos en un post anterior, son algunas de las herramientas que nos ofrece. Todos estos cambios requieren de un aprendizaje y adaptación por parte del equipo al completo, pero van a ayudarnos mucho en el control del proyecto.

Como decía, puede parecer que el equipo técnico sea el más afectado por la introducción de Azure DevOps por la «obligatoriedad» de usarlo en Visual Studio (bendita obligación), pero también es el que más provecho le va a sacar… 😉

Primeros pasos

Lo primero que tenemos que hacer cuando empezamos un nuevo proyecto de implantación es conectar LCS y el proyecto de Azure DevOps que vayamos a usar. Está todo muy bien explicado en la documentación.

Una vez configurada la conexión tenemos que desplegar el entorno de Build que vimos en el anterior post. Esto se hace habitualmente en la máquina de desarrollo disponible en la suscripción de Microsoft en el proyecto de LCS. Cuando se despliega esta máquina se va a crear la estructura básica de carpetas en el proyecto de DevOps:

Carpetas en proyecto de Azure DevOps

(Ignorad la carpeta CSProjects que es de la actuación cómica del pasado 365 Saturday con mi compañero Juanan)

Con esto ya podemos mapear las máquinas de desarrollo y empezar a trabajar. La carpeta Main que veis en la imagen es una carpeta normal, pero la podremos convertir en una rama en caso de que lo necesitemos.

Carpeta convertida en rama

En la imagen de arriba podemos ver que el icono de Main cambia cuando se convierte en una rama. Las ramas (branches en inglés) nos ofrecen funcionalidades que no están disponibles en las carpetas. Lo podemos ver en el menú contextual:

Menú contextual carpeta
Menú contextual carpeta
Menú contextual rama
Menú contextual rama

 

 

 

 

Por ejemplo en las ramas podemos ver la jerarquía de las distintas ramas del proyecto (En este caso que sólo trabajamos con dos ramas no parece muy útil :P).

Jerarquía de las ramas

También son distintas las ventanas de propiedades de ambas. Las de una carpeta:

Y las propiedades de una rama, donde podemos ver las relaciones y las ramas que se han creado a partir de ella:

Propiedades de la rama

Todo esto son detallitos, pero quizás lo que mas nos interese de convertir Main en una rama es que nos permitirá ver dónde se ha mergeado qué, como veremos en un próximo post 😛

Un consejo

La carpeta de Projects es buena idea ponerla en la raíz del proyecto de DevOps (al mismo nivel que BuildProcessTemplates y Trunk). Si no se cambia y acabáis trabajando con una rama de dev y la de Main, los check-in de las soluciones y proyectos de Visual Studio se seguirán haciendo en Main (porque la carpeta de proyectos estará ahí). Os ahorrará microinfartos cuando veáis la lista de changesets en el correo de la build de Main 🙂


Y hasta aquí la primera parte del tema. En el próximo post voy a intentar explicar la estrategia de branching que podemos usar en los proyectos y definiciones de build que nos pueden ser útiles.

¡Suscríbete!

Recibe un correo cuando se publique un nuevo post
Author

Microsoft Dynamics 365 Finance & Operations technical architect and developer. Business Applications MVP since 2020.

ariste.info