Microsoft Dynamics AX 2009 : The MorphX Tools - Version Control (part 1)

Using a version control system offers several benefits:

• Revision history of all elements All changes are captured along with a description of the change, making it possible to consult change history and retrieve old versions of an element.

• Code quality enforcement The implementation of version control in Dynamics AX enables a fully configurable quality bar for all check-ins. With the quality bar, all changes are verified according to coding practices. If the change doesn’t meet the criteria, it is rejected. Microsoft uses the quality bar for all check-ins, which has helped raise the quality of X++ code to an unprecedented level. Microsoft developers cannot check in code with compiler errors, compile warnings, or best practice errors. In the final stages of development, tasks in code (to-dos) are also prohibited.

• Isolated development Each developer can have a local installation and make all modifications locally. When modifications are ready, they can be checked in and made available to consumers of the build. So a developer can rewrite fundamental areas of the system without causing any instability issues for others. Developers are also unaffected by any downtime of a centralized development server.

Even though using a version control system when developing is optional, we strongly recommend you consider one for any development project. Dynamics AX 2009 supports three version control systems: Visual SourceSafe 6.0 and Team Foundation Server, which are designed for large development projects, and MorphX VCS. MorphX VCS is designed for smaller development projects that previously couldn’t justify the additional overhead that using a version control system server adds to the entire process. Table 1 shows a side-by-side comparison of the version control system options.

The elements persisted in the version control server are file representations of the elements in the AOT. The file format used is the standard Dynamics AX export format (.xpo). Each .xpo file contains only one element.

There are no additional infrastructure requirements when you use MorphX VCS, which makes it a perfect fit for partners running many parallel projects. In such setups, each developer often works simultaneously on several projects, toggling between projects and returning to past projects. In these situations, the benefits of having change history are enormous. With just a few clicks, you can enable MorphX VCS to persist the changes in the business database. Although MorphX VCS provides many of the same capabilities as a version control server, it does have some limitations. For example, MorphX VCS does not provide any tools for maintenance, such as backup, archiving, or labeling.

In contrast, Visual SourceSafe and Team Foundation Server are designed for large projects in which many developers work together on the same project for an extended period of time (e.g., an independent software vendor building a vertical solution).

Figure 1 shows a typical deployment using Visual SourceSafe or Team Foundation Server, in which each developer locally hosts the AOS and the database. Each developer also needs a copy of all .xpo files. When a developer communicates with the version control server, the .xpo files are transmitted. A unique ID is required when the developer creates a new element or label. A Team Server, available as a Microsoft .NET Web service, is required to ensure uniqueness of IDs across all the local developers’ environments. The Team Server is a component available with Dynamics AX.

Element Life Cycle

Figure 2 shows the element life cycle in a version control system. When the element is in a state marked with green, it can be edited; otherwise it is read-only.

You can create a new element in two ways:

• Create a completely new element.

• Customize an existing element, resulting in an overlayered version of the element. Because elements are stored per layer in the version control system, customizing an element effectively creates a new element.

After you create an element, you must add it to the version control system. First give it a proper name in accordance with naming conventions, and then click Add To Version Control on the context menu. After you create the element, you must check it in.

An element that is checked in can be renamed. Renaming an element deletes the element with the old name and adds an element with the new name.

Check-Out

To modify an element, you must check it out. Checking out an element locks it so that others can’t modify it while you’re working.

By clicking Tools\Development Tools\Version Control\Pending Objects from the Microsoft Dynamics AX drop-down menu, you can see which elements you currently have checked out. The elements you’ve checked out (or that you’ve created and not yet checked in), appear in blue, rather than black, in the AOT.

Undo Check-Out

If you decide that you don’t want to modify an element that you checked out, you can undo the check-out. This releases your lock on the element and imports the server version of the element to undo your changes.

Check-In

When you have finalized your modifications, you must check in the elements for them to be part of the next build. When you click Check-In on the context menu, the dialog box shown in Figure 3 appears, displaying all the elements that you currently have checked out. The Check In dialog box shows all open elements by default; you can remove any elements not required in the check-in from the list by pressing Alt+F9.

We recommend the following procedure for checking in your work:

Quality Checks

Before the version control system accepts a check-in, it might subject the elements to quality checks. You define what is accepted in a check-in when you set up the version control system. The following checks are supported:

• Compiler errors

• Compiler warnings

• Compiler tasks

• Best practice errors

When a check is enabled, it is carried out when you do a check-in. If the check fails, the check-in stops. You must address the issue and restart the check-in.