Visual Studio and Release Manager

Question

I have been playing around with Visual Studio and Microsoft Release Manager. I have found a couple of behaviors I wasn't expecting and I was hoping someone might be able to confirm these (in case I'm getting the wrong end of the stick).

My goal is to:

1. Host my code in Visual Studio Online.
2. Deploy said code to on-premise or Azure hosted VM, using deployment agents.

My first attempt; using the Release Manager service provided as part of Visual Studio Online. However I found that I wasn't able to connect to Release Manager Online with agents deployed on-premise (or in Azure VMs).

I later found this text at https://www.visualstudio.com/en-us/get-started/release/manage-your-release-vs

You have the following options for managing your releases:

Using Release Management as a service on Visual Studio Online: You need a Visual Studio Online account. You cannot use Chef and you can deploy only to vNext environments based on Azure IaaS services

Using an on-premises server: You need to install Release Management Server; do that here.

This seems to suggest that Visual Studio Online Release Manager cannot use agents - is this correct?

Assuming that is correct, my second attempt was installing Release Manager on-premises (so to speak, it is actually in an Azure VM).

I installed the latest RM versions (server, client, agent) from https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs#d-release-management. Specifically, Release Management for Visual Studio 2013 with Update 4 (12.0.31101.0).

However I found that I was unable to connect the on-premise Release Manager to Visual Studio Online. The error message stating that I must supply the user name in 'domain\username' format - which won't match the online '[email protected]' format.

This seems to suggest that an on-premise installation of Release Manager cannot connect to Visual Studio Online - is this correct?

Thanks,

Answer 1

Okay, there are a few pieces of the puzzle here:

1. The Release Management client has to be on Update 4 (or later, when RM 2015 comes out later this year).
2. If you're using Visual Studio Online, on-prem Release Management cannot talk to it. It's a weird limitation, but there it is. You can hook the RM client up to RM Service in VSO, but that's it.
3. RM Service in VSO does not support deployment agents. It only supports "vNext" release templates, which operate off of PowerShell or DSC scripts to perform deployments.

Agents are, sadly, quickly becoming deprecated in favor of what's termed "agentless" or "vNext" deployments. Microsoft is currently working on totally revamping the Release Management piece, and the next version (which will be released in TFS 2015 Update 1) will not support agents at all.

If you want to use an on-prem RM server with VSO, you have to use RM without the TFS integration. It's still possible to get the bulk of the continuous delivery functionality, it just requires jumping through a few more hoops.

1. You'll have to set your components up as "builds externally" and use an on-prem build server
2. Your RM deployment agents in Azure (obviously) have to be able to talk to your RM server. This could require all sorts of firewall shenanigans, but that's a conversation to have with your networking folks.
3. If you want to do continuous delivery (where a build triggers a release), you'll have to look at the ReleaseManagementBuild.exe file (which is part of the RM client). This tool is responsible for launching releases as part of the build. The "Release" build process templates assume TFS integration, but the ReleaseManagementBuild.exe application has a "package" mode, where you can specify a UNC path to release. This gets you around not having direct TFS integration. It's possible to hack up the build process template a bit to take advantage of this.