Recently at Octopus HQ we've been looking at how to better integrate with other tools in the DevOps ecosystem.
We've spent some time looking at what other tools exist in similar spaces, what people are using with Octopus Deploy, as well as where our customers are already writing integrations with their existing tools.
We've got some ideas for how best to support the sorts of tools and products that are currently a bit tricky, and better ways to do a few things people are already doing. We've come up with a few features for Octopus which will enable more and better integrations, as well as better support for some custom processes you might want to use.
Introducing Octopus Reactions
We are proposing a new feature for Octopus we're currently calling Reactions. It will allow you to take internal and external events (triggers) and map them to some custom actions, either in the form of PowerShell scripts OR outgoing HTTP requests.
Triggers and Actions
There are two types of event triggers available for a Reaction. An internal event such as a Deployment Succeeding or Failing, a Release being created, a Tentacle being Registered, or a Deployment Process being Updated. We also have external events such as a new package being available in an external package repository which can received as an HTTP webhook request.
In the event of an internal or external trigger, we can initiate an Action.
For example, we may want to map our external HTTP trigger from our Artifact Repository to a PowerShell script to create a new release.
We have Auto Release Creation for Packages in our internal NuGet repository, but we've never supported external repositories such as MyGet because polling these services wouldn't make us a good citizen.
This feature would allow us to implement this with a webhook trigger. When Octopus gets an HTTP request in the pattern it's expecting, it would trigger a script which could query back to your package repository to build some release notes then create a release.
Another example might be using Octopus events such as deployments starting and finishing to notify an external monitoring system via their HTTP API. In this case we'd map an internal trigger to an outgoing HTTP request.
What this might look like
Adding a new Reaction would be a matter of choosing the trigger, adding a filter (in the case of some of the internal events) then creating the corresponding action.
External Triggers with PowerShell Actions
An external trigger would be created by defining an endpoint, much like the way you'd define an ASP.NET Route. As an example, you might want to have a Reaction to a new package being available in MyGet, so you might define an endpoint of /triggers/mygetpackage (i.e. https://octopus.yourcompany.com/triggers/mygetpackage) and configure that in MyGet.
For authentication, we'll probably require an API key to be passed either in a query string or an HTTP header.
Most products that will send a HTTP WebHook pass a JSON payload as the body of the request. We'd deserialize this to a PowerShell object and pass it, as well as any Query String parameters, to the PowerShell script. The script would also have a bootstrapped API client available so you could work with the Octopus API to create releases.
Internal Events and Outgoing HTTP Actions
A common scenario we've seen people write step templates for is to notify a monitoring or analytics system such as New Relic, AppDynamics, or Raygun that a deployment is starting and finishing. By integrating with these systems we can have alert thresholds relaxed during deployment, as well as mark versions for later performance correlation.
To create this we'd choose the internal event (Deployment Started then Deployment Succeeded), Apply filters to choose the Project and environment we're interested in (e.g. Core Web application in Production), then define the HTTP request by specifying the URI, Headers, and body.
To build the HTTP request we'd include the standard Octopus Deploy text templating features to include variables like Release Versions and other relevant variables.
Internal Events and PowerShell Actions
A couple of types of scenarios come to mind here. The first might be similar to the previous one but where the third party integration is more complex than a simple HTTP request, we could use PowerShell to integrate more tightly with a product (perhaps there is an API DLL we need to use). The second type is internal Octopus operations we'd like to kick off based on other operations finishing. An example might be a new Tentacle registration triggering a deployment (a scenario we've talked about doing automatically, but this could be a finer grained way of implementing this). Another example might be creating and deploying a new release of a Project if a dependent component had a new version released.
In these cases the PowerShell script would be bootstrapped with an API client as well as any relevant variables based on the event (Project ID, Release ID, Deployment ID, Machine ID etc).
External Events and Outgoing HTTP Actions
This scenario doesn't really make sense so we most likely wouldn't support it. Octopus would just be acting as a passthrough HTTP broker and there are probably better ways of achieving any scenario this would open up.
Some things we're still thinking through
There are a couple of things we'll still need to figure out here, permissions is the first one that comes to mind.
Making it simpler
We think these features open up a lot of power and possibilities to extend Octopus Deploy. The risk here is that creating and managing all your Reactions will get a little cumbersome. What we'll probably do is to pre-build a lot of the third party integrations and allow you to select them, add in any account specific stuff (API tokens etc) and have them configured for you.
Over to you
Do these features sound like something you'd use? Are there any scenarios we're missing? Let us know your thoughts.
