Introduction
To give you a little background, I started a job back in mid-January which has taken me from doing Microsoft infrastructure engineering to doing more software development related work. I’ve never worked in a professional development environment before, and this job has been a real eye-opener for me in many different ways. I’m learning lots of new technology, and I’m learning a lot about how professional development teams work.
During the course of my learnings, I have been introduced to a very cool tool which helps with release management for ASP.NET applications (or probably any type of service-based application).
Octo-what?
It’s interesting how there’s all these funny names for software projects in development field. Sometimes the project’s name is entirely relevant, and other times, you had to wonder if someone went through a children’s picture book and plopped their finger down on a random page they opened to. Thankfully the author (Paul Stovell) of this project known as “Octopus” chose a name that is intricately tied to how the software works.
Octopus has a central server service (and website) which handles the configuration of the tool, and the deployment end-points are befittingly known as Octopus “tentacles.”
Environments, Projects, Tasks, oh my!
Octopus is a very simple tool to use, and doesn’t require a whole lot of configuration. Once the server is set up and configured, you can go ahead and start configuring your software releases in the [very clean] Octopus web interface.
Settings
Before you get too far in, you’ll need to set up a NuGet package URL in the Octopus Settings page. The NuGet package feed will be used later on to run software releases.
Environments
First off, you’ve got the ability to define multiple server “environments.” These environments allow you to specify one or more servers of one of three types:
You’ll probably end up setting up environment names similar to other development teams:
- Dev
- Test
- Staging
- Preview
- Production
- etc.
You don’t have to install the Octopus tentacle on the servers before you add them to the environment configuration, but until you do, they’ll show up as offline tentacles. Octopus has a built-in health check task that will automatically check the health of the tentacle endpoints every five (5) minutes.
Projects
Once you’ve built out your deployment environments, you can begin building your projects. Projects are the applications that you want to deploy. Creating a new project is as simple as giving it a name and an optional description.
Deployment Steps
Each Octopus project consists of several “Deployment Steps” that are executed in sequence. Each step represents a NuGet package that is executed.
Release History
As you build our your projects and begin performing releases, you’ll get a Release History under each project’s details. It shows each build number and environment that was deployed to, and the date/time that the deployment occurred at.
Variables
You can define variables in your Octopus project, which will then be passed to the PowerShell pre-deploy, deploy, and post-deploy scripts. These scripts are discussed in more detail in the Octopus documentation.
Conclusion
This has been a very brief overview of the Octopus .NET Deployment tool. I hope you’ll take a look at the tool for yourself. In terms of creating a consistent, repeatable, automated software release process, you can’t go wrong with Octopus.
