Setting up continuous deployment

We're now going to check our website into TFS and set up continuous deployment so that our website is built and published to the staging slot whenever we check in code changes.

Adding a solution to source control

To add a solution to source control, perform the following steps:

1. First of all, we need to add our solution to TFS in our Visual Studio Online account. From the FILE menu, go to Source Control | Add Solution to Source Control...:
   
2. Select Team Foundation Version Control (default) from the next dialog and click on OK. In the Connect to Team Foundation Server dialog, click on the Servers... button; then, on the Add/Remove Team Foundation Server dialog, click on Add.... After that, enter the URL of our Visual Studio Online account from the Azure portal:
   
3. Sign in when prompted, and then click on Close on the Add/Remove Team Foundation Server dialog.
4. Select the team project in the Connect to Team Foundation Server dialog and click on Connect:
   
5. Next, click on Make New Folder and add a main folder; this is a good practice for TFS projects to help with branching:
   
6. Once we've done this, we'll see a lot of little + symbols next to each file in the solution; this means the files are added to source control but not checked in. Next, we need to check in the code to see if it's safely stored on the TFS server, so right-click on the solution and select Check In...:
   
7. Enter a comment (it's always important to enter a comment as it shows up in the version control history, helping you if you need to revert the code or create a branch at a certain point) and click on Check In:
   
8. Now, all the files in our solution should have blue padlocks next to them, showing that they are all checked in and there are no pending modifications.

Configuring continuous deployment

Continuous deployment is performed by a TFS build agent, which can build code triggered by a number of different events. We're going to use the wizard in the Azure portal to set up our build agent for us, and then we'll have a look at what is done:

1. First, go to the dashboard of the website's staging slot and click on the Set up deployment from source control link:
   
2. Next, select Visual Studio Online (default) from the SET UP DEPLOYMENT dialog and click on the next arrow.
3. Now, enter the name of the Visual Studio Online account and click on Authorize Now:
   
4. Accept the connection request, choose the repository, and accept it; then, the project will be linked and will appear under the DEPLOYMENTS tab:
   

We can now test continual deployment's working by changing something in the website, checking it in, and then browsing the Azure website to see the changes:

1. In the website project, open the Views/Home/Index.cshtml file and make some changes to the markup; I changed the ViewBag.Title property, which will change the title. Then, I changed the first div element and deleted the rest of the markup like this:

   @{
       ViewBag.Title = "Azure Bakery";
   }
   
   <div class="jumbotron">
       <h1>Azure Bakery</h1>
       <p class="lead">Welcome to Azure Bakery!</p>
   </div>

   Tip

   Downloading the example code

   You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

2. Now, if we save this and check it in (using the same process as when we first checked in the code), a build should trigger, and then our website will be published. While we wait for this to happen, we'll go and take a closer look at what's going on, so in the Team Explorer window, click the drop-down menu and select Builds (you can also get to this via the menu on the home tab):
   
3. We should then see a build listed under the My Builds heading; if we double-click on it, a window will open, showing us the current status of the build (if you miss the build and it's completed already, you can right-click on the build definition and select Queue New Build to rebuild manually; I did this while I was trying to type everything, so this is why you can see two builds):
   
4. Once it's complete, you will see it update with a Build succeeded status and a green tick:
   
5. If we have any problems during the build, we can view the build log from here (as shown in the previous screenshot), which will show us any errors and warnings to help us diagnose the problem.
6. Finally, if we refresh our staging website, we should see that the code changes have been deployed!

Examining the build definition

To complete this section, we'll take a look at the build definition that the Azure wizard has created for us:

1. In the Team Explorer window, right-click on the build definition and select Edit Build Definition:
   
2. In the General tab, we have options to control how the build is queued:
   • Enabled: This allows requests to be queued and built in priority order.
   • Paused: Requests are queued but not built (unless an administrator forces them).
   • Disabled: Requests are neither queued nor built. This can be used to stop continuous deployment.
3. In the Trigger tab, we can adjust what events trigger a build:
   

   The various triggers available are as follows:

   • Manual: This stops builds from being automatically triggered (they can still be manually triggered). This can be used to stop continuous deployment.
   • Continuous Integration: This is the default setting created by the wizard and will trigger a build on every single check-in, which might not be the best setting if you check in code regularly as you will find build requests backing up.
   • Rolling builds: This might be a better option for continuous deployment as you could set it to build not more than every 30 minutes, for example, so you don't get a backlog of requests queuing.
   • Gated Check-in: In this configuration, changes that the developer makes are placed in shelve sets (like a staged check in) and are only checked in once the build server has successfully built the changes. This can stop developers from breaking code in source control.
   • Schedule: It can be quite common to have a scheduled build to check the integrity of the code at regular intervals if continuous integration is not used.
4. The Source Settings tab shows us how Source Control Folder maps to Build Agent Folder. Don't change this unless you need to.
5. The Build Defaults tab allows us to change the location of where the build output is deployed. Don't change this unless you need to.
6. The Process tab is where the build process template is defined and configured. Don't change this unless you need to.
7. The Retention Policy tab allows you to change how builds are retained by the server.