Octopus 4.0 (v4.0.4) was officially released as non-release candidate on Tuesday, November 21st 2017. Since then, Octopus has already pushed forward to v4.1 since and are at v4.1.5 as of last week on Wednesday, December 20th. I’ve been using Octopus Deploy since the early version 2.1 days so to have 4.0 (or rather 4.1) now released to the masses, I’m trying to take a step back to remember just how Octopus Deploy has built such a powerful yet simple tool over the past four years. Let’s take a look at their recent version history for some sense of how frequently they push out updates.
It’s impressive to see in the span between November and December of 2017, a total of 21 releases of which a major version shift from 3.x to 4.x as well. Since early 2014 to today, there are a few notable patterns from the Octopus Deploy organization I’ve observed over time and I’m sure others have noticed:
- Octopus 2.x releases were fairly frequent (weekly patch or two)
- Octopus 3.x releases were more frequent (roughly every other day or once every three days or so)
- Octopus 3.x minor version upgrades include newer (typically smaller) features and released every 4 to 6 weeks
- Octopus major version upgrades are significant changes and fewer but impactful features and released once every 14 to 18 months (-ish) time frame
Each one of these points highlights their philosophy and practices. Deploy changes frequently, and fix bugs fast. Create minor releases with new smaller features. Make meaningful and significant changes/improvements/features for major releases. It’s a strategy that has seemingly paid off for them. Their consistency and rapid speed to market has often out-paced me and I imagine many other users quite easily and their practices appear to be paving the way for even more features in 2018 and beyond. Having seen all the leaps being made over the past few years, I’ll admit I find the rate of improvements impressive considering all the newer features coming in during the minor version upgrades whilst maintaining all the support, bug fixes and planning out the major version upgrades.
If you’ve been reading about or using Octopus Deploy, you may have run across their UserVoice forum which users suggest features or ideas to implement. A few years ago, the list had grown quite a bit and the suggestions were definitely useful – but for Octopus to implement those features or ideas, some serious reworking of the user interface (UI) needed to be done. From Angular 1.4 to ReactJs and Redux. If you look at many of the suggestions, many of the concerns were clearly reflective of the UI at the time. While Octopus itself can scale – especially version 3.x, the UI itself wasn’t designed to match at scale as well.
While it seems easy to say they’ve simply upgraded the UI framework, rewrote everything for ReactJs that’s not the complete story. Simply swapping frameworks isn’t easy but the emphasis while UI /UX driven, really lays out the groundwork for implementing a lot of the features requested from the UserVoice forum. A lot of these changes could not have been easily done within the 3.x design and thus, the transition to ReactJs for version 4.x made a lot of sense.
To go through each screen and do an analysis would be a bit time consuming and perhaps a waste of your time. Instead, I’m going to focus on four notable features or updates that really stand out to me and recommend you to either download and try out Octopus for yourself or redirect you to their demo site: https://demo.octopusdeploy.com/. The features are in my preferred order but some may have a huge impact for your needs, while others won’t make much of a difference for you.
- Keyboard driven – It’s strange to highlight this feature but for a web app to be completely keyboard accessible is extremely useful if not wonderful. When I am working within a deployment process, to have it be completely accessible via keyboard makes rapidly working through changes faster. It’s an invisible feature that won’t be seen but will be felt for those who choose to use it. For users who move through any application web or otherwise via the keyboard, this is a huge feature. I applaud Octopus’s efforts for this level of user experience. It’s not a highly touted feature nor is it easy to show and not all users will use it which says a lot. It’s a feature that can benefit everyone, even if they’re unaware of it’s existence.
- Variables – the long awaited changes by not only the community but myself included, have finally materialized and it’s significantly better. I could go on into detail, but the blog post from Octopus is probably best to read for more detail. Even then, there were probably more changes made before 4.x was officially released. Being able to file out variables by name, value, description, scope, etc. is such a simple concept but until you see it you won’t appreciate the effort they put into streamlining variables. Not all projects are extremely variable heavy, but for those who are, this is probably the feature everyone was most likely waiting for and the Octopus team delivered.
- Collapsible elements – this is a simple yet nice feature allowing large pages of options, checkboxes and text boxes shrink down to allow you, the user to get to the exact field of interest. At first, I didn’t think it was a big deal – if you know what you’re looking for it’s fairly simple, but when you have numerous options within one deployment process step and it becomes cumbersome to find that needle in your haystack. Collapsible menus are just a simple fix for all the clutter.
- Environments – for environments with hundreds (which I’ve had a few) to thousands of servers (which I have yet to deal with) now have a much better experience than before. This was a serious issue for teams or projects with hundreds if not thousands of servers – this update is significant. For those with hundreds to thousands of servers to manage, this improvement makes life orders of magnitude more manageable.
Octopus version 4.x is a well-polished product. Off the top of my head, I can’t think of any significant features I’d want, but I’m sure there may be circumstances or edge cases that warrant more minor changes. That said, the way I use Octopus and in our production environment may not be comparable to most so it’s not completely fair to say that everything is perfect for every type of user. Quite frankly, deployment automation can be extremely complex and vast given the number of platforms, cloud providers, environments, security, configuration details and swath of layers in between, I don’t think I could say with any sense of certainty that any one product can solve all your deployment problems. But I’d argue Octopus Deploy comes pretty damn close.
Octopus is consistently pushing out updates, bug fixes, smaller features and with bigger features always being on the horizon. I’ve watched Octopus Deploy mature over time as a product (and as a company to some extent) that is capable of incorporating features and changes at a rapid pace. If you’re debating on whether or not to try Octopus Deploy out, I would encourage at the very least a test run. It’s easy to setup and is not resource intensive. With multi-OS support now for both Windows and a few Linux OSes and now Java support, there’s no excuse for not trying it out and the latest 4.x version will make your experience worth while.