Using output of one deployment to seed a different deployment

I am working on a project for which we are building a version controlled infrastructure pipeline using Azure Resource Manager templates and PowerShell. We have Team City set up to build, version, and nuget pack the templates and scripts before creating a release on our Octopus server which will run them to bring the Azure infrastructure up to date.

The challenge we have is that the outputs from that infrastructure deployment will include values such as URL’s and connection strings which we would then want to seed into our software deployment pipeline for that environment. We have considered the following:

  1. Store the infrastructure deployment outputs in a JSON formatted file on disk and read them back in at the start of the software deployment.

  2. Store the infrastructure deployment outputs in a JSON formatted deployment artifact in Octopus, then use the REST API to discover and read them at the start of the software deployment.

  3. Use the REST API to write directly into the variables for the software deployment at the end of the infrastructure deployment.

It’s looking like option 3 might be the best solution, but I would like to know if there is a recommended approach or if anyone can suggest a better solution I have not considered?

Many thanks.


Hi Adam,

Thanks for reaching out!

Actually the 3 options make sense. I’m a bit more inclined towards 2 for the fact that having an artifact attached to a release make it way easier to track down which variables were generated by which infrastructure deployment (which approach 1-2 don’t quite provide) and you don’t have to worry about the JSON files location on the server (another point against approach 1).

Quick question: At the end of your Infrastructure deployment(ID), do you automatically trigger a Software deployment(SD)? Or do you manually trigger the SD at a later time? Because if you trigger the SD as a final step of ID, you could use the --variable parameter of Octo.exe to pass the needed values as prompt variables.


We have yet to decide on the relationship between deployment life cycles for infrastructure and software, but it is something we are currently working on.

I am certain we would need to do software deployments more frequently than infrastructure and so would not want to lengthen the software deployment time frame by forcing a prerequisite infrastructure deployment in order to obtain the variables every time.

I completely agree with you on the drawback of approach 1, and I really like your suggestion to store the JSON as an artifact for tracability. There were a few reasons I have been leaning towards approach 3…

  1. By setting the project level variables directly from the infrastructure deployment we have an opportunity to review and easily modify them in between the two deployment stages which I could see being useful.

  2. With regards to the REST API setting a variable appears to be a little simpler than obtaining the latest release artifact.

  3. If the latest infrastructure release failed to produce its artifact for some reason, then it may impact the next software release unless our script falls back to a previous infrastructure artifact.

Perhaps a combination of approach 2 and 3 would serve us best. I appreciate your thoughts on the matter!


Hi Adam,

Glad I could help somehow :). I agree with your points and also thing a combination of approaches 2 and 3 would be the best.

Best regards,