If you're one of the many Visual Studio Team Services (VSTS) or Team Foundation Server (TFS) users who make use of the Octopus Deploy Build and Release Tasks extension, you might have noticed a couple of changes. I thought I'd take a moment to explain these changes and let you know what else we're working on in that space.
Wait, what new version?
The new version of the extension is 2.0.6 (at time of writing), but if you're currently using version 1.2.81 of the extension, you won't see a change straight away.
The UI for parts of VSTS (including Build Tasks and extensions) is still changing rapidly, and some recent changes are all about a safer update process for breaking changes. In short, if the major version of an extension changes, you'll have to explicitly update the extension before you can use it.
To get the new version, you'll have to update by going to the Manage Extensions page.
Click the link telling you an update is required.
Finally, review the changes and update. You'll need to have the correct permissions to do this of course.
Using the new version
If you're already using the Octopus Deploy steps in your build definition, you'll now see a little pink flag next to those steps (you may need to force a refresh in your browser). This indicates that there's a newer version of the build and release step you can use. Minor and patch version updates will be applied automatically, and I promise we won't make any breaking changes without updating the major version!
To move to the latest version, in the configuration for each step you'll see a new version dropdown. This lets you pick the step version you want to use.
Older versions of these steps will continue to work, but when you add one from the Add Build Step menu, it will default to the latest version. You might also notice nice new logos thanks to Jess!)
To start using the new steps, you'll have to start with a new Octopus connection.
Octopus Service Endpoint
Our extension now includes a specific service endpoint type for Octopus!
Having our own endpoint makes it much clearer what the connection is for, and there's also the obvious advantage of putting your API Key in an "API Key" field rather than the password field, but there's more going on behind the scenes.
Defining a specific Octopus endpoint lets us provide "data sources" that can be used from various parts of VSTS. At the moment, we're using these to give information to dropdowns in the build and release steps (see below), and we'll no doubt make use of them for much more in the future.
Dropdowns in Task Fields
One big advantage of using the new service endpoint is the ability to retrieve data from an Octopus server, and expose that inside the VSTS UI.
That means when you choose the Octopus endpoint when using the build and release tasks, the Project Name field (which is now a dropdown) is populated with all the projects on your Octopus server. It's a similar story for Environments, Channels and Tenants if they're applicable to your scenario. This saves you from opening Octopus to make sure you get it right, and should make it much harder to make a typo!
A quick note on security
Whenever VSTS/TFS connects to Octopus, it uses the the API key you provided for the new service endpoint. That means you'll only be able to see the projects, environments, channels, and tenants viewable by that user. If the user's permissions are restricted at all, you should expect a similar restriction through that endpoint.
The extension talks to Octopus from two distinct places - the VSTS UI (when you're configuring your build/release), and the build/release agent itself (when the build/release is running).
When you're configuring the tasks in the UI, it's the VSTS or TFS server that communicates with Octopus. That means in order for the new dropdowns to work properly, that server must have access to Octopus. If it doesn't, you can just type the details in directly.
This is distinct from when you're performing a build or release. In that case, it's the agent that connects to Octopus. If you don't want to make Octopus available to the cloud-hosted build agents, you can use a local agent instead. This local agent can live inside your network so it can access Octopus and other resources you might need.
So what's next?
We're planning on following up fairly soon with a dashboard widget so you can see the status of your deployments without leaving VSTS.
There are plenty of other extensibility points available in VSTS, so we'd love to hear what else you might find useful! What should we look at next?