Microsoft Release Management is a great tool.Where the ALM workflow previously ended with a Build server package, Release Management now brings the tools to move that package to your environments and deploy it automatically.
If you haven’t seen it yet go check it out and give it a try with the Brian Keller VM.
However, running Release Management in a production environment is different from running it installed on one single virtual machine. In this blog I want to share some info I found while trying to install Release Management in more complex environments.
Release Management Architecture
Release Management has a couple of different parts:
- Release Management Server. This component is installed on your TFS server and is the main part of Release Management.
- Release Management Client. The client tool is for DevOps what Visual Studio is for developers or Microsoft Test Manager for testers. You run it at your local pc and use it to setup deployments and monitor releases.
- Deployment Agent. This tool is installed at the servers you are targeting with your deployments. The Deployment Agent uses a pull model where it contacts the Release Management Server at a specified interval to check if there are new releases. This is done over HTTP(S) to avoid firewall problems.
If all components are installed in the same Windows Domain you won’t have any problems. You can add users that can access the Release Management Client and Service Users for the deployment agents to Release Management and you’re all done.
However, when working with multiple domains things can get tricky. Fortunately, Microsoft has some great people working on Release Management who helped me out.
Connecting the Release Management Client from a different domain
The first thing you should always check whenever you have any connection problems is if you can access the Web UI for Release Management at: http://<rm_sever>:
Now let’s get started with the Release Management client. If you have external customers or internal employees that are not connected to your companies Active Directory Domain, you have two options when connecting a user.
The first option is to use the domain account of the user and add that to Release Management together with the local username:
- Add the domain account for the user to Release Management as both a Release Manager and a Service User.
- Add the username that the user is using on his local pc to Release Management as a Service User (and as a Release Manager if the user should be a Release Manager).
So for example, my local pc is running under an account named Wouter and my domain account is WdK1111. This means that I need to add both WdK1111 and Wouter to Release Management. Make sure to add Wouter without any machine name in front of it. Just add it as a plain username. You also don’t have to create a local shadow account named Wouter.
After configuring these two users, the Release Management server knows about your local machine account and about your domain account. Now you need to configure the client to know about both.
On the client machine, the user needs to add his domain account to the Credential Manager for the URL of your Release Management Server (like tfsrm.
And that’s it. After launching your client it will use the credentials from your credential manager and connect to Release Management with your local, non-domain account.
A second option you have is creating a shadow account on the Release Management machine. This shadow account should have the same username and password as your local pc account. This shadow account can then be added to Release Management and you can give it the appropriate permissions. This option is easier to configure since you don’t need to configure the Credential Manager or use the domain account of the user. A problem with this option is that you need the password of the users local account. If that’s a problem, you could have the user create a second account on their PC that’s solely used for connecting the Release Management client.
Connecting the Release Management Deployment Agent from a different domain
The steps for the deployment agent are similar to those for connecting the client. But instead of using a domain account that’s mapped to a real user, you can create a local account on your TFS machine that can be used as the shadow account for your deployment agent.
- Create an account on your TFS server. For example: DeploymentAgentXXX with a strong password.
- Create the same account on your deployment server and make the account a local administrator.
- Add DeploymentAgentXXX to Release Management as a Service User.
- On the server where you want to install the deployment agent add the DeploymentAgentXXX account to your Credential Manager. Use the URL for your Release Management Server.
- Install the agent and use the DeploymentAgentXXX account in the configuration screen.
And that’s it! Now both your Deployment agent and client can connect even when they’re not in the same domain.
What about a proxy
There was one other situation I ran into. A customer was trying to run the Deployment Agent from behind a proxy. Since the Deployment Agent is initiating the HTTP Request, this is still allowed. However, you can still get the error
“Failed to configure Release management service user. Error: The remote server returned an error: (407) Proxy Authentication Required”.
You can fix this error by adding the following snippet to your app.config file located at Program Files (x86)Microsoft Visual Studio 12.0Release ManagementbinDeploymentAgent.exe.config:
<system.net>
<defaultProxy useDefaultCredentials="true" />
</system.net>
And that’s it! When you get the hang of it, it’s quite easy to setup Release Management and configure all the authentication settings.
Comments? Feedback? Any problems with getting Release Management up and running? Please leave a comment!