Dynamics AX and Version Control

Microsoft Dynamics AX 4.0 has version control capabilities. If you are used to using version control in Visual Studio, you may find some aspects version control in AX to be... let's say "odd."

I don't really want to bash the AX development team because they have done some amazing and wonderful things with AX. The object layering is great. So is the built-in data dictionary with its extended data types and ability to synchronize the schema of the underlying database system. So is the "best practices" checking and unit testing tools.

It is just bewildering that they have been able to implement such advanced features as those and then fudge something as old and established as version control, especially since version control has already been implemented by Microsoft in Visual Studio.

So my first blog about version control in AX is going to be a review of the parts of it that are "different" than what you may be expecting if you are coming from a different environment.

Visual Source Safe
For starters, they tied version control explicitly to Visual Source Safe 2005 and "Source Depot", one of the version control systems Microsoft uses internally. Yes, you can use other source control systems - if you are insane enough to write your own version control class. Considering the built-in functionality is a bit flaky, I'm not going to play Russian Roulette and hope I implemented my own classes correctly.

Come on, AX team! Visual Studio has the ability to work with practically any source control system on the market out of the box. You couldn't consult with them to figure out how to do it? Maybe even crib some code from them, even if you had to rewrite it in X++?

The Team Server
No, that's not "team server" as in Team Foundation Server. That would make too much sense. This refers to a special server Microsoft wants you to set up in order to use Version Control with AX. The purpose? To dispense unique object IDs when developers create new objects. That way different developers won't create multiple objects with the same IDs.

Holy kluge, Batman! This little problem has been solved quite nicely across the rest of the known universe by using GUIDs (AKA UUIDs). Bingo. Now every new object gets a unique ID without the need for some silly ID server. Did they go the "ID server" route because they didn't feel like assigning new GUIDs to existing objects as part of the upgrade process? Because they didn't want to change the data type of object IDs? Bad trade-off, IMHO.

Revision Labeling
Sometimes known as tagging, this feature of source control systems allows you to apply a label to a specific revision of an object (file). This lets you to identify milestones in the code history, identify files that were modified for a particular change, etc. There appears to be no support for this in the Version Control functionality of AX.

This is a shame, since it would have fit in really well with AX projects. You could select all the objects in your project and label them with a work order number, making it very easy to identify which objects should be retrieved from source control to build and deploy the changes.

Instead, you have to switch to the VSS client, find your objects all over again, and label them that way. What a missed opportunity. Maybe they thought the term "label" would be confused with the AX labels used to store string constants?

If they wanted to go way above and beyond what everyone else is doing, they would have included the ability to do branching and merging of AX projects right from the IDE.

Too Many Stinking Messages
Oh boy, does AX like to give you a lot of feedback. The act of checking out an object results in:

1. A dialog box asking "Do you want to reload XYZ?" Which of course really means "Do you want to replace your local copy of XYZ with what is in Version Control?" But they couldn't ask that.



2. An Infolog showing you that AX did indeed update and check out the object. These messages are labeled "just for your information and do not require you to take any action." Oh. Thanks. Can I turn this off?



3. Just for good measure, a separate "Message window" also listing the object you just checked out. Oddly enough, there is no explanation at all. Just the name of the object. I'd like to turn this off too.

Confusing Prompts and Terminology
Operation: Check out
AX Language: "Do you want to reload XYZ?"
Translation: "Do you want to replace your local copy of XYZ with what is in Version Control?"

Operation: Undo check out
AX Language: "Do you want to reload XYZ?"
Translation: "Do you want to revert XYZ to the way it was before you checked it out?"

Operation: Adding an object to Version Control
AX Language: Right click on the object and pick "Create"
Translation: Right click on the object and pick "Add to Version Control"

Halfway Implemented Checked Out Indicators
AX does give you the option of color coding objects that you have checked out (they turn blue). However, it doesn't color code objects that other people have checked out. It would be nice if objects would turn red or have a padlock next to them if they were checked out by other people.
Am I being too hard on the AX team? Possibly. But then again I'm expecting great things from AX!

In my future postings, I hope to cover how VSS is working behind the scenes and what particular problems I've run into using it and setting up daily builds.

Features Business Application Platforms Should Have

There are a lot of software packages that go way beyond being mere applications and become development platforms in their own right. WebSphere Portal, SharePoint, Lotus Notes, and Dynamics AX come to mind.

These "apps" allow you to drastically customize the way they work and add your own functionality. In fact, they probably won't be very useful for you unless you do treat them as a platform rather than a finished app.

Unfortunately, in many cases these business application platforms don't follow through when it comes to rounding out their platform features. Here's a short list of just some of the things that seem to slip vendors minds for at least the first dozen releases.

Application Modes
There are times when you want to take the application down for maintenance or upgrades, and you don't want users to just get a "server not available" message. You should be able to put your application into "Offline" mode. When end users try to access the system they should see a nice message like "The system is currently not available" or a custom message provided by the administrator. Obviously this mode can't be dependent at all on the database and only trivially dependent on the application server.

There are other times when you need to get into the application to make configuration changes or troubleshoot a serious problem, and you don't want end users mucking around with the data or doing real work they may lose. So all applications need an "Admin Only" mode. People with administrator rights should be able to get into the system, but a "not available" message should be displayed to all other users. There should be an option to let end users in with "read only" access.

Deployment and Change Management
It still never ceases to amaze me how, in this Sarbanes-Oxley world, source control and deploying customizations from development to test to production is still an afterthought for many software vendors.

The next time that sales guy is showing you how easily the application can be customized, ask him "where's the deploy customizations button?" and watch the blank stares. If he tells you the changes need to be manually repeated in production, show him the door. If he shows you some convoluted export and import procedure ask for a demonstration that takes 15 minutes or less with zero manual editing of the export file.

Also make sure he shows you how your development environment can be hooked into your source control system. Have him demonstrate labeling (tagging), branching, concurrent checkouts, and merging. If you get more blank stares, show him the door.

Data Refresh
This one would be a huge bonus. You normally want your test, training, and development environments to have data that is fairly fresh. This is rarely a matter of just doing a backup + restore of the production database, since the non-production environments probably have configuration information in the database that is different from the production environment. So having a "data refresh" utility that knows which data not to refresh would be wonderful.

Yes, you can use tools like Red-Gate Data Compare. But that requires you to dig through the hundreds, or maybe thousands of poorly documented tables the vendor has created.

Any vendors that really want to work magic should incorporate data obfuscation so the non-production environments contain data that is "real" but has fictitious values for things like customer names, bank account numbers, phone numbers, etc.