When a product or technology is introduced, it starts out feeling fresh and innovative. Over time, it finds a market and starts to spread. Eventually, everyone you know is using it. And then, eventually, it starts to fade away. The Diffusion of Innovations theory provides a way of understanding this process, and it is often illustrated as a bell curve:
In our industry this whole lifecycle may only take a few years. Right now, Octopus Deploy is finding its market among those innovators and early adopters. In fact, we were recently added to the ThoughtWorks Technology Radar in the Assess category:
Tools like Chef and Puppet are increasing their support, but there are also Windows specific solutions being developed like Octopus. Octopus allows automated deployment of your ASP.NET applications and Windows services and decreases dependency on PowerShell. It can be used with both NuGet using Octopak and TeamCity to create a full build, package, and deployment pipeline.
When Octopus Deploy 1.0 was first released we had a pretty basic feature set - we could download a NuGet package, and push it to a remote agent, and run PowerShell scripts with some very basic configuration support. Since then we've added:
- Windows Azure, FTP and ScriptCS support
- Manual deployment, ad-hoc PowerShell and email steps
- Automatic Tentacle installation and registration
- A native plugin for TeamCity
- Retention policies
- A powerful permissions model
When we first shipped, I expected Octopus Deploy to be used by customers with a handful of projects, deploying them to a dozen or so machines. I figured that banks and the fortune 500 wouldn't go near it. In reality, we have customers using Octopus to deploy over 200 projects to 300+ machines, and is being used by some pretty recognizable brands. People aren't just trialing it, they are seriously committing to it.
We've also learned a lot about the trade-offs and limitations of our current architecture and ways it could be improved. There are features that we'd love to add that just aren't possible without revisiting large parts of the application.
What is a 2.0?
At this point, there's a temptation to just stick with the current architecture. It may not be perfect, but it's working. We could add a few small features here and there and call it version 2.0, without doing anything too significant or risky. Then we'd switch to marketing mode and hope that the Diffusion of Innovations model takes its course, and we grow without doing much more work. And, eventually, someone else would come up with a better product and we'd fade away.
I think we can do better.
We're not going to go so far as to completely rewrite everything, as that would be a bad idea. But at the same time, 2.0 is going to be different. 1.0 was a great way to learn more about the problems we're trying to solve with Octopus, and 2.0 is where we'll apply those lessons. Octopus 2.0 will be the product someone else would have built.
However there's an equal temptation to fall into the trap of second system effect:
As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used 'next time.' Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system... The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.
Certainly when building Octopus 1.X there have been plenty "if we had only done this thing different, that thing would be way easier to add" moments. I'm hoping we'll be able to address some of those issues, but without going too far.
Big changes for 2.0
The biggest change we've made so far in 2.0 is to go HTTP API-first. Everything the server can do will be exposed via the REST API, and the web user interface is going to be built in JavaScript. There will also be a C# client library that you can use that provides a friendly wrapper over the REST API.
In fact, right now, Octopus 2.0 doesn't have much of a UI at all; I'm doing most of the work through an automated API test suite that I blogged about on my personal blog recently.
Since the web stack was being revisited, we even re-evaluated whether the Octopus 1.0 choice of ASP.NET MVC running on IIS was still valid. And it wasn't. Instead, Octopus 2.0 uses Nancy, self-hosted. When you install Octopus 2.0, there'll just be a Windows Service; there won't be an IIS application, and you won't need to install IIS on the Octopus server anymore. That also cuts out a whole bunch of support issues for us.
We're doing other things differently too. We're embracing eventual consistency, so everything feels really fast. And we're designing the new UI to work much better for very large amounts of projects, environments and machines.
We're also making some conceptual changes. These aren't just new features, but different ways of thinking about the world:
- Instead of a project having a list of steps, projects have a deployment process that provides a lot more control about what to do on failure.
- We're introducing support for multi-tenant deployments
- You'll be able to create global variables, environment variables, and project group variables, all with multiple scoping options
- We're going to be dealing with variable/step snapshots quite differently
I'll blog more details about these changes as we get further into building Octopus 2.0 and we have a better understanding of the changes.
When?!
When will it ship? Once we've made some more progress on the UI (the REST API is now looking pretty complete) we'll try to make beta downloads available for people who want to give it a try. I'm hoping we'll have something to release by the end of August/September, but we'll know more as we get closer to a beta release.
No comments:
Post a Comment