Octopus Deploy 2017 Roadmap

Octopus Deploy 2017 roadmap

Since the early days of Octopus, I've always been a believer in making our roadmap public. When Octopus was just me, I used to keep a public Trello board with everything I was planning to do. When we outgrew a single Trello board we started to keep a GitHub issues list and a public roadmap page with our high-level plans.

As 2016 came to a close and we started planning 2017, we spent a lot of time thinking about what we wanted to accomplish this year, and I've put that into this roadmap for 2017. We have some ambitious goals this year and I'm very excited about what's on this list. Enjoy!

Summary

By the end of 2017:

  • Octopus will have implemented all UserVoice items with over 200 votes
  • Octopus will have a lower learning curve
  • Octopus will have first-class PowerShell DSC support and be used to manage running applications
  • Octopus will have a better UI for configuring deployment steps, and support every option in IIS
  • Octopus users should be able to interact with Octopus via a Slack chat app
  • Octopus will expose its API with Swagger, making it easier for end users to use our APIs
  • Octopus will have better built-in support for Amazon Web Services
  • Octopus will enable Linux deployments for customers that don't want to install Mono
  • Octopus will make PCI-compliant deployments supported out of the box via release promotions
  • Octopus will be available as a production-ready platform-as-a-service solution

Overall strategy

For Octopus, true long-term success is measured by the number of active, successful installations. Everything on this roadmap is designed to contribute to this - either by:

  • Keeping existing customers happy they chose Octopus, and giving them reasons to renew
  • Expanding the range of scenarios that Octopus can support
  • Making it easier to use

High Level Roadmap

These are the headline items on our roadmap this year. For most of these, we'll publish our traditional RFC posts as we begin to design and work on them, so I'm only including short summaries of what each of them are below. If you have any questions or ideas, feel free to put them in the comments!

All UserVoice items with over 200 votes

With over 914 ideas in our UserVoice site currently, it's unlikely that we'll get to the long tail of them, and I don't think any of our customers would expect us to build all of them. However, many of the suggestions have hundreds of votes and have been open for a few years now, which is unacceptable. So this year we're vowing to do something about all suggestions with over 200 votes.

Here's the list as it stands today:

Octopus Ops

For many smaller teams, Octopus is the closest thing they have to a general "DevOps" tool. Like everyone, they use it to deploy ASP.NET applications, database upgrades and Windows Services. But they also use it to run ad-hoc scripts across machines, or as a configuration management and machine provisioning tool. Or they use our health checks as a monitoring tool.

While there are plenty of great tools out there that specialize in configuration management or monitoring, and we don't plan to go out and compete with them, we do see that for smaller environments Octopus can be pretty good at doing those jobs. We want to expand on that a bit this year in two different ways.

First, we're going to ensure Octopus a first-class PowerShell DSC experience. I already wrote about how you can use PowerShell DSC support in Octopus. We'll polish this by supporting reboots, and doing some UI work to make it more streamlined.

Second, we're going to finally implement the operations features discussed in our Monitoring & Service Management RFC. As I wrote in that RFC:

The Octopus dashboard shows you whether your last production deployment was successful. What if it also showed you whether what you deployed is still running? ... It wouldn't just be limited to monitoring status though: you could also start/stop these services. Did the Windows Service that you deployed yesterday to 30 machines suddenly crash on 7 of them? No problem, just click the button, choose the 7 you want to restart, and hit the execute button. Sure beats using remote desktop! Plus, there would be a nice audit trail.

The building blocks for these two projects already exist: scriptable health checks, PowerShell steps, and the step template runner provide most of the implementation work already. We just need to glue them together and show people how to use it.

Octopus Slack App

We've just shipped "Subscriptions" support in Octopus, which lets us notify a web service when events happen within Octopus. This, plus our API, are all the building blocks that we need to build the "ChatOps" experience we've been dreaming of. This will take the form of a Slack App that customers can connect to their Octopus server. You'll be able to associate the Slack app with your Octopus server, and do things like:

  • Ask it what's deployed in production
  • Tell it to promote the release in Test to Production
  • Be notified of deployment status

New Step Builder and a lot more IIS options

To date, the UI for configuring a deployment step in Octopus has had to balance:

  • Letting you configure everything you need for your deployment
  • Not overwhelming you with all the options

For deployment steps that configure things like Windows Services, there's only a handful of options anyway. But some steps, like those that configure IIS, have potentially hundreds of different settings you might want to set. For now, this has meant that we only expose the most common settings, and you have to write PowerShell to do the rest.

We spent some time thinking about alternative UI's that would allow us to gradually expose settings that you care about changing, and hiding the ones you don't care about, and I think we've figured out how to do that. We'll know we've achieved this when every IIS setting you could ever want to configure in Octopus.

Lower the learning curve

Octopus is one of those "set it and forget it" tools; you download it, set it up, and spend a bit of time setting up your deployment process. You iterate a few times, until the process and variables are exactly what you need. When all that is done, you can settle into a nice rhythm of creating and deploying releases - you only have to modify the process if your deployment needs change.

That initial deployment process configuration has been the difficult part for most people. This year we'll be doing a lot of work to try and make the setup simpler and more streamlined.

Mono-free Linux (SSH) deployments

Octopus currently supports deployments to machines over SSH using Bash, allowing it to be used to deploy to Linux servers (among other things). However there's one drawback: we currently require Mono to be installed, because of how we invoke those scripts. For some people that's just too big of a dependency, too difficult to install, or just not something they are comfortable with.

For cases when you are just running a simple script, we're going to make it possible to just run the script without requiring Mono. How you access Octopus variables will probably change, but otherwise everything will just work. For full package deployments with our built-in conventions, we'll still use our Calamari tools, but we're porting them to .NET Core (and may be able to compile them natively for common architectures) so there will be less dependencies.

Octopus Release Promotions

Many customers work in environment where releases must flow between more than one Octopus server - the two most common scenarios being:

  • PCI compliant environments where the Octopus that deploys to production must be isolated
  • Agencies which use one Octopus for dev/test, but then need an Octopus server at each of their customer's sites to do production deployments

We've had numerous attempts at solving these scenarios in the past:

  • Octo.exe export - this was limited but worked for many people
  • Octopus Migrator - this exported pretty much everything, but was too noisy - people mostly care about promoting individual releases
  • Offline Drops - these work when the downstream environment is small, but you quickly end up reproducing Octopus yourself when the machine count increases

We're going to try and solve this once and for all by letting you declare "downstream" and "upstream" environments in one Octopus server that are actually managed in another Octopus server, and to promote releases between them.

When you promote a release to a downstream Octopus server, we'll export the release, the packages, the variables and process snapshots, and everything else that the downstream Octopus server needs to know about. You'll be able to automatically flow this export between Octopus servers if they are network connected, or put them on a USB drive for air gap deployments. When you deploy them in the downstream Octopus, you'll get a "receipt" which can be imported in the upstream Octopus.

I'm hoping that by building this feature, we'll be able to eliminate all three of those previous attempts at solving this scenario, plus save a lot of customers from trying to solve this problem manually.

"Swaggerize" our API

We took a big risk in Octopus 2 by building a REST API for everything in Octopus, and then rewriting our entire UI on top of it. This API-first mentality has served us well, and has become very popular - people use our API to do all kinds of things I never imagined.

We're going to make the API even more discoverable by paying down some technical debt (our API is harder to maintain for us than it should be) and adding support for Swagger, which will give you a brilliant UI to explore our API. This should make building against our API much easier.

Tighter AWS integration

For Azure users, Octopus already has deployment steps and account support built-in. We'll continue to add more steps (Azure Service Fabric being the most obvious), but we'll also bring support for AWS up to par. We'll add support for AWS accounts, and steps for working with common AWS services like CloudFormation, EC2, S3 and Elastic Beanstalk.

PaaS Octopus

When I started Octopus, the cloud hadn't gained much traction and our customers were almost completely on-premises. We've noticed more and more customers moving their code and CI environments to the cloud, either with GitHub/AppVeyor or VSTS, and think that trend is only headed in one direction. We recently added Octopus to the Azure marketplace so you can spin up an Octopus server in your own subscription, but we think we need to go further.

For me as the founder/CEO, this is the most difficult item on this roadmap because it requires not just technical changes, but organizational change - from being a shrinkwrap software vendor to learning how to grow and support a PaaS offering.

Closing

We put a lot of thought into our roadmap for this year, and there's a wide range of items on it. I'm sure there will be some disappointment - everyone has something they wish Octopus could do, myself included - but I also hope there's something of value on here for everyone. All the best for 2017!

Tagged with: RFC Company

Related posts