Poll VSTS release and deploy requests from Octopus

Our company is using VSTS in Azure and Octopus on-prem. I want to create Octopus releases at the end of the builds and then kick off the deploys from a VSTS release pipeline and watch the logs in the Release agent.
The problem is that my company will not allow the call to be initiated from Azure since the build and release agents that get spun up don’t have static IPs. Do you have a way that Octopus can perform a polling of our Azure VSTS tenant to see if it has anything to do. Currently, I am aware that Microsoft uses deployment groups that do just that and if we can’t get this functionality to work we may have to abandon Octopus and use the deployment groups that are built into VSTS.

Thanks Jeff Genova

Hi Jeff,

Thanks for getting in touch.

Tight spot indeed. There’s no out-of-the-box feature that allows Octopus to poll Tasks from an external source and start deployments based on them. You could build something fairly simple to act as a bridge that goes along these lines:

  1. Each VSTS build will send a Deployment entry to an Azure Function Webhook.

  2. When the Webhook receives a Deployment entry, It’ll invoke Octo.exe Create-Release and trigger a deployment in Octopus. This Azure Function can have its own certificate and static IP so your security team can lock things up and only allow data incoming from that webhook.

That said, we are interested to hear a bit more about your scenario:

  • You mentioned that your company doesn’t want to allow traffic from the VSTS dynamic agents because they don’t have static IPs. While that is true, they do have a fixed range based on regions (see more) . Locking it up by that range of IPs and the specific Octopus port would lock things up quite good. The Octopus API call would also be made using a specific APIkey, making it even harder for “someone in that IP range” to try to mess with your Octopus. Do you think this would be enough for your security team to allow incoming data?

  • Could you tell us a bit more about why is your Octopus server on-prem, but your builds are in the cloud and executed by dynamic agents? Its peculiar that your security team trusts the cloud for the builds and source control, but when it comes to Octopus they want it locked up on-prem. Would your security team consider moving Octopus to the cloud?

  • VSTS allows you to have on-prem agents. Do you think it would be feasible to spin up an on-prem agent right next to your Octopus Server?

Thanks in advance for taking the time to answer these questions. It definitely helps us understand the scenarios of our users to try to build a better product with each release :slight_smile:

Warm regards,
Dalmiro

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.