And now, the moment we’ve all been waiting for. This post will give some insight into the Azure CI build process and how all of this works under the hood. You may be surprised to learn that this solution has very little secret sauce as much as bread and butter. First I want to show a bit of the build template that was included with your TFS project. In a later post, I want to give some information on a new set of activities that may prove useful if you are using TFS online or migrating to an on-premises 2012 instance.

AzureContinuousDeployment.11.xaml

The AzureContinuousDeployment.11.xaml file is the xaml markup defining the build workflow or build template. This file should be located in your TFS project. Open Visual Studio 2012 and connect to TFS online, the file should be at $/<projectName>/BuildProcessTemplates/AzureContinuousDeployment.11.xaml

To open just double click from the source control explorer. If you are using the black theme, switch to the light theme because for some reason the expression text in the workflow designer is black and you cannot see it at all.

At first glance this template looks very similar to a normal default template, but if you dig into the post-compilation area you can find some deployment setup and activities.

The deployment configuration happens at Process > Sequence > Run On Agent > Try Compile, Test…> Sequence > Compile, Test an… > Try Compile and Test > Compile and Test > Sequence > Initialize Variables > If DeploymentEnvironmentName is Set.

There are a couple of new activities here. The activity that manages most of the configuration is named Get Deployment Environment and is part of a new (as far as I can tell) Microsoft.TeamFoundation.Deployment.Workflow assembly.

The result of this sequence is a number of variables set depending on the type of Azure deployment, website or cloud service.

Another new activity is called “Mark this build as including a deployment” under the “Deploy Output” if statement. As far as I can tell this is what adds this build to the Deployment tab.

The next section to note is back up a couple levels under the Compile and Test > Sequence > Deploy Output area.

Under the Publish Output section after the tests have passed you can see the deployment sequences for the Website and Cloud Service.

You can see that if this was an Azure website deploy, the MSDeploy activity is used which simply performs a web deploy. Then afterwards a new activity is used to update the “build number” for the Azure Website. If it is a Cloud Service Deploy then a new activity called DeployAzureCloudApp is used for the deployment.

After that the rest of the build definition is pretty straight forward. With some clever arranging you can see how you can modify this definition to do multiple deployments or even deploy then run tests if you need to.

I hope this gives you a look into the Azure TFS deployments and how it all works. If you have any questions please leave a comment, email me at tylergd@live.ca, or contact me on Twitter @tyler_gd.

Thank you as always for reading and I hope you are having a great summer.

This post is a bit delayed from the previous post unfortunately. I just want to give some direction on setting up TFS publishing to Cloud Services by sharing some links and experience that I have had with the process.

Steps

The official set of steps can be found here (https://www.windowsazure.com/en-us/develop/net/common-tasks/publishing-with-tfs/)

These steps involve

1. Setting up the TFS Online project adding your initial codebase,
2. Adding your initial codebase (any new Azure solution will do)
3. Connecting the project to Windows Azure
4. Making changes and triggering a CI build
5. Redeploying an earlier build (optional)
6. Swapping to the production deployment

Notes

For stage 3 (connecting the project to Azure) if you cannot find the screen shown there you have likely skipped the Quick Start. To get back to the screen click the small cloud icon beside “Dashboard” that looks like this

I have an open forum post here, but it seems that you need to have Project Collection Administrator privileges in TFS to make the connection. I will update this if I come to a different conclusion.

By default the deployment will update the Staging environment. To override that you can use the “Alternate Cloud Service Environment” parameter in the build and set it to Production. I suggest using this for testing or beta deployments because it can be difficult to switch back, when deploying to staging it can be as easy as swapping the environments again to back out of your deployment.

In the next post I am going to dig into the workflow definition and show you how it works and how to extend it.

If you are having issues with this you can check out Brian Harry’s Blog post announcing this feature: http://blogs.msdn.com/b/bharry/archive/2012/06/07/announcing-continuous-deployment-to-azure-with-team-foundation-service.aspx

I hope this helps, please send me an email at tylergd@live.ca if you have any questions that you don’t want to add to the post comments.

Thank you.

The next set of blog posts will be devoted to the connection between Azure and TFS released as part of the June 2012 features. Many people are talking about publishing websites using Git, WebDeploy, and FTP. There is one more option for doing deployments, TFS. More specifically TFS Online from tfspreview.com. Currently this functionality does not exist in the on-premises version of TFS 2012.

How it works

If you go to tfspreview.com and create a new account (which you can do now, it is no longer invite only) you have the key component for deploying to Azure. The Azure build template, which should be in source control under $/<projectName>/BuildProcessTemplates/AzureContinuousDeployment.11.xaml

The next piece requires you to setup the connection between TFS Online and Azure. If you are setting up a cloud service deployment you need to deploy something there first. You should see this link.

A background service in TFS connects to Azure on you behalf. If you co to the Collection Administration area of TFS you should see a Services tab.

The final component should have been created automatically. Under the project you connected there should be a new CI build and a deployed tab in the projects build area.

This will show you when the application has been deployed to Azure.

With this connection made, the build process retrieves account details from the TFS service and performs the deployment operations. The Continuous Deployment build trigger will run this build every time you check-in code to TFS.

I will go into all of these areas in the second post when I go through setting up a new deployment. Then further in the third part, where I will dig into the build definition and show how the deployment is done.

Pros

Team-Oriented – Compared to the Git and WebDeploy solutions which use a single set of credentials for all of the sites for the subscription, TFS can be connected to a team project and incorporated into the builds for that project. This allows you to control access to who has the ability to run this build, or even check in code. In order to deploy to Azure, the user does not need access to the Azure Subscription or credentials that could update other sites.

Automated Testing – The deployment of your website or cloud service depends on the result of your unit tests. This gives you an easy quality gate that the code has to pass through before deployment.

Extensibility – The TFS deployments use a TeamBuild CI (Continuous Integration) trigger on a fairly standard build template (which I will go through in the next post). Once you understand how the workflow is performing the deployment it can be modified or extended to do multiple deployments, testing, or any extra operations that may accompany your product.

Cons

TFS Preview – Currently the out-of-the-box functionality is only available with tfspreview.com. Right now as far as I know the long term pricing for this service is unknown. Also, if you have current Azure projects that use TFS 2010 you will have to use traditional means for Azure deployment. TFS Online looks like a great service, even though there are some feature gaps with on-premises like Lab Management and Work Item customization, I think it will cover the vast majority of TFS users.

Please leave a comment or email me if you have a question. This is part 1 in a 3 part series on TFS and Azure.

1. Introduction
2. Setup a Cloud Service deployment
3. Under the hood

Thank you,