When building a deployment procedure, there is a point that can cause quite intense discussion. How do we prevent code that is not ready for release from being released?

There is no easy way to shelve code in AX, and many would panic at the thought of synchronizing to the tip. We can create a branch and update the VCS settings with this branch, but we can't easily merge this back into the main branch after release.

The solution we use is to create shelvesets. In order for this to work, there are some dos and don'ts; this is the list that we use:

Let's say we have two pieces of work in progress, and one is not ready for release. We can check in the code that is ready and create a shelveset within Visual Studio for the code that should be shelved. We can then synchronize the code with TFS in AX to remove the shelved changes. To check for regression, we would run a full compile and rerun our test cases. The full compile is required as the p-code for a shelved method may still be there, and a call to this shelved method may actually still work! This has caught many out when they say, "It worked in my environment!" only to find that recompiling the affected objects highlights the problem as being a compilation error.

We can bring the shelved changes back into our repository after the release has been done and synchronize AX with TFS.

Once all releasable code is checked in, we create a build that we can then release to the appropriate environment, such as a user acceptance test server.

We may also need to remove the checked-in code; a useful trick is to check out the elements and create a project from the Pending Objects form in order to export it. You can then revert the changes as required, create the release build, and eventually, reimport the XPO after the release is done.