Version control in MorphX

Posted By: mfp | Dec 19th, 2007 @ 4:40 AM | 6,163 Views | 6 Comments

Formats:

This screencast is a preview of the version control system integration options in the next release of MorphX - the IDE of Dynamics AX.

It shows a side-by-side comparison of the integration options with Team Foundation Server, Visual Source Safe, and MorphX VCS.

The latter is a simple, yet powerful alternative without any additional infrastructure requirements. The last half of the screencast gives a demonstration of MorphX VCS.

Tags: Dynamics, Dynamics AX, Microsoft Dynamics AX 2009, Team Foundation Server

Rating:

thensley

Thank you for the sneak peak! And thank you for the Team Foundation Server support!

Can you elaborate on the concurrent checkouts (particularly merging check-ins).

Also, can the "Change List" be identified later on the Team Foundation Server side so the change set can be fetched for deployment or building on a test server?

The biggest problem we've had with using version control is that it provides absolutely no help in deploying our changes in a controlled manner.

For example, we make a new project for each Change Request we get from our users. From the VCS side it is impossible to identify which XPO files belong to an AX project. We also haven't found a good way to identify which versions of objects have been deployed to our test and production systems, and which versions in VCS have been tested and marked as "approved" for deployment.

If you look at an object in the AOT of your production AOS, is there anything that identifies the version # from the VCS that was deployed? I'd like to be able to look at an object in production and see that it corresponds to version "n" in our VCS.

And would you guys PLEASE consider using GUIDs for object IDs and ditching the "Team Server" entirely? It makes development very difficult when we have partners and remote developers who don't want to be VPN'd to our network just so they can be connected to the team server.

mfp
mfp

You are very welcome.

With regards to multiple check-out nothing new is added in 5.0. VSS in 4.0 already supports this, if you enable it in the VSS Admin tool. The way it works is that the version control backend will automatically attempt to merge the files. In most cases it succeeds and both check-ins succeed. In cases where the exact same lines has been modified the last check-in is rejected. The developer then has to resolve the conflict manually, and check-in again.

Keeping track of versions across installation can be difficult. Even more so if you use XPO files as a way of deploying. I strongly recommend only using AOD files. In combination with a VCS it requires a build step. In the next update of the documentation on MSDN we will release a documentation on how to setup an automated build procedure. Using an AOD file you can stamp each version with a build number, and you can label (VSS term) your VCS files with the build number. Then you know what you got at all times, in every environment.

Regarding IDs, *sigh*, we know. What I can promise is we will address this in the very near future after 5.0. If we don't Microsoft will be out-of-IDs very shortly. Wink

If the solution will be GUID based or not is still not decided. The other obvious alternative is NAME based - like .NET and C#.

sturlafr

This is truly a powerful feature and has been needed for a long time. It will definitely be very useful to solution development in Dynamics AX but also for implementation projects and make it much more easy to maintain the customized customer applications. At least as I see it.

However I’m curious to know if the MorphX VCS functionality is all together hidden inside the kernel or if it will be possible to hook in to these VCS events (like check-out/in etc.)?

mfp
mfp

The version control system can be fully controlled from X++. In fact the kernel has no knowledge about which provider is used (VSS, TFS or MorphX).

In the AOT you will find the VersionControl class, it has methods like checkin, checkout, undoCheckout. These can be customized like you normally do in MorphX.

The documentation for this class on MSDN will (eventually) be available here:
http://msdn2.microsoft.com/en-us/library/aa843010.aspx

mowgli

Hi there

Hope you are still watchin this blog.

Good news about a build-in VCS - it seems like the right configuration for my company - except for one thing !

It seems that version control on each object is optional - you have to manually enable it - per object !

I would like to have version control enforced - period - so that no developer can edit anything in the AOT, without a trace to who did the change, and when.

Is this possible ??

ddjong

Hi,

Commenting on Thensley's remark:

In reply to {0}

Download:[Pending]

Thank you for the sneak peak! And thank you for the Team Foundation Server support!
Can you elaborate on the concurrent checkouts (particularly merging check-ins).

We are using TFS2008 with AX2009 and the straight forward issues are working great (check-in, check-out, ...), but it would be good if AX provides built-in (context menu) options for conflict resolving. You can check with eclipse (subversion), that also has perfect conflict resolving facilities.

Areas where we face problems are:
- concurrent check-outs and how to resolve
- if you are working at home without ADSL connection, the TFS integration gets automatically lost and no checks are done anymore. In fact it is like working without TFS integration. You are allowed to do changes that are not tracked.
- we work in distributed environment (partially India, partially Europe). Team server is in NL but it consumes to much band width to be continuously connected and performance in AOT is bad when having TFS remotely. We need to find a way to keep a thin line between the ax installation and the TFS instance.

Regarding the GUIDs. Whatever identification you use, it must not be numeric IDs. In my previous job, we had the same issue (developing collaboration platform) on how to identify objects. We have choosen for GUIDs internally but name-based externally. The problem internally is to update many references if you change the name. But ultimately i would really like to have proper names (including name spaces!!!) for each component. That will also prevent naming conflicts in the field (when deployed).

rgds.