Hi Konstantine,
Thanks for getting in touch.
There are a number of ways to achieve infrastructure + code deployments in Octopus, but in general I’d say it’s best not to leave a Deployment task waiting on infrastructure provisioning. For one thing, the various clouds can fail provisioning for various reasons, with the potential to leave open tasks hanging around in Octopus. For another, with cloud deployments you may be bringing up one or many instances, and a running deployment project has no way to know what those instances are when you hit ‘deploy’.
It is definitely achievable, though.
I’ve achieved this two ways in the past, so I’ll try and break those down here.
1. Completely decoupled Code + Infrastructure
This approach would use two separate Octopus Projects, one for the infrastructure steps, and another for deploying code to your infrastructure.
When you want to deploy new infrastructure, you run the infrastructure project, then when the provisioning completes, an Octopus Trigger, or some custom code on the instance(s) would trigger a deployment of your code to the instance(s)
2. Blended Code & Infrastructure
With this approach you use a single Octopus Project, which targets to multiple roles, for example:
Steps concerned with spinning up the instance(s) run on the Octopus server itself or on a role called, say infrastructure. Only the steps concerned with infrastructure run, because there are no instances present yet, and you get a green tick for a successful deployment. This release then becomes the most recent successful deployment.
When the new instance(s) come online they register with the role mycodeproject, and a trigger (or some custom script) re-runs the same Octopus Project - deploying the last-good release. This is the release you just got a green tick for in the first step. The Project then runs, deploying the code to the newly-provisioned instance(s), and you’re up and running.
Both these approaches need a trigger on the target instances, for which I’d recommend the built-in Deployment Triggers feature available from 3.4, though it can be achieved with custom code using the Octopus API
The second approach assumes your infrastructure provisioning code is idempotent - so can be run multiple times without duplicating its effects. In Azure that would ideally be an ARM template, in AWS you’d use Cloudformation, but there are ways to achieve this with the various APIs. As long as you can prevent infrastructure being accidentally provisioned twice, you’re all set.
Does this help with your enquiry?
Regards,
Jason