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.

2 comentarios
  • jaestevan
    Junio 24, 2017

    Hola Daniel,

    Sobre D365 tengo pensado escribir artículos específicos porque la estrategia puede cambiar respecto a AX2012 (para mejor, por suerte).

    Básicamente en D365 seguimos las directrices estándar de .NET. En principio no deberías tener que cambiar el workspace de los usuarios por tener mas ramas, ya que a las ramas de TEST, UAT, etc. sólo debería llegar código mediante “merges” desde las ramas de desarrollo, que serán las que tengan siempre configuradas los usuarios. Si es necesario estar cambiando de rama constantemente, es muy posible que las ramas no se estén usando correctamente y para lo que están pensadas.

    Es una conversación larga para una respuesta, así que por favor este atento al artículo sobre D365 🙂

    Mientras tanto puede buscar información genérica sobre ramas para .NET desde Visual Studio. La mayoría de información disponible, que es mucha, es útil para D365 ya que las herramientas que usamos son las mismas ahora.

  • Daniel
    Febrero 10, 2017

    Hola José.

    Yo y mi equipo estamos muy interesados en averiguar cuál es la mejor forma de configurar los entornos de D365O para soportar branching.

    Actualmente todos apuntan a la carpeta por defecto Trunk/Main y estamos versionando los objetos desde todos los VMs hacia esa carpeta en el repositorio de VS Team Services. Aún no salimos en vivo.

    Estamos probando crear nuevas ramas (DEV, TEST, RELEASE), pero nos encontramos que debemos reapuntar las carpetas locales (working folders) a las nuevas ramas creadas, y esto cada vez que necesitamos cambiar de rama para revisar incidentes aquí o allá.

    Las working folders son Metadata (\AosService\PackagesLocalDirectory) y Projects (\Documents\Visual Studio 2015\Projects).

    La otra posibilidad es tener tantas working folders como ramas en las VMs, y cada vez que se quiere trabajar sobre una rama en particular se detiene el IIS, se apunta la carpeta Metadata correcta desde el web.config y se inicia IIS. Además de tener una DB de xRef específica para cada rama.

    En todos los casos, cada vez que se cambia de rama, habrá hacer build y sync completo.

    Podrás sugerirnos alguna otra idea o indicarnos alguna documentación específica sobre VSTS y branching para D365O?

    Gracias!

Comentarios

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sólo se aprovarán comentarios relativos a este artículo.
Para cualquier otra cosa por favor utiliza el formulario de contacto.