About Octopus Deploy
Octopus Deploy Pty. Ltd. | Founded: 2011 | Location: Brisbane, QLD, Australia
Vision: to ensure all.NET developers can realize the benefits of automated deployment.
Hi, my name is Paul Stovell. Allow me to introduce myself and explain why Octopus Deploy exists, and how we're going about our mission.
Prior to working on Octopus Deploy, I lived in Australia and the UK, working as a consultant and independent contractor with a focus on building ASP.NET and WPF applications. I travelled a lot for work, and did a lot of short-term engagements - two weeks here, 6 weeks there, that sort of thing. Often, my job was to build an application and get it into production, or to mentor a team to do the same.
All of the teams I worked with had various levels of maturity when it came to agile software delivery. First, they'd set up source control. Next, a product backlog and issue tracker. Next automated builds. And finally, automated deployment.
The last part was rare. A team might have Mercurial and TeamCity running, or Team Foundation Server, but deployments were still handled manually, often by a team member who was overworked.
Even on teams where automated deployment was set up, it wasn't very inspirational. Imagine reams and reams of PowerShell scripts, complicated PowerShell remoting configurations, batch files that had to be run over remote desktop, FTP, and very little visibility.
Why do so many teams have source control and automated builds, but not automated - or barely-automated - deployments? I think the answer is: because automating deployments is complicated. Source control is easy to set up - just install a server, and check files in. Automated builds are also easy by comparison: check out code, compile it, run some tests, produce some artifacts.
Automated deployment involves many concerns. There's security to worry about: who's allowed to deploy to production? How will we move the files from our LAN to our data center in a secure way? Then there's implementation: How do we automate all the steps needed to deploy and configure the application? How will we change configuration settings for each environment? There are many moving parts needed to make repeatable, reliable automated deployments.
Cloud solutions like Heroku and AppHarbor were making automated deployment look easy. As long as you follow a few conventions, you hardly have to think about deployment - it just works. But they were limited to the cloud. Many of us are still building applications that need to run within the firewall, or within a corporate data center.
I asked myself: why can't deployment automation be as easy as deploying to the cloud? Why can't it be as quick to set up as automated builds?
Prototyping and beta testing
Through 2011 I prototyped the product and released some beta releases, while continuing to work at my day job. I was getting amazing and high quality feedback from people using it. Sales started coming in regularly, but since I was only able to work on the application at nights and on weekends, it was hard to take it to where I needed it to go.
Going full time
In June 2012, just before Octopus Deploy 1.0 was released, I quit my day job to work on Octopus full time. Octopus has evolved from a side project into a sustainable business. Our team is small but growing, and we are committed to making automated deployment as common as source control for .NET developers.
I hope you'll evaluate our product.
ABN: 69 160 339 186