AX 2012 & TFS 2010, along with other Version Control Options

One of the area's that companies look at when talking about Microsoft Dynamics AX 2012, revolves around the software development lifecycle. (SDLC). As part of this conversation, and decent amount of focus is around version control. This is a key critical part, to any true SDLC process, and that's a true statement for Microsoft Dynamics AX.

With the release of AX 2012, there are several options, which are covered in the following article on MSDN: MSDN: Version Control System [AX 2012]

With this, we see that four options exists for us: MorphX VCS, Visual Source Safe (phasing out though), Team Foundation and finally third party VCS systems. It's worth noting that Microsoft recommends either TFS or MorphX VCS.

Like all things, I want to caution in this area about getting over focused on the SDLC used for managing, say, pure .Net development efforts, or others that might be employed at a company today. AX 2012 are business projects, not pure technical development. This means, that as my broken record self continues to state, Value should drive decisions for AX 2012, not technology.

With that stated, lets look at the point, process and value that using version control affords us in a given implementation project. Like all topics relating to AX 2012 implementation projects, the size of the company, and therefore total scope and size of the implementation typically help dictate choice. Does it make sense for a two developer, smaller mid-sized company to invest in TFS? I would think not, therefore, the preferred option, based on Microsoft recommendation is MorphX VCS.



With this option, a shared development environment, that a majority of Dynamics AX projects use, is the need. Here, developers connect their clients into a shared environment and MorphX allows for checking out, checking in, and history for artifacts that are developed, touched, etc. from within AX 2012. This can leave gaps, however for certain Visual Studio project types, that might complete the entire solution for a customer, that can't be added to the AOT.

A Typical environment, for such a use of MorphX version control, then would look like the following.:



That's a very straight forward total AX solution for a given company, and one that most small to mid-sized companies would find gives them a lot of value, and ability to have version control, without a lot of overhead.

With that said, it's not really a suitable solution for a larger mid-sized, and of course moving into the enterprise space. Here there needs to be an enterprise class collaboration solution that enables version control, among other possible benefits. Enter, Microsoft's main focus for this area, and solution addressing such needs, Team Foundation, or TFS 2010.



With this option a lot of new possibilities exists, specifically around AX 2012 and TFS. This includes the ability to offering branching now, which did not exists as an option for AX 2009. Also, the ability, in a limited fashion, to make use of work items and tie those to the check in process for artifacts. Let me say, there has been some great improvements for TFS and AX 2012, in terms of setup, administration and reduction of headaches that come with both those topics.

In the past, with AX 2009 and TFS, someone once told me.: "If you want someone to really hate their job, make them setup AX 2009 and TFS." Now, that's a little over the top, but there are some issues that are caused, specifically around the need for an Object ID management server. That however, no longer exists in AX 2012 and TFS integration. The ability, to quickly setup TFS integration with AX 2012 has improved a lot, and that alone will add value to any AX 2012 project that needs this requirement.

In order to properly use AX 2012 and TFS, this changes the dynamics of the development environment. What now needs to exists, is that every Developer needs their own development workstation. This needs to have all aspects of AX 2012, SQL Server, SSRS, SSAS, EP, AX Client, VS2010, etc. etc. In doing this, then each developer instance connects with a TFS repository, for checking in and checking out project artifacts. What the use of TFS also brings to the table, as a pro, is the fact that outside project artifacts that don't belong, or can't be placed within the AOT of AX, can use the same VCS as the AX projects and artifacts uses.

In this type of scenario, the following is typical of what you might see.:



With this specific setup, you will notice I've added a Release Manager role to the workflow. This is actually very critical to understand, and a point that should not be taking lightly. By no means should you ever try to automate the deployment of AX artifacts throughout the different environments of AX. There needs to be some human workflow, in the promotion from TFS into the rest of the environments, down through production. This is a very critical point, and this will save you time, and effort, on something that quite frankly for ERP projects, automated builds add very little value. Post go live scenarios might one day, possibly, make sense, but this is still hard to really justify. making sure this effort takes place, will ensure that the correct artifacts, and merging of objects takes place and issues can be addressed, instead of forced down the line.

With this information, we can see that there is great possible value add to AX 2012 projects, through the use of MorphX VCS or integrating AX 2012 with TFS 2010. Keep in mind, simple is king of value, and use that as a guide when planning for anything in AX, including this topic. With that, there are some great resources on the web, from fellow bloggers, and MSDN, relating to this topic. I will share them below here.:

• Version Control Setup for Microsoft Dynamics AX [AX 2012]
• How to: Connect Microsoft Dynamics AX to a TFS Proxy [AX 2012]
• Linking work item when checking in (AX2012)
• Daxmusing ALM / TFS Page

Microsoft is also expected to release a new whitepaper, very soon, on this topic of AX 2012 and TFS 2010. Once it's out, I will make sure and link to it, and give my thoughts. I hope you have found this entry useful!

That's all for now, till next time!

"Visit the Dynamics AX Community Page today!"

Integrating Third party VCS with Dynamics AX 2009

Just over a month ago, Microsoft released a new white paper which talks you through how they integrated Team Foundation Server, TFS, into Dynamics AX.

That white paper can be found here.:
Microsoft Dynamics AX 2009 White Paper: Integrating a Third Party Version Control System into Microsoft Dynamics AX 2009

"The MorphX Integrated Development Environment (IDE) can integrate various Version Control Systems (VCS). Team Foundation Server (TFS) is a newly integrated VCS with the MorphX IDE in Microsoft Dynamics AX 2009. This document provides detailed step-by-step instructions to integrate a VCS with the MorphX IDE, by using how TFS was included in Microsoft Dynamics AX 2009 as an example.

The Version Control Extensibility Framework was refactored in Microsoft Dynamics AX 2009, which is now used by the integration with TFS."



In looking at this I started looking around for cloud based VCS software, that was similar to Visual SourceSafe, and already integrated to work with Visual Studio. I came across the following.: www.DynmaSoft.com The product they have can be hosted in the cloud, on-premise, and has a published COM based SDK.

It already integrates with Visual Studio, and that was key for this, because in most Dynamics AX solutions, with 2009 and beyond, Visual Studio solutions and projects are very much a part of the Source Code that make up a given AX implementation.

So with this in mind, I started to dig a little deeper in what would it take to integrate this DynamSoft product into Dynamics AX.

After looking into this, I found of course you will need to sign up for at least a free account. Next you will need to download the following two items.:

• SourceAnywhere Hosted Server Manager - To remotely manage the users, groups, access rights and other configurations of the hosted server.


• SourceAnywhere Hosted COM SDK

After getting these two, of course make yourself familiar with the COM SDK, and then go through the steps listed in the Microsoft Whitepaper for enabling DynamSoft cloud based VCS with your given Dynamics AX instance.:

• 1. Add a new class that represents the VCS and implements the sysVersionControlFilebasedBackEnd interface.


• 2. Add a new base enumeration value to the SysVersionControlControlType base enumeration type. For TFS, the SysVersionControlTfs base enumeration value was added.


• 3. Add new class construction logic to the newType method of the SysVersionControlSystem class.


• 4. Implement the VCS setup methods. These methods are the bootstrap methods that are responsible for initializing the backend instance. Therefore, they must be implemented for each VCS.


• 5. Implement the basic VCS operation methods in the new class such as the fileGetVersion, fileSetCheckIn, fileCheckout, fileAddToVersionControl, and fileDelete methods.


• 6. Use the advanced VCS methods to implement additional VCS features. The framework also defines a list of runtime surrogate methods to let the VCS notify the framework whether these features are supported by the VCS. These features are optional.


• 7. Implement the plumbing methods that are required by the framework.

I have plans to now take the above information, a free account and actually develop this and place in an XPO project for sharing. I wanted to get this out here though, making this a part 1 in this series, to help bring into focus Change Management possibilities that exists with Dynamics AX, specifically related to VCS options.

With what Microsoft has given us here, we now have the ability to really integrate Dynamics AX 2009, with near any VCS solution we desire. Be that Cloud based, on-premise, Custom, Open Source, or purchased.

I think this shows the flexibility of Dynamics AX, and also gives customers choices in their VCS options.

There is something technical you need to keep in mind, in regards to VCS solutions with Dynamics AX. This is designed so each developer has their own AOS installed on their developer workstation.

With what we have in this white paper, however, we have the ability to create a server side integration into a VCS that will work, with having a single AOS and 1 to 1,000+ developers! I will save that for a later post on this subject.

Hopefully this post has you thinking, and hopefully you have plans or already have in place change management policies, that include management of code.

That's all for now, but check back soon as more to come!




"Visit the Dynamics AX Community Page today!"

Microsoft Dynamics AX 2009 White Paper: Using the Version Control Integration with Microsoft Team Foundation Server

One of the topics that a lot of customers need to be really thinking about, and sometimes is not part of the initial project implementation, is Source Control, Version Control --- Control over the development of Dynamics AX objects and projects, the a Version Control System.

Microsoft has a great product, called 'Team Foundation Server'. Team Foundation Server, offers different levels depending on the need of the customer, and is not just a run of the mill VC solution.

If offers planning, control, documentation, BP, guidelines, branching, promotion options, and allows different role types to view a given project or set of projects in the manner best suited, and allowed for them.

With Dynamics AX 2009, you can actually take and make use of Team Founcation Server, with your instance to help gain control and governance over the development and lifecycle of your given Dynamics AX investment.

A very good white paper, that was release this past July, talks in details about this. That is the following white paper.:
Microsoft Dynamics AX 2009 White Paper: Using the Version Control Integration with Microsoft Team Foundation Server



The above image shows the Object Lifecycle when making use of TFS integration within Dynamics AX.

So this offers an amazing amount of power. The only draw back, for smaller shops, is the fact that each developer machine, must have their own AOS. So if you have 10 developers, then that's 10 AOS licenses, you will need.:

Developer Machines
Each developer machine should have:

• Microsoft Dynamics AX 2009 Developer installation (with AOS)


• Microsoft SQL Server (local or remote)


• Local repository folder


• Visual Studio Team Explorer (optional)

There are other options, but for a shop that wants to get the most out of their investment for Dynamics AX, even having an AOS per developer, does not cost that much in the scheme of things. When your talking about your enterprise business platform!

That's all for now, check back soon as more to come!




"Visit the Dynamics AX Community Page today!"