Category Archives: Build Management

Continuous Integration and build management.

PowerShell DSC tooling updates released!

Over the past few weeks, we’ve been working on incorporating Desired State Configuration into our continuous deployment pipeline.  We’ll be using this technology internally, eating the dog food, but we also want to be able to help our clients leverage this technology.

To get started, we decided to take advantage of the excellent work and experience of Steven Murawski.  During his time at Stack Exchange, Steven was one of the first and most visible adopters of DSC in a production environment.  Over time, he developed a set of PowerShell modules related to DSC, which have been published as open source over at

We’ve been working on some updates to this code and are now pleased to announce that it’s publicly available via GitHub at

A list of the changes that Dave Wyatt has been working on within DevOpsGuys over the past couple of months can be found at

The most extensive changes, and many of the design decisions were made in collaboration with Steve Murawski. There’s still more work to be done before this branch is ready to be merged into master; we just wanted to get this code out into the public repo asap. The motivation behind these changes was to get the tooling modules to a point where we can train clients to use them in a continuous delivery pipeline.

The biggest priorities were creating examples of the folder structures required by DscConfiguration and DscBuild, and simplifying the Resolve-DscConfigurationProperty API and code.

We’ve also tried to improve the overall user experience by making minor changes in other places; making Invoke-DscBuild run faster, making failed Pester tests or failed calls to Test-cDscResource abort the build, making Test-cDscResource stop reporting failures for resource modules that are actually valid, etc.

We’d love your feedback on the changes we are making, so please get in touch with your comments.

Upgrading to Octopus 2.0

On 20th December 2013, Paul Stovell and the Octopus Team released Octopus Deploy 2.0. We’ve had a chance to play with the product for sometime, and it’s a great next version.

Here’s 5 great reasons to upgrade;

  1. Configurable Dashboards
  2. Sensitive variables
  3. Polling Tentacles (Pull or Push)
  4. IIS website and application pool configuration
  5. Rolling deployments

So let’s take a look at how the upgrade process works.

Step 1 – Backup your existing database

Things to check before you upgrade;

  1. Your administrator username and password (especially, if you are not using Active Directory)
  2. Before attempting to migrate, make sure that you don’t have any projects, environments, or machines with duplicated names (this is no longer allowed in Octopus 2.0, and the migration wizard will report an error if it finds duplicates).
  3. IIS Configuration. Are you using ARR or rewrite rules of any kind.
  4. SMTP Server Settings (these are not kept in upgrade)

The first step is to ensure that you have a  recent database backup that you can restore in case anything goes wrong.

1 - Database Backup

Confirm the location of your backup file. You’ll need this file at a later stage in the upgrade process (and if anything goes wrong)

2-Database Backup Location

Step 2 – Install Octopus 2.0

Download the latest installer MSI from the Octopus Website at

Next follow the installer instructions and the Octopus Manager process. This process is really straight forward, and if you’ve installed Octopus before you’ll be familiar with most of the process. There’s a great video here on how to install Octopus

Step 3 – Import Previous Octopus Database

Once you’ve installed Octopus 2.0, you’ll most likely want to import your old v1.6 database with all your existing configuration. To do this, select the “import from Octopus 1.6” option and choose the database back-up from the process you followed in step 1 and follow the instructions.

3 - Import Octopus Database

Step 4 – Post Upgrade Steps (server)

When you have completed the installation it’s essential to task a copy of the master key for backups. Instructions on how to backup the key can be found here

Once you have the server installed there’s a couple of items you’ll need to configure again.

  1. SMTP Server Settings are not kept, so these will need to be re-entered.

Step 5 – Upgrading Tentacles

If you are upgrading from version 1.6 – Octopus 2.0 server can no longer communicate with Tentacle 1.6. So in addition to upgrading Octopus, you’ll also need to upgrade any Tentacles manually. There are two ways to achieve this;

1. Download and Install the new Octopus Deploy Tentacle MSI on each target server

2. Use  a PowerShell script to download the latest Tentacle MSI, install it, import the X.509 certificate used for Tentacle 1.6, and configure it in listening mode. The powershell script is as follows;

function Upgrade-Tentacle
  Write-Output "Beginning Tentacle installation"
  Write-Output "Downloading Octopus Tentacle MSI..."
  $downloader = new-object System.Net.WebClient
  $downloader.DownloadFile("", "Tentacle.msi")
  Write-Output "Installing MSI"
  $msiExitCode = (Start-Process -FilePath "msiexec.exe" -ArgumentList "/i Tentacle.msi /quiet" -Wait -Passthru).ExitCode
  Write-Output "Tentacle MSI installer returned exit code $msiExitCode"
  if ($msiExitCode -ne 0) {
    throw "Installation aborted"
  Write-Output "Configuring and registering Tentacle"
  cd "${env:ProgramFiles(x86)}\Octopus Tentacle 2.0\Agent"
  Write-Output "Stopping the 1.0 Tentacle"
  & .\tentacle.exe create-instance --instance "Tentacle" --config "${env:SystemDrive}\Octopus\Tentacle\Tentacle.config" --console
  & .\tentacle.exe configure --instance "Tentacle" --home "${env:SystemDrive}\Octopus" --console
  & .\tentacle.exe configure --instance "Tentacle" --app "${env:SystemDrive}\Octopus\Applications" --console
  & .\tentacle.exe configure --instance "Tentacle" --port "10933" --console
  & .\tentacle.exe import-certificate --instance "Tentacle" --from-registry  --console
  Write-Output "Stopping the 1.0 Tentacle"
  Stop-Service "Tentacle"
  Write-Output "Starting the 2.0 Tentacle"
  & .\tentacle.exe service --instance "Tentacle" --install --start --console
  Write-Output "Tentacle commands complete"

Step 6 – Upgrade TeamCity Integration

The JetBrains TeamCity Plugin has also been released and requires an upgrade. To do this

  1. Download the plugin from the Octopus Website
  2. Shutdown the TeamCity server.
  3. Copy the zip archive ( with the plugin into the <TeamCity Data Directory>/plugins directory.
  4. Start the TeamCity server: the plugin files will be unpacked and processed automatically. The plugin will be available in the Plugins List in the Administration area.

Please Note: The API Key’s for the users will have changed and will need to be re-entered into the Octopus Deploy Runner Configuration within the Build Step


We think that overall the Octopus Team have done a great job making the upgrade process easy. There’s still a few little issues to iron out, but overall the process is robust and simple. It’s a shame that automatic upgrade of the tentacles couldn’t have been supported as this may cause pain for customers with a large server install base, but Powershell automation makes for a great workaround.

As we learn more about Octopus 2.0, we’ll continue to let you know what we find. Good Luck with Upgrading — it’s definitely worth it!

DevOpsGuys use Octopus Deploy to deliver automated deployment solutions – ensuring frequent, low-risk software releases into multiple environments. Our engineers have deployed thousands of software releases using Octopus Deploy and we can help you do the same. Contact us today – we’d be more than happy to help.


In a previous post, we mentioned NuGet as great way to package up code for deployment, and that got us thinking about NuGet feeds.

NuGet Overview

In just about every Visual Studio project we create today, we will eventually find a need for a 3rd party library of some kind.

Managing these libraries has traditionally been a cumbersome process. It can be difficult to find available libraries, although Google does a good job, but it’s hard to find the latest version of libraries you’ve used and keep them updated.

That’s when NuGet comes to the rescue. NuGet is a Visual Studio extension that makes it easy to add, remove, and update libraries and tools in Visual Studio projects that use the .NET Framework.

What’s great about NuGet is that we can use it to package our own applications for publishing, which means it becomes a good tool for deployment.

This post won’t cover using NuGet, there’s some great information at, but we are going to explore some options for publishing NuGet packages once they’ve been created.

Public Publishing at

The public NuGet Gallery is the best place to publish if you’re producing a library, component or framework you want others to use. If however, you’ve just developed a bespoke website for a new client this not the place to publish to.

The NuGet Gallery currently boasts more than 10,000 packages and claims over 42 million downloads, so if you have something to share this will be your publishing target.

Publishing to this feed is pretty straight-forward, you need to

1.  Register for an account at

2. Grab the API Key, located in the “My Account” page. This is generated for you.

3. Open a command console and run the command:

nuget setApiKey Your-API-Key

4. Confirm you can view your NuGet package in the NuGet Gallery using the search or in the NuGet Package Manager in Visual Studio.

That’s it. There is however a word of caution, and here it is direct from Microsoft; does not support permanent deletion of packages, because that would break anyone who is depending on it remaining available. This is particularly true when using the workflow that restores packages on build.

Instead, supports a way to ‘unlist’ a package, which can be done in the package management page on the web site. When a package is unlisted, it no longer shows up in search and in any package listing, both on and from the NuGet Visual Studio extension (or nuget.exe). However, it remains downloadable by specifying its exact version, which is what allows the Restore workflow to continue working.

If you run into an exceptional situation where you think one of your packages must be deleted, this can be handled manually by the NuGet team. e.g. if there is a copyright infringement issue, or potentially harmful content, that could be a valid reason to delete it.

  1. Easy to setup.
  2. Publicly available.
  1. does not support permanent deletion of packages.
  2. Publicly available without a mechanism to restrict packages.

Hosting your own NuGet Feeds

There are several reasons you may want to host your own NuGet feed, but the most common two are;

1. You want to restrict access to the packages/libraries that your development team can use. E.g. filter the public NuGet gallery by creating your own.

2. You want to publish your own packages, but not have them publicly available.

If this is the case, then you’re going to want to consider creating your own NuGet Feed. To do this, you have a couple of options;

1. Shared Folders

Download packages from the NuGet gallery or package your own code with NuGet and then put the packages (.nupkg files) in a shared folder location. Network drives, DropBox or any other document sharing tool are great for this.  Then, simply add the shared folder location to the list of available package sources in NuGet package manager in Visual Studio.

2. Feed Server

Using IIS you can create and host your own internal or remote feed on a server. By adding the NuGet.Server package to an empty website project you enable the site to serve up the package feed using Open Data Protocol (OData).

Once you’ve deployed the site to an IIS server you can then access the oData feed by using a URL. e.g. http://yourdomain/nuget/

Then, simply add the feed server URL to the list of available package sources in NuGet package manager in Visual Studio.

Detailed instructions on both of these methods can be found at Hosting your Own NuGet Feeds.


1. Allows you to control/protect what packages are in the NuGet feed.

2. Ensures that packages are not available in the NuGet Gallery

3. Additional packages can be added and deleted from the feed using NuGet.exe


1. Requires additional configuration and some development.

2. Shared network drives will work, but are not ideal.

3. Only supports one NuGet feed, so all packages are available in one feed.

JetBrains TeamCity as a NuGet Server

In Version 7 of TeamCity, JetBrains added native support for the NuGet Server.

Enabling the NuGet Server is easy. Select the “NuGet Server” option from the “Administration” section and click  the “Enable” button.

TeamCity NuGet Administration
TeamCity NuGet Administration

Once enabled the NuGet server URL’s will be shown.

TeamCity NuGet Server URL's
TeamCity NuGet Server URL’s

The public feed URL is only shown if the “Allow to login as a guest user” setting in “Global Settings” is ticked.

The final step is to add a build step, with a runner type of NuGet Pack. The NuGet Pack build runner allows you to create a NuGet package from a given nuspec file.

TeamCity NuGet Pack Build Type)
TeamCity NuGet Pack Build Type

Then, simply add the feed server URL to the list of available package sources in NuGet package manager in Visual Studio.


1. NuGet package creation becomes part of the build process.

2. NuGet server is integrated into TeamCity. No custom configuration or development is required.

3. Supports both authenticated and unauthenticated access to the NuGet server allowing for greater control.


1. Requires TeamCity.

2. Only supports one NuGet feed, so all packages are available in one feed.

3. Multiple feeds would require multiple TeamCity instances.


MyGet is a hosted NuGet feed, NuGet-as-a-Service (NaaS). The product has some really nice features, allowing you to create public and private feeds, apply fine-grained user security and also has a range of package management features, such as retention policy.

There is a free plan, but as with all -as-a-service offerings there is a price to pay, ranging from $7 USD/month to $599 USD/year for the Enterprise plan.

We’ve done some basic tests and the product works well. They certainly, consider themselves a SaaS provider, hosting on Windows Azure and making Uptime Status reports available, which is great to see.

What interested us most are two BETA features MyGet are currently running; Build Services and Package Sources.

Build Services

MyGet build services allows you to add packages to your feed by providing Git, Mercurial or Subversion repo details. MyGet servers download the code, build the package, create the package and  publish it.

Currently this service supports Microsoft.NET framework up to Version 4.5 and supports build hooks (commit build triggers) which can be linked to GitHub or BitBucket repositories and will trigger a new build using a HTTP POST.

Package Sources

Package sources are upstream repositories for your MyGet feed. You can aggregate package sources in a single MyGet feed, filter each of them individually, and even proxy upstream package sources to include them in your feed queries.


1. Supports multiple feeds, so packages can be separated into distinct groups.

2. Fine-grained security

3. Hosted solution means you don’t have to set up your own infrastructure

4. Extended feature set. Features and more in beta.


1. Private feeds are not free as shown in Pricing Plans.

2. Unsure of customer uptake.

Inedo ProGet

ProGet is an on-premise NuGet package repository server.

This product has some nice features which include multiple feed support, feed filtering (only in Enterprise), granular security and package caching.

The product has 3 licensing options;

1. Free, with limited support and some feature limitations.

2. Enterprise Annual $395 USD/year.

3. Enterprise Perpetual $995 USD/ 1st year, with additional support at $195 USD /year.


1. Supports multiple feeds, so packages can be separated into distinct groups.

2. Fine-grained security

3. Additional features when compared to the roll-your-own server solution.


1. Requires additional infrastructure to setup, including SQL Server, but will run using SQL Express.

2. Feature limitation in free edition, as shown in licensing.

NuGet Summary

We hope that gives you a flavor of the NuGet package hosting solutions available. Each solution has advantages and disadvantages, but our advice would be;

1. If you’re creating a library to be used by developers in the public domain, choose NuGet Gallery.

2. If you’re using TeamCity, use the inbuilt NuGet Server. It’s real easy.

3. The choice between Local Feed Servers, MyGet and Inedo ProGet is a close call, but our winner was MyGet. The beta features,  Build Services and Package Sources made it our choice.