Syncing many Dynamics AX instances to a single TFS 2010 Team Project

I have been working with a customer who had been frustrated with the need to have a new Team Project for every instance of AX that they use. In fact with 3 instances per customer and lots of customers it can very quickly get complicated and I wanted to see if there was a solution for them.

---

There is a White Paper for configuring AX 2009 to connect to TFS 2008 which will allow you to get all of the basics right. I suggest you follow that first.

Microsoft Dynamics AX 2009 White Paper: Team Foundation Server Version Control Setup

AX 2009 uses the Team Explorer 2008 API to connect to TFS. You can’t just get it to use the 2010 API, but there is a big push to make this sort of interaction version independent in future versions. However for now, you need to use Team Explorer 2008.

On your AX server, you will need to install the following components:

1. Visual Studio Team System 2008 Team Explorer
2. Microsoft Visual Studio 2008 Service Pack 1
3. Visual Studio Team System 2008 Service Pack 1 Forward Compatibility Update for Team Foundation Server 2010

Once you have these products installed, you can quite happily store the source code for AX Dynamics in TFS 2010 by linking between an AX instance and a Team Project.

This gets you started, but if you are a consultancy that has many clients and you have the usual Development, Testing and Production instances of AX for each client, you can see how this could quickly become difficult to manage on TFS. If you had 10 clients, this would leave you with 30 team projects all linked to different instances of TFS with separate work item queues.

The first things you would need to have done is have a good naming strategy for your projects as you CAN NOT rename a team project. You can see how this could very quickly get messy…

One option to mitigate the work item problem would be to have a single team project for the work items for all of your project. You can categorise them using the “Area” tree and only have AX store the source in the individual Team Projects.

This works pretty well, but still leaves you with 30 odd Team Projects to manage including your single work item repository project.

Solution: Have All your AX Code Under a Single Team Project

There are actually a few ways to configure this, including the way described in the white paper:

1. One Team Project per AX instance (As per the white paper)
2. One Team Project per Customer
3. One Team Project.

Options #2 and #3 are setup in the same way, so I am only going to discuss #3 as it conforms to my previous guidance on when should I use Areas in TFS instead of Team Projects in Team Foundation Server 2010.

Laying out your source in this way allows you to have a single Team Project to manage while keeping each of your Products/Customers separate. it also means that you can easily merge features from a Feature branch into Main and from there create new Release branches that go to the customer.

Tip: If you are only ever going to have one Feature branch that you continue to work in, then you could call it “Current” instead of a feature name.

Let's go back to one of the setting windows for AX 2009.

AX saves a copy of the customisations in a fixed structure to the path specified in the “Repository folder” textbox. This folder is mapped to TFS and it syncs with that mapping.

In this case, if you change the “Repository folder” value to be “c:\Workspaces\Northwind\Product1\Feature1”, then AX will sync with the correct folder and you have no need to have separate team projects for each instance.

Advantages

In addition to those listed in when should I use Areas in TFS instead of Team Projects in Team Foundation Server 2010,

• Ease of branching and merging – Branching and merging can be confusing at the best of times, but without a consistent folder layout, it can quickly become a confusing disaster.

Disadvantages

In addition to those listed in when should I use Areas in TFS instead of Team Projects in Team Foundation Server 2010,

• You need to configure Workspaces carefully – Although this is not difficult, it does add a level of complexity that does not exist in option #1.

Conclusion

The advantages of this approach far outweigh the slight added complexity in setup and will allow a company to manage all of their source under one roof. They can also easily move work items from one project to another and make it easy for developers to identify where they are working and what effect it will have without them having to refer to documentation.

Ultimately keeping everything under a single format across the company regardless of team or topic allows everyone to understand the source and the impact of changes a little better. And that is never a bad thing…

<iframe marginwidth="0" marginheight="0" src=""http://ads.geekswithblogs.net/a.aspx?ZoneID=5&Task=Get&PageID=31016&SiteID=1"" frameborder="0" width="1" scrolling="no" height="1" />