As part of a project I’m involved with at my day-job, I wanted to setup a simple continuous deployment to complement our continuous integration. We have one solution that contains, amongst other projects, two web projects; one is the primary web application and the second is a web api project containing our REST based API. We wanted to deploy this projects to two separate websites in order to keep them apart, mimicking how we planned to release them into the wild.
The first step is to create new Build Definitions in TFS. We will create two new definitions, one for each of the web projects.
Firstly, open the Team Explorer and locate the Builds section of the project:
There are no builds at present for this project, so right click on the Builds folder and select “New Build Definition”. The build definition panel will be opened and you can then configure the details of the build. I’ve blacked out the name of our build server in the image above.
When the Build Definition pane opens, you’ll be presented with this:
Fill in the build definition name. For this I’m using the name SmartBusinessPortal_API_CI indicating the project name, the individual area and that it’s a CI build. Use whatever naming convention is applicable to your project.
Since this is a Continuous Integration task, you need to choose how the build will be triggered. From the menu on the left hand side of the Build Definition, select Trigger.
I use the Rolling Builds option, selecting the “Build no more often than every” option with a value of five. This will mean that when a check-in is performed it will only perform a build if there hasn’t been one started in the past five minutes. It also means that check-ins performed at short intervals won’t result in lots of new builds. You’ll get a max of twelve builds an hour.
The next thing to change is the “Items To Build”. This is located under the Process section.
Expand the “1. Required” section under Build Process Parameters.
You can see that the “Projects To Build” option points to the solution of the project. This isn’t what I want, since I’m only concerned with a particular project (In this case, a web api project called SmartBusinessPortal.API). Highlight the Projects to Build section and hit the small button in the row (highlighted here with a red box)
This will open a new Window showing you the selected projects.
Hit the “Remove” button to delete the reference to the solution and then hit the “Add…” button. A Browse window will be opened. Just navigate the folder structure until your find the project file you want to build. Be sure to change the “Items of Type” dropdown to “MSBuild Project files” if you want to see actual project files, instead of solution files.
Select the project file you want and click OK. Then, when back on the “SolutionsProjects” window, hit OK again. This will update the Build Definition window to the selected project file.
Try and Build
You can now the Build Definition by hitting Ctrl-S or trying to close the tab, which will prompt you to save. You should now see the build under the Builds folder of the Team Explorer. I’ve repeated the steps about to create the Build Definition for the web project, so my Builds folder looks like this.
Right click on one of the builds and select “Queue New Build”. A new windows will open, but just click “Queue”. The build explorer should then be displayed, showing your build in progress.
After a while, hit F5 to refresh the view and it should now should the build as successfully completed. The green tick indicates this. If you get a build failure, double click on the row to open the details. Fix whatever errors are showing and Queue new builds until it succeeds.
Now that the build it working okay, the next step is to setup the automated deployment. I’m going to assume that you have setup MSDeploy on an IIS 7.0 server somewhere and that you can deploy without issue from VS directly.
In the Build Definition pane, open the “Process” section again. This time, expand the section “3. Advanced”. Within this section, there is a setting called “MSBuild Arguments”. We need to populate this with some MSDeploy arguments.
/p:DeployIisAppPath=<WEB APP NAME>
There are a few values you need to add. The “Web App Name” is just the name of the website or virtual directory you have on IIS. The “Server Name” is the location of IIS. The username and password refer to an account that has permission to use the MSDeploy publish. If you remove these, it will use the identity of the Build process. I specify the username and password using an account local to the IIS machine.
All those settings above go together in one line and put in as the “MSBuild Arguments”. You can now save the build configuration and Queue a build. When the build completes successfully it should perform a deployment.
I have this basic setup in place and working. The next thing for me to do is learn how to choose the Solution Configuration that it should use to build, so that the web.config file gets populated with the correct database settings. Once I know how to do that I’ll post the details.
Good luck. If you’ve any questions use the comments below or drop me an email.