A few weeks ago I posted some screenshots of an application I'm working on. A few people guessed, rightly, that it is a tool for automated deployment. Progress is going well, so I'd like to share some more details, and get your feedback.

Octopus is a automated deployment solution for .NET applications, powered by NuGet and designed for convention over configuration.

• Deploy Web applications and Windows Services
• Configure your applications automatically
• Works inside your network or over the internet, securely
• Track and report on how releases are promoted between environments

I'm working my way through the SecretGeek 25 things list, and writing plenty of code. My goal is to have Octopus ready for beta testing in a few weeks. If you'd be interested in taking Octopus for a spin, add your email address below. I promise to only send occasional updates as the beta program opens.

Where Octopus fits in

Imagine your development team has been charged with building an intranet web solution. The solution consists of:

• An ASP.NET MVC web site
• A SQL Server database
• A Windows Service for performing some long-running tasks

The team are working iteratively. They check code into source control, and the build server picks up the code, compiles it, and produces artefacts ready to be deployed. Now, someone has to figure out how to deploy it.

Every application has different deployment needs, but they are usually pretty similar:

1. The CI server builds the code and products artefacts (Zip files, WebDeploy packages, MSI's, etc.)
2. The artifacts are copied and extracted on the target server(s)
3. Web/App.config settings and connection strings are updated
4. Performance counters and event log entries are created
5. IIS web sites are configured
6. Windows Services are installed and started

Ideally, these deployment steps would be automated. Unfortunately automating these deployments still takes a lot of manual work. Usually the solution is a cobbled together band-aid solution of PowerShell scripts, XPath queries, batch files and point-and-click tools.

Once you've cobbled together the PowerShell scripts and MSI packages for your application, zoom out, and look at the rest of your organization. How many other projects do you have? How many of them have automated deployment? How different is the deployment process for each application? Does it need to be this hard?

Octopus in action

Here's where Octopus fits in a typical organization:

1. Developers check code into source control
2. The CI server (TeamCity, TFS, CCNet, whatever) compiles the code, and packages it into NuGet packages (I'll explain why below)
3. The NuGet packages are exposed via a NuGet feed to Octopus
4. A release manager commands Octopus to deploy a "release" of your application to an environment (staging, production, etc.)
5. Octopus assembles all the NuGet packages, and pushes them to a "Tentacle", a small Windows Service that runs on your UAT/staging/production machines.
6. The Tentacle agent deploys the NuGet package, and configures it (see below)

Concepts

Octopus understands a few simple concepts:

• Package: A NuGet package containing the smallest unit of deployment for part of your solution (for example, YourApp.Web, YourApp.Database)
• Project: A group of packages and deployment steps, for example, YourApp
• Release: A set of packages, with versions, for a project. For example, YourApp release 1.5 contains packages YourApp.Web 1.5.3 and YourApp.Database 1.5.1
• Machine: A computer running the Tentacle service, that you intend to deploy packages to
• Environment: A collection of computers, such as Staging or Production

Most of these concepts should be pretty intuitive from the UI - my goal is to make the release process pleasurable. Check out some of the screenshots to see where it's going.

Convention over configuration

Octopus was inspired by AppHarbor, which performs automated deployment of .NET applications from Git/Mercurial check-ins. AppHarbor has a very clever system for dealing with deployment:

• If your VS solution has a Web project, it deploys it to an IIS site
• If your web.config file has AppSettings with names matching variables you declare in the UI, they are automatically replaced

The end result is you never need to write automated deployment scripts for AppHarbor applications - it's automatic, because most applications work the same way.

Octopus shamelessly steals "borrows" these ideas, making enterprise application deployment as easy as cloud deployment on AppHarbor.

Conventions in Octopus include:

1. Replacing appSettings and configurationStrings entries
2. Updating the path of IIS websites if your package contains a web.config
3. Running any System.Configuration.Install.Installers (for performance counters, event logs and Windows Services)
4. Invoking a "Deploy.ps1" PowerShell script, if your package contains one

The cool thing is that all of these steps are run locally on the target server; you don't need to mess around with configuring WinRM or PowerShell Remoting.

NuGet packages

Instead of MSI's, Zip files or WebDeploy packages, Octopus standardizes on the NuGet package format. There are a few reasons for this:

1. Packaging files into a NuGet package is extremely easy
2. NuGet packages can be consumed via a feed, so other applications can easily query the available packages
3. CI tools like TFS and TeamCity will soon have support to make publishing NuGet packages easy

At first this might seem like a strange use of NuGet. Currently, NuGet is mostly used for packaging DLL's and other files, mostly for open source components. Why use NuGet for packaging complete web applications or Windows Services?

If you spend time in the world of Linux however, you can see that package managers (like NuGet) have evolved beyond libraries. If you want to install Apache or MySQL on Linux, you'll use a package manager. Shouldn't we be able to do the same on Windows?

An aspect of this idea that I think is really interesting is the concept of an internal "enterprise software inventory". Imagine if every version of every internal application you built was available from a NuGet feed, instead of a mix of File Shares, TFS Drops and TeamCity artifacts?

Reports and metrics

Since Octopus takes a pretty holistic view of your projects, environments and releases, it can be used to answer some interesting questions:

1. How long on average does it take Project A to get from Staging to Production?
2. How often do Staging releases fail user acceptance testing before going to Production?
3. Which version of Project A is in UAT right now?
4. What were the release notes of version 1.4 of Project A?

The business

I've spent a lot of time over the past few years working on open source projects. Open source projects are hard. Getting contributors is tricky, and even when you do, they usually focus on contributing "fun" features rather than bug fixing and documentation. Unless your project is large enough to have a lot of momentum, it's hard to attract committed contributors to do the not-so-fun things.

I think Octopus stands a much bigger chance of succeeding if it has people committed to doing the not-so-fun things, producing a very useful, very high-quality product that you can trust to reliably deploy your software. For this reason (plus, well, greed :-)) Octopus is going to be a commercial product, and my first MicroISV. Even if it's a colossal commercial failure, I'm looking forward to the experience of product development.

Pricing

At this stage I expect Octopus will be priced using a TeamCity model - free enough that you can use it to deploy one project to your organization, but by the time you need to deploy your second project, you'll have gotten enough value from it that you won't mind sharing the love.

What do you think?

This is one of my longer blog posts, and I hope I've done a good job of explaining what Octopus is all about. I'd like feedback, good or bad, about the direction. Specifically:

• What do you think about the conventions? Can you think of any others? I've documented them a little better on the knowledge base.
• Is the system described above something that you could see yourself/your organization using?
• How are automated releases currently done within your organization?
• What additional reports/metrics would be useful?