Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Tagged as

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

, 8 Oct 2010 CPOL
Rate this:
Please Sign up or sign in to vote.
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.

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.

image

Figure: Select the TFS server and the local workspace path that is bound to your TFS Team Project

image

Figure: Set the Server name and the Team Project name

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

image

Figure: Using Area to categorise your work items in a single Team Project

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.

image

Figure: Ideally map to sub folders

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.

image

Figure: Main Branch hierarchy should be replicated for each 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.

image
Figure: The Repository folder links to a TFS Mapped folder locally

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.

SNAGHTML990c33

Figure: Cheating AX into mapping to a specific folder

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…

Technorati Tags: ,,,

<iframe src="http://ads.geekswithblogs.net/a.aspx?ZoneID=5&Task=Get&PageID=31016&SiteID=1" width=1 height=1 Marginwidth=0 Marginheight=0 Hspace=0 Vspace=0 Frameborder=0 Scrolling=No> <script language='javascript1.1' src="http://ads.geekswithblogs.net/a.aspx?ZoneID=5&Task=Get&Browser=NETSCAPE4&NoCache=True&PageID=31016&SiteID=1"></script> <noscript> </noscript> </iframe>

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Martin Hinshelwood
Instructor / Trainer naked ALM
United States United States

About the Author: Martin has worked with many customers in government, finance, manufacturing, health and technology to help them improve their processes and deliver more. He provides management and technical consulting that intends to expose processes and practices to gain transparency, uncover impediments to value delivery and reduce cycle-time as part of an organisations path to agility. Martin is a Professional Scrum Trainer as well as a Visual Studio ALM MVP and Visual Studio ALM Ranger. He writes regularly on http://nakedalm.com/blog, and speaks often on Scrum, good practices and Visual Studio ALM.

You can get in touch with Martin through naked ALM.

Follow on   Twitter   Google+

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.141220.1 | Last Updated 8 Oct 2010
Article Copyright 2010 by Martin Hinshelwood
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid