Allow deployments to target roles that don't exist (yet)
Presently Octopus assumes the deployment environment must exist before the project is setup - because you can't create a deployment that targets a role that doesn't exist.
This means that you can get into creating your new deployment, then realize you are blocked from saving, then lose your changes as you a) go and create a role or b) go and talk to the admin (the drop-down won't refresh, so creating the role in a different browser tab doesn't work).
I think it'd be better if you were just warned if targeting a role that didn't exist, but allowed to save and create the deployment anyway. The net result would be no different from if the deployment were orphaned due to the tentacle being removed after the deployment is created - ie there is no new edge-case here.
This would make it explicit that you can create the environment and the deployments in any order you like.
Unless I am doing something wrong, this is only partially implemented as "New-OctopusAzureWebAppTarget" is the cmdlet that creates the dynamic target, but it needs a resource group and web app (app service) to pre-exist. I want to use Terraform to create the resource group and web app, but I need to run this first to create the role and target, therefore it would be better to update the cmdlet so it doesn't need a resource group or web app to pre-exist.
Thanks for the suggestion! Octopus 3.8.7 added a feature to allow deployments when no deployment targets exist in the environment.
You can read more about the feature and how to enable it in our blog: https://octopus.com/blog/no-target-deployments
And refer to an example of provisioning infrastructure and deploying your application within the same project in our documentation: https://octopus.com/docs/guides/elastic-and-transient-environments/immutable-infrastructure
Jonathan Mezach commented
I think this will become even more important now that Octopus 3.4 supports elastic and transient environments. I would really like to be able to just setup my deployment processes for my projects and then dynamically create environments to deploy them to.
Perhaps roles shouldn't be defined on machines, but rather flow from the projects you want to deploy.
Michael Noonan commented