Octopus Deploy 3.0 details emerge

For months, I’ve been anticipating Octopus Deploy 3.0. The details have been slowly emerging over the past few months dating back to late November 2014 from several blog posts from the Octopus team. Each post has revealed some detail about the upcoming changes and technical details behind 3.0. Looking back on all the blog posts, I found four that explicitly state Octopus Deploy 3.0:

• 2014/11/27 – Octopus 3.0 – Switching to SQL
• 2014/12/16 – How we are using SQL
  
• 2015/01/11 – Actors vs. RPC in Octopus 3.0
• 2015/02/25 – Deployment targets in Octopus 3.0

Granted, everything is speculation until Octopus Deploy 3.0 is released, these posts give us something to look forward to. So what can we anticipate?
1. SQL Server is in; RavenDB is out – The back-end of Octopus Deploy is changing from RavenDB to SQL Server. This announcement leaves nothing to the imagination. This change gives users some advantages that embedded RavenDB could not. That’s not to say RavenDB couldn’t meet the needs of Octopus Deploy users, but the embedded license was a little restrictive and frankly, most users don’t know much about RavenDB at all. From a support perspective for Octopus, the switch makes sense. From a technical perspective, the customers benefit greatly. While I’ve seen first-hand that RavenDB is quite capable, most (if not all) of Octopus’s target audience doesn’t have the resources to support RavenDB.
Switching to SQL Server will allow organizations to be able to leverage staff, resources and licenses that they currently have. Also, different editions and versions of SQL Server – 2005, 2008, 2012, 2014 and above – any edition from Express to Enterprise as well as SQL Azure, will be supported which should meet everyone’s needs. It’s a big undertaking to swap the plumbing while testing all the permutations of configurations for 3.0. Note – only Octopus 2.6 is supported for upgrading to 3.0 so if anything, you should be planning on migrating to 2.6 if you’re not on it yet. 
2. Clustering – SQL Server’s editions create some interesting options regarding HA (high-availability) and DR (disaster-recovery) scenarios that could not be done with the embedded RavenDB license. Again, it’s not that RavenDB cannot do HA/DR, but the license bundled within the Octopus Server hamstrings that feature. No fault of Octopus Deploy or RavenDB. This is probably one of the biggest aspects we’re looking to leverage with SQL Server at the helm. We have a lot of SQL Server who can help us out and with their knowledge and our licenses, we’re going to have a very nice database “home” for Octopus Deploy 3.0.

With the ability to have multiple SQL Servers is the ability to setup multiple Octopus Servers reading from the same database cluster. This allows us to leverage our current load balancers and architect a highly-available 24/7 solution. We have developers all over the world from Spain to India, China, Philippines, Argentina as well as the United States. Keeping the Octopus Server available is a high priority for us as we’re pushing towards 1,500 deployments per month. I anticipate our monthly deployments trending higher when teams get the hang of using Octopus and really take advantage of deploying frequently as possible.
Having said that, while this configuration might not be a big feature you may want now, your situation may gradually change and having this HA/DR available, you will (at the very least) have the option to leverage it or not – either way you look at it, everyone wins.
Update: This tweet from Paul Stovell’s account showing an Octopus Deploy 3.0 server cluster:

3. New Tentacle Communication Model – Paul Stovell mentioned this in the Actors vs. RPC post in January and it wasn’t until the latest posts regarding deployment targets that a clear picture came to focus on what they had in mind.

Decoupling the communication logic (the SSH side of things) from the deployment logic is a much nicer architecture. So we’ve decided to do the same for Tentacles in 3.0: Tentacle will just know how to run commands or transfer files, over a secure connection. All the logic and tools for deployments will be sent up from the Octopus server, meaning Tentacle upgrades will be far less common.
From 3.0 onwards, think of Tentacle as a Windows-oriented version of SSH, except with support for both polling and listening modes. All it knows how to do is to execute PowerShell scripts, or transfer files. Everything else – the config transform stuff, the IIS stuff – will be PowerShell scripts that Octopus will ensure exist on the Octopus server prior to deployments executing.

Update: Somehow I managed to neglect the fact that Octopus Deploy will be Open Sourcing the new tentacle for 3.0! Like the OctoPack and DbUp, you can now work with the source code on GitHub.

Now that we’re decoupling Tentacle the communication channel from Tentacle the deployment engine, we gain a new possibility: all the scripts and deployment logic that Tentacle executes during a deployment (as well as the scripts and tools used in SSH deployments) can now be open sourced. Our plan is to manage this as a GitHub project. If you don’t like the scripts that we call during a deployment, you’ll be able to fork this, build your own Tentacle package, put it on the Octopus server and use your own scripts/tools during the deployment instead. It will also mean we can take community contributions, which will be especially helpful for supporting the various Linux distributions.

This is a welcome change indeed – if less tentacle upgrades are necessary and we can switch deployment targets on the Server, this is pretty slick. It answers a few user requests (Offline, Linux/SSH) while making tentacles more adaptive. And with this change in tentacle architecture, it appears that SSH will be a big part of the discussion for deployments from now on. Clearly this is spearheading into Linux turf and it’s a great first step. I’m very interested to see the new tentacles in action. Until Octopus Deploy 3.0 is released, a lot of this is still speculation based on blog posts, but it’s still rather enticing to think about what this means. Here’s to looking forward to Octopus Deploy 3.0.
*   Octopus tentacle [explore] from Grégory Thiell, used under Creative Commons.