I have defined a few variable templates under Library > Variable Sets > [Authentication Api]… that I wnat to be used across multiple projects & tenants. I was hoping once this variable set was included in a MultiTenant project, that I could define custom values for each environment, similar to how you can do currently for project level variables. I don’t want to define these variables at the project level because X number of projects reference them… for example, I have 5 APIs that will all reference this Authentication Api and need to A. have environment specific details and B. Tenant Specific details. Make sense?
Am I missing something here? I have attached a few images which show this example.
These variables are not simple, so I can’t use the example provided in documentation where you have EnvironmentAlias… In fact, even in your documentation for this particular step, the password part you would have issues deploying and authenticating to sql server if the password was different across environments.
Thanks for getting in touch. I’m glad to see you are getting up and going with the multi-tenant features!
We did talk about “variable variability” quite a lot when working on 3.4, and we opted to start with what we have today - either “common” variables (constant wherever the tenant is used) or “project” variables (potentially different value for each project/environment combination). We didn’t want to build additional complexity in to multi-tenant deployments unless we really needed to.
The idea of “shared environment variables” or “environment-specific tenant variables that are shared amongst projects” feels like it would eliminate the need to copy-paste without adding too much complexity/confusion to the variable system.
One idea is to allow Variable Templates from Library Variable Sets be either Constant (like they are today) or VaryByEnvironment. We could add a new tab to the Tenant Variables screen so it would become something like: Common Variables | Environment Variables | Project Variables.
I feel like this would be a really useful mix of capabilities and match many situations.
The reason we are shying away from allowing “anything goes” scoping to variables is due to complexity - we’d rather take an opinion and make it as easy as possible to get up and going for the 99% cases. We’ve also been loosely talking about extending the idea of Variable Templates beyond Tenants into Environments, Deployment Targets and Roles - this way you can define the variables in the place where they vary.
Thanks for the reply Mike… For now I’ll just create these variables in every project and duplicate them… I totally understand coding it for 80/20 rule here, or as you say, 99% … all good. I will keep my eyes peeled for when you introduce the VaryByEnvironment.
Thanks for getting back to me. Hehe, 99% might have been an exaggeration… After spending some time sleeping on the idea, I remembered quite a few situations where I wanted a common environment-scoped variable for my projects - and I can easily see circumstances where you’d want a shared tenant-environment scoped variable - think shared Azure Storage Accounts, Amazon S3 buckets, a common database etc. 80/20 is probably a much better estimate!
A few of us are convinced it’s a good balancing point, to add the concept we’ve described. We’ve got a few variable-related changes to make, including ordering and grouping of Variable Templates, so we’ll probably gather these changes up into a bucket of work.
Fantastic! A common database and an Azure accounts were the exact two use cases I ran into a wall on which made me create this thread. I love the Octopus team, you guys are awesome - thanks for taking the time to reply, think about the challenge and work it into your backlog!
Thanks for creating this github issue… I acn’t close this thread because I created my account after posting without an account… so I don’t have the option. You can close for me, thanks!
