Dynamics AX
  RSS Feed  LinkedIn  Twitter
Want to turn you're data into a true asset? Ready to break free from the report factory?
Ready to gain true insights that are action focused for truly data informed decisions?
Want to do all of this across mutliple companies, instances of Dynamics and your other investments?
Hillstar Business Intelligence is the answer then! (www.HillstarBI.com)

Hillstar Business Intelligence for Microsoft Dynamics AX and NAV on Mobile, Desktop, Tablet

Let us prove to you how we can take the complexity out of the schema and truly enable users to answer the needed questions to run your business! Visit Hillstar Business Solutions at: www.HillstarBI.com

Monday, September 26, 2011

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.:

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!"

Labels: , , , , , , , , , , , ,


Blogger Turner said...

Good post. I would like to point out that TFS is included in the MSDN subscriptions now, so if a company already has an MSDN Subscription they already have TFS. With that said, are there additional costs incurred with having each developer workstation host the entire AX stack?

8:33 AM  
Blogger brandon said...

tfft, Thanks for pointing this out. From an AX License perspective there is no cost for the developers to each have their own AOS. That is something not understood very well.

The largest cost, for developers, typically comes with VS2010. That is sometimes, for smaller and mid-sized companies, an over looked fact during the sale process. Specifically for those clients that are coming onto a Microsoft stack, that maybe have not been so Microsoftish in the past.


9:40 AM  
Blogger tommy.skaue said...

Would be awesome to get this to work with the distributed VCS Mercurial (http://mercurial.selenic.com/). Or even Subversion.

1:35 PM  

Post a Comment

<< Home

Copyright 2005-2011, J. Brandon George - All rights Reserved