Free trial *Internet Service Required

Continuous delivery to Windows Azure by using Team Foundation Service

Microsoft Team Foundation Service is a cloud-hosted service version of Microsoft’s popular Team Foundation Server (TFS) software that provides highly customizable source code and build management, agile development and team process workflow, issue and work item tracking, and more. You can configure your Team Foundation Service team projects to automatically build and deploy to Windows Azure web sites or cloud services. For information on how to set up a continuous build and deploy system using an on-premises Team Foundation Server, see Continuous Delivery for Cloud Applications in Windows Azure.

This tutorial assumes you have Visual Studio 2012 and the Windows Azure SDK installed. If you don’t already have Visual Studio 2012, download it here. You can use Visual Studio 2010, but you must have SP1 installed and you must install the Compatibility GDR. Install the Windows Azure SDK from here.

To set up a cloud service to automatically build and deploy to Windows Azure by using Team Foundation Service, follow these steps:

Sign up for TFSStep 1: Sign up for TFS

  1. Create a TFS account by navigating to http://tfs.visualstudio.com. Click the Sign up for free link. You will need to sign-in using a Microsoft account. After you log in, create a TFS account URL. Your account will have the form: https://<accountname>.visualstudio.com.

  2. Select New Team Project.

  3. Give a name and description to your project and click the Create Project button.

  4. When project creation is done, click the Navigate to Project button.

Check in a projectStep 2: Check in a project to TFS

  1. Click the Open new instance in Visual Studio link to automatically launch Visual Studio connected to your team project. If you see any security dialog boxes, choose Allow. This step requires Visual Studio 2012.

  2. In Visual Studio, open the solution you want to deploy, or create a new one. You can deploy a web site or a cloud service (Windows Azure Application) by following the steps in this walkthrough. If you want to create a new solution, you can either create a new Windows Azure Cloud Service project, or a new ASP.NET MVC4 project. Make sure that the project targets .NET Framework 4, and add an ASP.NET MVC 4 web role and a worker role. When prompted, choose Internet Application. If you want to create a web site, choose the ASP.NET MVC4 Application project template.

  3. Open the shortcut menu for the solution, and select Add Solution to Source Control.

  4. Accept or change the defaults and choose the OK button. Once the process completes, source control icons appear in Solution Explorer.

  5. Open the shortcut menu for the solution, and choose Check In.

  6. In the Pending Changes area of Team Explorer, type a comment for the check-in and choose the Check In button.

    Note the options to include or exclude specific changes when you check in. If desired changes are excluded, choose the Include All link.

Connect the project to Windows AzureStep 3: Connect the project to Windows Azure

  1. Now that you have a TFS team project with some source code in it, you are ready to connect your team project to Windows Azure. In the Windows Azure Portal, select your cloud service or web site, or create a new one by selecting the + icon at the bottom left and choosing Cloud Service or Web Site and then Quick Create. Choose the Set up TFS publishing link.

  2. In the wizard, type the name of your TFS account in the textbox and click the Authorize Now link. You might be asked to sign in.

  3. In the OAuth pop-up dialog, choose Accept to authorize Windows Azure to configure your team project in TFS.

  4. When authorization succeeds, you see a dropdown containing a list of your TFS team projects. Select the name of team project that you created in the previous steps, and choose the wizard’s checkmark button.

  5. When your project is linked, you will see some instructions for checking in changes to your TFS team project. On your next check-in, TFS will build and deploy your project to Windows Azure. Try this now by clicking the Check In from Visual Studio 2012 link, and then the Launch Visual Studio 2012 link. (or the equivalent Visual Studio button in the command-bar).

Trigger a rebuildStep 4: Trigger a rebuild and redeploy your project

  1. In Visual Studio’s Team Explorer, click the Source Control Explorer link.

  2. Navigate to your solution file and open it.

  3. In Solution Explorer, open up a file and change it. For example, change the file _Layout.cshtml under the Views\Shared folder in an MVC4 web role.

  4. Edit the logo for the site and hit Ctrl+S to save the file.

  5. In Team Explorer, choose the Pending Changes link.

  6. Type in a comment and choose the Check In button.

  7. Choose the Home button to return to the Team Explorer home page.

  8. Choose the Builds link to view the builds in progress.

    The Team Explorer shows that a build has been triggered for your check-in.

  9. Double-click the name of the build in-progress to view a detailed log as the build progresses.

  10. While the build is in-progress, take a look at the build definition that was created when you linked TFS to Windows Azure by using the wizard. Open the shortcut menu for the build definition and choose Edit Build Definition.

    In the Trigger tab, you will see that the build definition is set to build on every check-in by default.

    In the Process tab, you can see the deployment environment is set to the name of your cloud service or web site.

    Specify values for the properties if the values differ from the defaults. The following table shows default values of the properties:

    Property Default Value
    Allow Upgrade true
    Cloud Service Environment Staging
    Cloud Service Name The name of the service you are connected to
    Deployment Label The same as the service name
    Service Configuration ServiceConfiguration.Cloud.cscfg
    Storage Account Name Blank, which means try to find a storage account.
    Publish Profile The .azurePubxml file. If you check in one, you can choose it here.


    If the storage account property is left blank, Windows Azure searches for one. If there is a storage account with the same name as the cloud service, it is used. Otherwise, it uses another storage account, or if there is no storage account, it creates one.

  11. By this time, your build should be completed successfully.

  12. If you double-click the build name, Visual Studio shows a Build Summary, including any test results from associated unit test projects.

  13. In the Windows Azure Portal, you can view the associated deployment on the Deployments tab when the staging environment is selected.

  14. Choose the URL in the Quick Glance section of the Dashboard page that shows the Staging environment for a cloud service. For a web site, just click the Browse button on the command bar. Deployments from continuous integration for cloud services are published to the Staging environment by default. You can change this by setting the Alternate Cloud Service Environment property to Production. Web sites have no Staging or Production environments.

    A new browser tab will open to reveal your running site.

  15. If you make other changes to your project, you trigger more builds, and you will accumulate multiple deployments. The latest one marked as Active.

Redeploy an earlier buildStep 5: Redeploy an earlier build

This step is optional. Select an earlier deployment and click the Redeploy button to rewind your site to an earlier check-in. Note that this will trigger a new build in TFS, and create a new entry in your deployment history.

Change the Production deploymentStep 6: Change the Production deployment

This step applies only to cloud services, not web sites. When you are ready, you can promote the Staging environment to the production environment by choosing the Swap button. The newly deployed Staging environment is promoted to Production, and the previous Production enviroment, if any, becomes a Staging environment. The Active deployment may be different for the Production and Staging environments, but the deployment history of recent builds is the same regardless of environment.

For more information, see Team Foundation Service.

Rss Newsletter