When you develop a new solution, it’s useless until you deploy it to a production environment where users can actually use it. Before you can do it, you typically need a few extra deployments to test environments. It takes time that people could use for working on new features and it often require many manual steps, which is always error-prone. Automation can both save resources and prevent people from doing something wrong. The need is getting more urgent as release cycle shorten to deliver new features to users as soon as possible.

Release Management for Visual Studio can help you to do that. It allows you to define the release process and approvers, execute deployments, track their history, send email notifications and so on. You still have to define what steps will run and what they’ll do; the value of Release Management is in handling all the infrastructure around.

I spent some time preparing releases of Dynamics AX with Release Management for Visual Studio 2013 and 2015. Unlike Kenny Saelen in his blog series, I used so-called vNext release templates, which is a more lightweight approach, doesn’t require deployment agents and it uses either Powershell or Chef to handle all release tasks (here is documentation, if you’re interested).

I was a bit disappointed, because it lacked quite a few features I needed, especially VSO support for on-premise environments. Also diagnostics of release tasks was quite difficult and a few other things just didn’t behave as I would like.

Therefore I was really keen to jump into a preview version of the new Release Management, which promised to address several of my problems, and I’m happy to announce that it does. It doesn’t do everything I would like (at least not yet), but it’s a great improvement.

Let me demonstrate the basics on a simplified release of Dynamics AX. The project uses Visual Studio Online as the version control and XAML builds running on an on-premise server.

You don’t need your own Release Management server for on-premise deployments anymore; it’s all hosted in Visual Studio Online. You can find it on the Release tab, but currently (October 2015) only if you’re participating in the preview program.

When you create a new release template, you have to define one or more environments. Then you can manage and track how far you’ve released your code, such us that it’s currently in the FAT environment.

You need some tasks to do the actual work. As you can see, you have quite a few tasks to choose from:

Nevertheless my AX release is implemented completely in Powershell (I just slightly modified my existing scripts, based on DynamicsAxCommunity module), therefore I don’t use any other type of task:

To get files to deploy, link the release definition with an artifact source. In my case, I linked it with a team build, therefore my release will get all files produced by a particular build.

Here I ran into a limitation, because my release scripts are not in the same team project as my AX code and I can’t easily link artifacts from other projects. That’s why I’ve put scripts to my environment and refer to them through absolute paths (\\Server1\RMScripts\…) accessible from all machines. If I could link artifacts from two projects, Release Management would download release scripts for me.

When triggering a new release, I can choose which build contains application files to deploy. I could also configure it to run automatically after a build (such as deploying a test environment immediately after a night build of latest code).

You can track progress of your release directly in your browser, including output from your tasks (such Install-AXModel and axbuild in the picture below). It’s wise keeping tasks relatively small, so you can easily see what’s running (or what failed, in a worse case).

You need an agent installed in your environment, to handle all communication with VSO and execute tasks. Tasks can connect to other machines and deploy things there, therefore you may have a single agent deploying to dozen servers. On the other hand, you may want more agents, to running multiple releases in parallel or having agents with different capabilities (such as different software installed).

The agent can run as a Windows service, but you can also start it as a normal command-line application and monitor what it does.

And of course, you can see history of all releases, their status, logs and so on.

Although it’s still in a preview stage, it already runs really well. And because it’s so lightweight and allow integration of Powershell scripts with just a few clicks, I think I’ll use it even for small things that didn’t require any sophisticated solution before, but that will benefit from being easily available to the whole team and from archiving history of all runs.

The new Release Management is expected to be released this year; unfortunately I don’t know anything for specific in the moment. In the meantime, you can learn more about it from documentation on MSDN.