Enabling Continuous Delivery for Azure Cloud Service Projects (Web or Worker Role) Using TFS source control & TFS Build Agents with Octopus Deploy.

Last week I have written a blog post about how you can build in TFS and Deploy using the Octopus Deploy of various similar applications like ASP.NET web applications , API and windows services  . This week’s post is on how we can deploy Microsoft Azure Cloud Service projects using the same tools and the infrastructure as we did last week. There are number of blogs out there do it differently but I have chosen the path where you create the packages during the build and just apply the transforms during deploy to different environments. Lets get into the subject.

Solution / Projects

This is our Azure Cloud Service Solutions which Contains a WebRole , Unit Tests and the Cloud Service Configurations. As shown above

Nuspec file

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<description>This is a sample test Azure cloud service project</description>
<!-- Add the files .wadcfg file to the root to get the diagnostics working -->
<file src="..\DiCloud.WindowsAzure\DiWebRoleContent\*.*" />
<file src="..\DiCloud.WindowsAzure\bin\Release\app.publish\*.*" />

Now, add the nuspec file into the webrole projects with the following contents. There is a subtle difference of why we are have the files section. Because we are not doing the Octopack during the build Process. Reason is the Publish target executes to produce the DiCloud.WindowsAzure.cspkg service package file. Which is not available when the projects build is completed. This package is produced only when the Service configuration is published.

OctoPack Package

Run the command Install-Package OctoPack in the package manager console. This will make the Octopack targets available for our later use.

Build Definition 

We have created the build definition based on the default template as shown below. We are using the target publish with the cloud profile.

/t:Publish /p:TargetProfile=Cloud

Service Package file

When you queue the build now, you will be able to see the service package file produced under bin\release\app.publish folder as shown below

Create Nuget package & Publish to Octopus Server

Step 1 : 

Post build Powershell scripts to create and publish nuget packages to Octopus server nuget feeds.

"DiCloud.WindowsAzure.sln /p:RunOctoPack=true /p:OctoPackEnforceAddingFiles=true /p:OctoPackPublishPackageToHttp=http://ditfs.cloudapp.net:1001/nuget/packages /p:OctoPackPublishApiKey=API-WQUPMXQKZGXGC8LJLWGOHGL8W /p:OctoPackPackageVersion=$(TF_BUILD_BUILDNUMBER)"


The contents of Powershell Script to make this happens is shown below.

Write-Host 'We are created Octo Package after the Publish'
Write-Host "Build Number is " $Env:TF_BUILD_BUILDNUMBER
Write-Host "Source Directory" $Env:TF_BUILD_SOURCESDIRECTORY
Write-Host '------------------------------------------------------------'
Write-Host "Number of Args:" $args.Length
foreach ($arg in $args) {Write-Host "Arg : $arg"}
Write-Host '------------------------------------------------------------'

Function Get-MSBuildPath {
 $lib = [System.Runtime.InteropServices.RuntimeEnvironment]
 $rtd = $lib::GetRuntimeDirectory()
 Join-Path $rtd msbuild.exe
$msbuildPath = Get-MSBuildPath
Write-Host "Ms Build Path " $msbuildPath

$OctofullCmd = "$msbuildpath $Env:TF_BUILD_SOURCESDIRECTORY\$arg"

Write-Host "OctoFull Command" $OctofullCmd
Invoke-Expression -Command "$OctofullCmd"

Check in everything you will be able to see the package in the Octopus library

Phase 2 : Octopus Configuration

Create the Projects and use the Deploy Azure template to create the step as shown below and also download the management certificate and upload to the Microsoft Azure account.

Select the automatic release creation from the process and associate with the nuget extraction step

Create the environments as shown below Staging and Production

Also, I have created a new life cycle for the Cloud Service deployments.

After the release have been created, we are deploy to the staging slot. As shown below

Once, Staging is deployed we can promote the build to the Production by click the button as shown in below screenshot

Now the Nice Dashboard will be able to give is the Clear view of what stage each application is in and what version have been deployed.

This summarizes this week’s post. My preferred tool sets will be Teamcity as build server and Octopus Deploy for managing deployments, reason for this is TFS build definitions are lacking step level architecture. I hope TFS 2015 might be able to do similar way Teamcity does.

Watch the space for next blog

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.