Background
We’re using Octopus 3.11.11, but I can also repro this on the latest 3.13.9. We are in the process of setting projects up to do tenanted and untenanted deployments.
To enable this we have installed a second tentacle onto our deployment targets as suggested in GitHub issue #2722.
The issue
We have project variables which are the defaults for untenanted deployments, and project variable templates where the variables are overridden for each tenant.
When the project variable is scoped to a step (we do this for all our variables), the untenanted value is used for tenanted deployments. I have attached some screenshots. I don’t think that scoping a variable in this way should stop it resolving for tenanted deployments.
Hi Kevin,
Thanks for getting in touch! Some good news is that you won’t need that workaround for very long. We’re almost finished unblocking mixed deployments: https://github.com/OctopusDeploy/Issues/issues/2722
I expect this will ship as part of our 3.15 monthly release.
Variable specificity
The reason that variable value is being used, is because it’s more specific. Here’s some writing we’ve done on this topic:
https://octopus.com/docs/deploying-applications/variables/scoping-variables#Scopingvariables-Scopespecificity
Since you’ve scoped that value to a Step, it trumps the value which is scoped to the Tenant.
From my point of view you have a couple of options available:
-
Move away from doing mixed tenanted/un-tenanted deployments in the same project. Un-tenanted deployments are enabled by default for existing projects so you can slowly introduce tenants into them, and eventually switch the project to “Tenanted deployments only”. This ends up simplifying things greatly because every deployment is similar - reliable and repeatable - because every deployment is tenanted. The cost of this approach is to create a tenant for what you might have originally considered as “un-tenanted” environments. I typically create a Test tenant and connect it to all the test environments.
-
Avoid scoping variables to specific steps/roles/machines where there could be confusion over which value will be used. I would typically recommend giving your variables unique names in favour to leveraging the variable specificity rules. It ends up being less confusing.
I would be interested to understand the driver in your scenario for having tenanted/un-tenanted deployments in the same project? I’m trying to improve the UX and our messaging around this area. 
Hope that helps!
Mike
Thanks Mike.
Since you’ve scoped that value to a Step, it trumps the value which is scoped to the Tenant.
I didn’t release the step scope takes the highest precedence. We’ll have a chat internally about moving away from scoping our variables like this.
I would be interested to understand the driver in your scenario for having tenanted/un-tenanted deployments in the same project?
We have an admin back end for our system. We’re standing up separate instances of it for our customers - these will be our tenanted deployments. In addition, we want to keep the existing instance for us to use (it tracks system wide audit events, and allows us to change system wide settings). This is going to be the untenanted deployment.
I see your point about moving to tenanted deployments only, but we don’t consider ourselves to be a tenant. Maybe we should? We’ll give this some thought too.
I typically create a Test tenant and connect it to all the test environments
Yes, we are already applying this pattern. We have a couple of test tenants which we will deploy to our pre-production environments. We’ll then only deploy the real tenants to production environments.
Hi Kevin,
Thanks for keeping in touch! Speaking for myself, I find it much easier to think in terms of “as soon as anyone is a ‘tenant’, everyone is a ‘tenant’, including us”. This means everyone is the same “shape” and gets treated the same way. It helps eliminate surprises and confusion.
Give it some thought and don’t hesitate to reach out if there’s anything else we can do to help!
Happy Deployments!
Mike
