Over the past year I’ve been using the Octopus Deploy tool to automate database deployments. There’s been some ups and downs using Octopus: at first I thought it was the answer to many of my problems. However no tool is perfect and I do have issues around Script Modules and Step Templates, as well as integrating source control with Octopus.
However, I’m not going to focus on these issues: that’s for another blog. What I am going to do is talk about something in Octopus that is really well built, and that is the API.
Octopus is built API-first: anything done in the web portal uses the REST API itself. This is really reassuring to know that you can use the API in automation scripts and expect to get back exactly what you’d see in the web portal. And there’s quite a lot to go through in the API, as the documentation shows.
So, I thought I’d start a series on using the Octopus API. Over the coming posts I’m going to start with very simple calls to the API. Then as things get progressively more complicated, I’ll provide some functions. And then furthermore, I’ll write more complex PowerShell. At some point it will make sense to provide a repo online of the functions, perhaps in a module, and so I’ll blog about that.
But that is some way away. right now, let’s make a simple call to the API to return something. I’m using a copy of Octopus Deploy on my machine with a couple of projects, environments, machines and releases. I’d love to be able to provide a public version that people could request access to, but that’s not realistic at this point. What I will say is that whilst a majority of the calls to the API will be GET, so I will make it clear that any PUT or POST will be highlighted in big bold writing, so that you will have to tread very carefully if you’re not using a test instance of Octopus Deploy.
So, what is this call? Let’s get the info on a given project:
So this is getting the info a on a new project I created call “BZZT”. And all the properties returned matches the documentation provided by Octopus. Neat, right?
Currently the project is just a name, with the default lifecycle chosen. It doesn’t even have releases or a process yet. In the next part of this series I will add some releases/process steps to the project and dig more into the info returned, and how we can alter the values of the properties.