In this post, I’m going to walkthrough how to set up Release Management for the first time. This will include installing and configuring the Release Management Server, the Release Management Deployment Agent, creating an environment, and deploying our favorite application from Microsoft, Tailspin Toys.
Release Management Server
Much like the installers for the rest of the Visual Studio suite, we can just run the setup executable, and all the configuration steps occur after the installation. Because of this, I’m going to skip over the installations as they are merely agreeing to the fine print and clicking Install. Once installed, run the Release Management Server for Team Foundation Server 2013. This will pop up a window that lets you configure which account to run the service as, which web service port to use (1000 is the default port), and which database server to use.
Figure 1: The configuration for the Release Management Server
Fill out the account that you want to run the server as, which database server to use (I used my TFS database server), and then click Apply Settings.
Figure 2: Configuration summary of a configuration succeeding for Release Management Server
The configuration summary, and whether or not the configuration succeeded, will then be displayed. The configuration dialogs can now both be closed.
The next thing we need to do is connect the server to TFS. To do so, install the Release Management for Visual Studio 2013 client (it is as simple as accepting the terms and clicking install). Once installed, go to the Administration tab and select the Manage TFS link.
Figure 3: Administration –> Manage TFS –> New to create a new TFS connection
Click the New button to bring up the TFS configuration window.
Figure 4: Verify the connection and click Save & Close
Fill out the appropriate information, and once done click the Verify link.
- The account you use here must be a part of the Team Foundation Service Accounts group. The only way to add a user to that group is to use the command line tool TFSSecurity.exe. The executable is located here:
- C:\Program Files\Microsoft Team Foundation Server 12.0\Tools
- The command to run is:
- tfssecurity /g+ “Team Foundation Service Accounts” “<account>” /server:http://localhost:8080/tfs
- <account> is the account you want to add to the Team Foundation Service Accounts group
Once verified, you can Save & Close the configuration dialog. This configured the connection to TFS itself. The Release Management server is now ready to go. The next thing we need to do is install the Release Management Deployment Agent to the machine(s) we want to deploy to.
Release Management Deployment Agent
Again, much like the Release Management Server, the deployment agent is installed by merely accepting the terms and clicking the install button. The configuration occurs post install, so when the install completes, open the Microsoft Deployment Agent 2013 to configure it appropriately.
Figure 5: Configuration page for the Microsoft Deployment Agent 2013
Again, fill out the account to run the agent under as well as the URL for the Release Management Server (which we specified in the previous section) and click Apply settings.
Figure 6: Configuration summary of a configuration succeeding for Microsoft Deployment Agent 2013
We are now ready to add the server to the Release Management Server through the client application. Open the Release Management client, go to the Configure Paths tab, and click on the Servers link.
Figure 7: Scanning for new servers to add to the Release Management Server
Click the drop-down for New and click the Scan for New button. This will show the server that we just installed and configured the agent on.
Figure 8: Choosing the server to register with Release Management Server
Select your new server and then click Register & Close. The deployment server has now been added to your Release Management Server and can be used to deploy different things to.
- I got a Deployer Error after this registration.
- Deployer Status: Offline
- Deployer Error: Deployment Agent has not communicated with the Release Management server. It may not have been installed yet.
- Reapplying the configuration settings to the Microsoft Deployment Agent 2013 fixes this issue. After reapplying, click the Refresh button on the Servers page and the error should go away.
Figure 9: One server registered with Release Management Server
The deployment server now has an agent running on it, and has also been added to the Servers available for the Release Management Server.
Stage Types & Technology Types
Stage types are what we define as the stages the deployment must go through. For instance, we may have the stages Dev, QA, and Prod that a deployment could go through. Another set of stages might be, Dev, QA, UAT, PreProd, and Prod. These are totally dependent on what stages your application must go through in order to get to production. For my environment, I’m going to create the following Stage Types: DEV, QA, and PROD.
To do this, open the Release Management client, go to the Administration tab, and then click the Manage Pick Lists link.
Figure 10: Add new Stage Types to Release Management
Click the Add button to add new stage types, and then click the Save button to save them.
Technology types are types of technology that can be associated to a server that is registered in Release Management. These are useful so one can determine where a certain package can be deployed to, without have to hard-code the correct path into the automation. For instance, I can specify IIS, ASP.NET, MVC 4, and SQL on one machine and know that, that machine has those dependencies on it. Again, these are manual and requires management and are not tied to any specific configuration on the server themselves. You can easily associate SQL to a server that does not have SQL installed on it.
Figure 11: Technology Types that have been added to Release Management
To add Technology Types, select the Technology Type on the left and use the same steps that were used in adding Stage Types.
Now, we need to set up an environment in order to deploy Tailspin Toys. I’m only going to create one environment for now – DEV – in order to start my Release Management process. To do so, open the Release Management client, go to the Configure Paths tab, and select the Environments link.
Figure 12: Create a new environment
Click the new button to create a new environment. We are going to want to use the server that we previously registered.
Figure 13: Configuring an Environment
Enter the details that you want to have associated with the Environment. This includes the name, owner, description, notes, etc. Once done, click the Link Existing button to show existing servers that you can add as part of that environment. Select the server that we added in the last section and then click the Link button.
Now, click the Supported Technology Types tab to select the technologies that are available on this server.
Figure 14: Selecting technology types for a specific environment
The third tab, Stage Type Security, will determine which stage(s) the environment can be used for.
Figure 15: Selecting the right Stage Types for my DEV environment
This is my going to be my DEV specific environment, so I’m only going to allow it to be used for the DEV stage type. I’ve unselected All Stage Types and added a new one for DEV and selected it.
Once everything has been configured correctly, we can click the Save & Close button. We have created an environment called DEV which is linked to a server, has specific technologies in it, and can only be used for the DEV stage type.
Release paths are the paths through the different stages an application must go through. This is where we define a release path for an application and are able to put in information around:
- The stage
- The environment
- Whether the acceptance step is automated and who is the approver
- Who is the owner of the deployment step
- Whether the validation step is automated and who is the validator
- As well as putting zero, one, or many approvers for the DEV step.
To create a release path we need to open the Release Management client, go to the Configure Paths tab, and then select the Release Paths link.
Figure 16: Create a new Release Path
Click the New button to open up the dialog to create a new Release Path.
Figure 17: Configuration for a Release Path
Give your Release Path a title, description, and then add the stages that you want. For each stage, you need to specify the stage (which is defined by the Stage Types we created earlier), the environment (which is dynamically filled depending on which stage you choose), who the approver is, who owns the deployment, who is the validator, and whether, or not, the acceptance and validation steps are automated.
You will note that I only have one stage. This is because I’m only going to be setting up my DEV stage with my DEV environment. Because I specified that my DEV environment can only be used for my DEV stage, the environment will show up if I select a stage that is not DEV. You can use the DEV environment for every stage, or you can use different environments.
Components are the different packages that will be deployed using Release Management. For instance, I have a web site and database that I want to deploy for Tailspin Toys. Therefore, I have two components (Tailspin.Web and Tailspin.Schema). We will create components that will target these different components and specify how to deploy them.
The first thing we will be doing is deploying the database. Since the Tailspin Toys project is already a SQL Server Database Project, a dacpac is already created during an automated build. Here’s more information on data-tier applications. In essence, dacpacs are artifacts that can be used to deploy databases. They will automatically create the database if needed, or run an upgrade on a database that already exists. The Tailspin Toys database project has a post-deployment script that runs to import a bunch of data for the website itself, so we are going to be recreating the database on every deployment.
To set up a component for Tailspin.Schema, go to Configure Apps, Components, and then click New.
Figure 18: Component information about Tailspin.Schema
We will want to fill out the name of the component (Tailspin.Schema will be the name of my component) as well as where to get the package. All of the Tailspin Toys components are being built together, so I chose Builds with application and then use the root folder as the path to the package (to choose the root folder, merely put a ‘\’ into the text box).
Figure 19: DACPAC Database Deployer configuration
The next thing we need to do is to choose the deployer tool and set up the arguments that need to be filled out when running the deployment. For Tailspin.Schema, I chose the DACPAC Database Deployer which will deploy the dacpac using sqlpackage.exe. Most likely, you will not need to modify anything beyond choosing the DACPAC tool, but since there is a post deployment script that runs, and will fail if there is already data in the database, I added a property to the deployment to create a new database during the deployment (essentially drop the old one and create a new one). To add a parameter, you merely need to put two underscores before and after the parameter name in the Arguments window. This is a wildcard that Release Management picks up to automatically make it a parameter.
Once done, we can hit Save & Close. This will save the Tailspin.Schema component, and we can now move onto the Tailspin.Web component.
The web component of Tailspin Toys will be done a little differently than the database portion. Go ahead and create a new component for Tailspin.Web by going to Configure Apps, Components, and then clicking New.
Figure 20: Component information about Tailspin.Web
Again, we are going to give it a name (Tailspin.Web will be the name this time) as well as where the package will be. By default, web sites are going to be dumped into \_PublishedWebsites\<WebsiteName> during a team build. So, Tailspin.Web is going to be located at _PublishedWebsites\Tailspin.Web and it will be part of the Builds with application text box. Once done, we can move onto the Deployment tab.
Figure 21: Deployment configuration for Tailspin.Web
This time, the tool will be the XCopy Deployer. It comes with only one argument by default, and it will be the only argument that we will need. The installation path will be filled out when we are creating our release template. This is all we need to define in order to be able to deploy Tailspin.Web as a component. Once done, go ahead and click Save & Close.
The release template is really tying everything else we have done together. This is where we choose our release path we want our releases to move along, as well as the workflow in which we want to deploy our components. To create a new Release Template, go to Configure Apps, Release Templates, and then click New.
Figure 22: Release Template properties for Tailspin Toys
The first thing that pops up is the properties for the new release template. Fill out the name, choose the release path that you want (I created TailspinToys as a release path earlier in this blog post), and then choose the build definition that the packages will be pulled from. Once you have chosen your configuration, click the Create button. This brings us to an empty workflow designer page.
Figure 23: Adding components to your release template
We will need to add the components we just created into the toolbox for this release template. Right-click on components, select the correct components, and then click the link button. This will add the components we want to deploy to the toolbox so that we can drag them into the workflow.
Figure 24: Drag and drop the server and then component into the workflow designer
We first need to drop the machine we want to deploy to into the workflow designer. This will give us the ability to run activities on that machine. After that, we can drop the Tailspin.Schema component onto the server (we want the database to be deployed before the website is deployed). Once the component has been dropped into the workflow, we can double-click it to get to its parameters (the ones we defined in the components section of this blog).
Figure 25: Tailspin.Schema’s configuration variables
This is where we put in the name of the dacpac file, what is the server name we are deploying to, what is the database name we want to deploy the dacpac to, and whether or not we want to create a new database. Once done, we can click the Deployment Sequence on the breadcrumbs at the top left of the workflow designer to get back to a global view of the workflow.
Before we deploy Tailspin.Web, we want to ensure that there is a web site and application pool for us to actually deploy to in IIS. To do so, we are going to drag and drop the Create Application Pool and Create Web Site under the IIS node in the toolbox into the workflow, after the Tailspin.Schema component. Note that by using the create rather than the configure activities, they will first check to see if the app pool or web site already exist and only configure them if they do exist. Again, we need to fill out a few parameters for these activities.
Figure 26: Application pool configuration variables
For the application pool, I leave everything default and only give it a name of Tailspin.Web.
Figure 27: Web Site configuration variables
For the web site, I give it the application pool’s name, the name of the site (which will match the application pool’s name), a port number, as well as the physical path for the web site (note that I will also define this in the component configuration for Tailspin.Web anyway). Once we have created the application pool and the web site, we will want to deploy Tailspin.Web itself. Again, drag and drop the activity onto the workflow designer and double-click it to define its parameters.
Figure 28: Tailspin.Web configuration variables
The configuration variable needed here is merely the Installation Path. This will be the path that we defined as the PhysicalPath for the website we created in IIS (our previous activity in the workflow).
Figure 29: Tailspin Toys deployment sequence for the DEV deployment
Once everything is said and done, we should now have a sequence that looks something like the above screenshot. We should now be able to click Save and then click New Release.
Figure 30: Starting a new release
Give the release itself a name, and then click the Latest link to poll the latest build from the build definition we specified for the release template itself. You will be brought to the page of the release you just created where it will show you it is currently in progress. If the release does work, it will be automatically updated and show the status of Released.
Figure 31: Successful deployment of Tailspin Toys
Once this is done, we can go verify that it is working by navigating to http://tupper-tfs:5000 and Tailspin Toys should appear.
Figure 32: Tailspin Toys now running on http://tupper-tfs:5000
Please note that this is a very simple deployment. I have almost no error checking, and absolutely zero rollback if things don’t work. This is very much a happy path deployment using Release Management, and should be added to for actual deployments. There are specific activities in Release Management that will help you complete rollbacks when releases fail.