As part of Octopus Deploy 3.8.7 we released a new feature related to Elastic and Transient Environments that we thought warranted a call out.
Allow deployments to No Targets
The core of the feature is a project level setting to opt into being able to perform deployments into environments where there are no targets.
Why is this useful?
The underlying premise of Elastic and Transient Environments is to ensure the release deployed to all targets in an environment is the same, including new targets that come online. The mechanics of this hinge around a successful deployment to the environment, in order to know which release to deploy to the other targets. In order to do a deployment to the environment though, you had to have at least 1 healthy target, which had its limitations.
What if you were spinning up a new environment? (e.g. for infrastructure/testing automation) You couldn't start the deployment until the infrastructure deployment had fully completed. What if your deployment process included steps to provision the infrastructure that would be used by later steps? By definition the targets can't exist before the deployment commences.
What if the transient machines happened to all be offline at the time you wanted to deploy an upgrade to an environment? Yes, there are scenarios where that is valid, e.g. you're deploying to a fleet of mobile devices and none of them happen to be docked/online at the time you want to deploy a new release.
How do I use this new feature?
The setting shown in the screenshot above will allow you to create a deployment when there are no targets in an environment. That's essentially all you need, but you will likely want to couple this with the use of triggers for most scenarios.
If you are using Immutable Infrastructure then this feature will be useful if you want to combine the infrastructure provision steps and application deployment steps into a single project.
You have to opt in!
Octopus' desire to not let you deploy into an environment with no targets still holds. For the vast majority of our customers we'd still expect that deploying to an environment with no targets indicates an error and we'll continue to treat it as such until such time as the user consciously indicates it's ok to do otherwise.
Auto deploy overrides
For those who haven't seen or used the auto deploy overrides functionality, it is a command line option to manually override which release will be deployed to a given environment/tenant. This is useful when you want to lock an environment/tenant to a specific version, rather than have them always receive the latest successful release.
Release overrides have previously been a recommended option for handling deployments into environments with no targets, as it can be defined without an existing deployment. When a new target appears in the environment the auto deploy trigger will fire and a task to deploy the specified release will be queued. Now that the releases can be deployed to environments with no targets, this usage scenario for auto deploy overrides is no longer necessary.
