I’ve just started setting up some continuous deployment for my personal websites. All of the sites are hosted within Azure App Services and the sources are located on either GitHub or BitBucket. By having the source code located on a public accessible repository (be it private or public), it’s rather easy to connect Azure to these locations.

On my day-job I come across a lot of web- and desktop applications which also need continuous integration and deployment steps in order for them to go live. For some of these projects I’ve used Octopus Deploy and currently looking towards Azure Release Management. These are all great systems, but they offer quite a lot of overhead for my personal sites. Currently my, most important, personal sites are so called static websites using MiniBlog (this site) and Hugo (for keto.jan-v.nl). Some of the other websites I have aren’t set up with a continuous deployment path yet.

I don’t really want to set up an Octopus Deploy server or a path in Azure Release Management for these two sites. Lucky for me, the Azure team has come up with some great addition in order to provide some custom deployment steps of your Azure App Service. In order to set this up, you need to enable the automatic deployments via the Deployment Options blade in the Azure portal.

In my previous post I’ve talked about creating new projects in Octopus Deploy in order to deploy projects to different environments. In this post I’ll explain a bit on how to create Octopus Deploy packages for your Visual Studio projects via Teamcity.

To enable packaging for Octopus you’ll need to include the Octopack NuGet package to the project you are packaging. In my case this will be the Worker project since I’m only working with Microsoft Azure solutions at the moment.

Once this package is successfully installed you will have to modify the project file also to enforce adding files in the Octopus package.

The following line will have to be added to the propertygroup of your build configuration

<OctoPackEnforceAddingFiles>True</OctoPackEnforceAddingFiles>

For reference, a complete propertygroup:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <OctoPackEnforceAddingFiles>True</OctoPackEnforceAddingFiles>
</PropertyGroup>

Your project is now ready to start packing. In my case I had to add a nuspec file also, because the worker project contained an application which has to be deployed to on an Azure Cloud Service.

A nuspec file for Octopus Deploy looks exactly the same as one you would create for NuGet itself. Mine looks like this:

<?xml version="1.0"?>
<package xmlns="https://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
	<metadata>
		<version>$version$</version>

After installing the plugin, three new runner type features will be available when creating a new build step.

The latest project I was working on didn’t have a continuous integration and continuous deployment environment set up yet. Creating a continuous integration environment was rather easy as we were already using Teamcity and adding a couple of builds isn’t much of a problem. The next logical step would be to start setting up continuous deployment.

I started out by scripting a lot of PowerShell to manage our Azure environment like creating all SQL servers, databases, service busses, cloud services, etc. All of this worked quite well, but managing these scripts was quite cumbersome.

A colleague of mine told me about Octopus Deploy. They had started using this deployment automation system on their project and it sounded like the exact same thing I was doing, just a lot easier!

Setting up the main server and it’s agents (tentacles) was quite easy and doesn’t need much explanation. The pricing of the software isn’t bad either. You can start using it for free and when you need to use more as 10 tentacles or 5 projects, you’ll start paying $700 for the professional license. Spending $700 is still a lot cheaper as paying the hourly rate of a PowerShell professional to create the same functionality.