Yesterday, we shipped Octopus Deploy 2.0. This is the official, non-beta, public, release-to-web version of Octopus 2.0. Woohoo!
Work on Octopus 2.0 started in May last year. Can you believe that? Instead of just adding a few features and changing the color scheme, we set out to make a true 2.0 release. We had learnt a lot making Octopus 1.0 and we wanted to make some pretty fundamental changes to the architecture and some core concepts in the product.
REST API
The change that had the biggest impact was the decision to make a fully comprehensive REST API. The user interface for Octopus 1.0 was built in ASP.NET MVC. For 2.0, we deleted nearly all of this code - the controllers and the views - and instead built a REST API from the ground up. Then, we built the UI using Angular JS on top of that API. There isn't a single thing that you can do in the UI that can't be done via the API now. In fact, for a long time the 2.0 code didn't have a UI at all; we built a suite of API tests that ran end-to-end, exercising all of the Octopus functionality using the REST API.
Polling Tentacles
Another huge area of change was in our communication stack between Octopus and Tentacles. In 1.0, we used WCF - the Tentacles listened, and Octopus connected.
In 2.0 we now support Tentacles in either listening or polling mode. To make this work, we developed a communication stack based on messages and actors, using HTTP and SSL at the transport layer to exchange messages. It's a pretty powerful mechanism for securely communicating in either direction with a network of servers, and it's a feature I'm looking forward to making more use of later.
Easier Windows Service and ASP.NET/IIS deployments
We added some new conventions and features to deal with Windows Service and IIS/ASP.NET application deployments.
Encrypted database and variables
The Octopus database is now encrypted, and we added support for encrypted variables too. If you're storing connection strings or passwords in variables, you can now do this in a secure way.
While we were at it, we also made it possible to share variables between projects.
Guided failures
When things go wrong, instead of the deployment simply failing, you can now choose to retry or skip failed steps.
Rolling deployments
Rolling deployments give you the ability to run a series of steps on one server before starting steps on another server. This makes scenarios such as deploying to a farm of web servers with limited downtime much easier.
New security model
We revisited our permissions model and tried to build something that was just as secure, but a lot more usable. Teams are a new concept that allow you to specify a set of users and their permissions, scoped to environments and/or projects.
Configurable dashboard
Yes, you can now, finally, change what appears on the dashboard.
Failure steps, and steps that run before package download
We implemented some big changes to the way deployment steps are managed. You can now run PowerShell and Manual steps prior to downloading packages (e.g., if you need to establish a VPN), or specify steps that only run on failure (e.g., send an email).
Variable editor improvements
In 1.0, a variable could only be scoped to one environment, machine, role or step at a time. Now, variables can be scoped to multiple levels at the same time. This greatly reduces the amount of variables needed. We also made some UX improvements such as editing multiple variables at once, deleting multiple variables at once, and a heap of other UI changes.
Summary
Since so much was being changed, we also made a lot of other improvements as we went. The installer got a makeover, the release creation page got some new features, we added graphs to the project list page to show activity, and a ton of other things.
If you're currently using 1.6, you should definitely upgrade. I hope you enjoy using Octopus 2.0 as much as we enjoyed building it!
