Create build artifact on azure and get local Octopus server to release

usability
server
known
#1

We currently use TeamCity to build, package, deploy to our local Octopus Server.

However, there’s interest in moving our CI (TeamCity) process to DevOps pipelines and I’m trying to find out how to do this.

Where we want to be is:

Devops builds and creates a package
Our local Octopus server sees that a package has been created and so gets the package and deploys it.
(For some Octopus projects we want to deploy and and auto release to our dev environment.)

I’d appreciate some resources that might be able to help me achieve this.

(Paul Calvert) #3

Hi @janwillemwilson,

Thanks for getting in touch!

The typical setup would be to use Azure DevOps to control the entire process, including telling Octopus when a build has been completed, creating the release and then deploying it.

We do now have a handy guide generator on our main page, Octopus.com, however the guide for using Azure as the package repository hasn’t been completed yet.
Instead, you should be able to use the guide for artifactory instead e.g. https://octopus.com/docs/guides/deploy-aspnet-app/to-iis/using-octopus-onprem-azure-devops-artifactory and then just configure Azure as the package feed rather than artifactory as described here.

I hope this helps get you started, please let me know if you have any further questions.

Best regards,
Paul

#4

Hi Paul,

Thanks for the prompt response. I’ve checked out the link you provided which all seems straightforward.

However, point 3 talks about the change being deployed to Dev.

We won’t be able to do this as there will be inbound firewall restrictions. Is there a some kind of polling agent for our local Octopus server that can reach out to see if any deployment work is required?

Regards,
Jan

(Paul Calvert) #5

Hi Jan,

Unfortunately the Octopus Server doesn’t perform any active monitoring of external feeds, so the only way for it to know that a new version is available is if an external component tells it by creating a release. This would normally be done using the Azure DevOps plugin, but can also be done using octo.exe or directly with the API.
All of the routes are inbound to the Octopus Server though.

This option has several flaws, and I would avoid it if possible, but you could create a schedule on an internal machine, possible even the Octopus Server itself, to run octo.exe to create a release every evening.

It would get around the firewall problem but would remove the flexibility of having releases created whenever a commit or build is complete. Also, when creating the release it would pick the latest version, this could potentially cause it to pick a version that already exists if there is no new build.

Best regards,
Paul