We work with Octopus for almost a year and lack of direct support for Environment Types (or Groups or Classes) causes us a lot of grief. We have a ton of Environments, they come and go and it is not feasible to scope variables to Environment name - there are too many. Environments may be easily classified by different parameters, for instance by region, by purpose (Beta vs Prod), by size, etc. It feels so natural to say All Environments in USA should have these variables set to these values, while Environments in Australia should have the same variables set to those values, etc. Scope variables to Environment features or tags or whatever. This feature was proposed three years ago. Octopus roadmap promised all features with more than 200 UserVoices to be implemented in 2017. Is it close? Because if it is not we must do something drastic.
Some time ago Octopus support recommended using Multitenancy as a workaround for the missing Environment Groups. Being desperate I have spent considerable time trying to achieve just that, but so far I don’t understand how to simulate Environment Groups with the Tenants. Any advice?
Thank you!
Konstantin
Hi Konstantin,
Thanks for getting in touch! I’m sorry to hear you’re hitting this grief and issues modelling a multi-tenanted solution.
Firstly, regarding the UserVoice suggestion, this is something that’s still valid and we’re planning on implementing a solution for it. As it stood at the beginning of the year, it wasn’t at 200 votes so it wasn’t listed in our 2017 roadmap blog post, but it’s still very much in our longterm goals for next year. Sorry that’s not the news you were after!
However, this can indeed be achieved with the multi-tenancy feature as you’ve mentioned. For example, using tenant tag sets by region (i.e. a tag set for USA and a tag set for Australia, etc.) will allow you to group these regions within your environments. They can be created in your web portal under Library > Tag Sets, and tenants can be added to them in Tenants > [Tenant Name]. It does take some architectural setup, and we have a lot of detailed documentation surrounding this feature so I’d recommend reading through these resources. Feel free to also followup with any additional specific questions going forward and we’ll be happy to assist.
https://octopus.com/docs/guides/multi-tenant-deployments
Specifically for tenant tags and tenant tag sets, you can refer to this doc page.
https://octopus.com/docs/key-concepts/tenants/tenant-tags
I hope this helps!
Kind regards,
Kenny
The concept of using tenant tags as environment designators for the purpose of variables scoping looks relatively attractive, but unfortunately contains a huge pitfall - it does not work as one would expect it to. Look at the pictures I attached. What my colleagues and myself were expecting is that we can designate tenant tag set for region (for instance), scope region sensitive variables using this tag and then be able to mark environments or targets with those tags to indicate their region and have variables adjusted accordingly to their scope.
In practice Octopus does something completely different! Tags only used to identify matching tenant(s). After that tags don’t affect anything. So really variables happen to be scoped to tenants selected by tags and deployment targets also scoped by tenants, selected by tags, so to have this system work the way we want it to we need to create a tenant for EACH possible combination of tags! Does not look feasible.
