This is the ninth post in my series on building a continuous delivery pipeline with TFS and I’m going to be covering the installation of Release Management for Visual Studio. This is the component of the TFS ecosystem that gives us reasonably straightforward tooling to deploy the components of an application to target servers and to carry out other activities such as running automated acceptance tests. If you are new to Release Management, be sure to check out my getting started post here. There are quite a few blogs that describe the detail of how to install Release Management and so I’m not going to give a blow-by-blow account in this post. Rather, I’ll provide some big picture details and discuss how whichever installation instructions that you end up referring to will need to be tailored for our all-in-one TFS server installation.
Release Management Components
The first thing to understand about Release Management is that there are three components: server, client and deployment agent. The deployment agent is installed on machines that are targets for code installations or tasks that need to be run as part of the delivery pipeline (running automated acceptance tests for example). The client is typically installed on developer workstations and is used to build and manage the delivery pipeline. The server component is, as you would expect, at the centre of everything. The server component is actually split into two main pieces – a SQL Server database and a collection of web services. In a production environment, some thought will need to be given as to where these pieces will live. The database is probably fine sitting alongside the other databases that are part of the TFS ecosystem, however the web services component is a possible candidate for running on its own server depending on your organisation’s attitude to keeping applications separate. It will certainly sit alongside the TFS web services very happily and that’s how we’ll do it here. In a production environment, you will also need to think carefully about what service accounts you employ – do you want Release Management running under its own account for example? Here, we’ll keep things simple and use the TFS service account to run the Release Management service and a dedicated account for the deployment agents.
Server Installation
The official installation guide for Release Management can be found here and the MSDN guidance is here. For a more visual approach, Martin Hinslewood has a nice YouTube video.
The first difference between Martin’s video and our installation is that for the server component Martin is specifying Network service as the identity to run the Release Management services whereas we’re going to be using the TFS domain service account (TFSSERVICE if you are using Microsoft’s example name). Other than that, the installation of the server component should be straightforward because everything is being installed on the same server (ALMTFSADMIN in my case).
Client Installation
The configuration of Release Management is done through the client and that’s the next bit of the installation. Martin’s video shows the client being installed on the same machine as the server and although this isn’t an absolute requirement, you will need to do this if the account you used to install the server is different from the account you will use to run the client on a different machine since this account will need to be added to Release Management in order to authenticate. So, go ahead and install the client on the server machine and note that connecting is very easy since the URL can simply be localhost:
Initial Configuration
After dismissing the dialog with the OK button, the Release Management client (a WPF application) opens. There are probably two areas to look at as part of the initial configuration. The first is to make a connection to TFS from Administration > Manage TFS. Click on the New button and supply details as follows:
You will need to verify the connection details before you can Save & Close, after which you will see your connection listed. It’s worth noting that you can have multiple connections to TFS and you will need to take advantage of this if for some reason you have more than one Project Collection.
The second area you may want to look at now is Administration > Manage Users, particularly if you will run the Release Management client using a different account on a different machine in which case you should add that account and give it the Release Manager role. Note that if you fill in the email details you will have had to have filled-in the SMTP Server Configuration details in Administration > Settings > System Settings for emails to be sent. On Azure, the easiest way to make this work is to sign-up for a free SendGrid subscription and fill in the SMTP details thus:
At this point, it’s probably a good idea to install the client on your developer workstation to check that there are no connectivity or authentication problems. The install will differ slightly from above since you will need to specify the Release Management server name for the URL which should be something like http://almtfsadmin:1000.
And There’s More…
Although I mentioned earlier, that there is a third component (the deployment agent) that needs installing, we can’t do that yet because we haven’t created any servers that will be targets for code deployments. In the next instalment, we’ll do just that!
Cheers – Graham
The post Continuous Delivery with TFS: Installing and Configuring Release Management appeared first on Please Release Me.
