I have an IIS website with several bindings in production but fewer in lower environments. I have multiple bindings defined in a “Deploy to IIS” step but need to skip some of them in the lower environments that don’t use them.
Site binding enablement using bound variables may be able to help. Time to bind our bindings!
(This is a more formal write-up of a past related post.)
For related help, please see the relevant documentation on the following concepts we’ll be using:
We’ll use the fictitious OctoFx application for this example. In our test scenario, we want the following URLs for our web site:
- Dev
- Test
- Production
Let’s first look at the initial binding setup. We’ll use a project variable (project.site-binding1.hostname) to define our IIS site hostnames with multiple values, each scoped to the appropriate environment.
Now in the process editor “Deploy to IIS” step binding, we’ll add a binding …
… and set the hostname using that variable.
We’ll create a release and deploy it through all environments.
Now we check IIS and confirm the sites are created/updated with the expected hostnames. (These are all on the same test host for demonstration purposes.)
So far, so good. Now let’s add the additional binding we need for production. We can add another variable with a single value scoped to production.
Back in the “Deploy to IIS” step we’ll add in another binding using the second hostname variable.
Create a new release and deploy!
Let’s take a look at the logs. First, Octopus sees that there’s a difference with the desired state of the bindings, so it happily makes the adjustment.
A look at IIS and we can confirm the configuration was made:
But upon site startup, IIS doesn’t like the configuration it’s been provided.
Looking back at our project.site-binding2.hostname variable, all we have is one value scoped to production. Dev and Test won’t get a replacement, and IIS doesn’t like the variable name as a hostname.
Here’s where we can provide some more context to the binding behavior. Let’s go back to project variables and add in another one. We’ll create a var to flag whether a binding should be applied or not. True for production, otherwise False.
Back in the IIS step, we’ll revisit the second site binding entry, click the “Binding status” variable binding icon:
… and replace “True” (assuming “Enabled” was still checked) with our new variable:
Save everything, create a new release, and deploy!
A look at IIS to confirm the desired outcome:
Success!
Using process step variable binding on the site binding settings with appropriately scoped variables, we’re able to conditionally bind hostnames.