As a feature request, I would like to see if we could get the ability to attach a given project to a tenant multiple times, instead of just once.
We have a web project which is scaled in a way that a given tenant could have multiple deployments of the same project at the same time - ie, a given tenant could have anywhere from 1 to 5 deployments, each with slightly different configurations. The machine it is being deployed to is the same, and each deployment should occur simultaneously with the others.
I think it would be beneficial to be able to attach the project (with the same environments) to the tenant multiple times, and then we can fill out each variable set individually from there as if they were different projects.
For the time being we can get around this by creating multiple tenants (one for each project deployment), but then we lose the ease of being able to configure the tenant in a single place, which is a huge benefit, especially since they have several projects attached to them in addition to the web project I described above.
Thanks for getting in touch! Would you be able to send through some screenshots to help us understand your situation better?
When it comes to variables, Tenants, Environments, Roles, Steps and Deployment Targets all provide ways to vary those variable values based on context. (Vary variable values!?! That’s a mind bender) From what you’re describing it sounds like you would like another way to vary your variable values… but none of the existing dimensions are suitable.
Like you said, you could consider this to be a different Tenant, or you could consider adding multiple environments, but both of those have down-sides. When designing scale-out software systems, I’ll usually try to keep variability to a minimum across the nodes in the scale-set, and I can usually scope variables that change per node to the Deployment Target.
If I could understand which variables actually need to change between each deployment in your scale-set perhaps I can help find another way around this problem?
Thanks for jumping in and trying out 3.4 beta and I’m really glad you got in touch.
Hope that helps!
TenantID and DeploymentNumber are both defined as a Common Variable: TenantID is the same for
Tenant A and
Tenant B (which are two deployments for the same customer,
Tenant), while DeploymentNumber is different.
As you can see, the Database Name, address, and other values (including the API Key/Secret) are the same. However, the IIS details (the domain binding, installation directory and website name) are all different. Both of these tenants are attached to the same deployment target and environment.
Personally, I don’t mind having to enter the same details multiple times like this; the bigger concern, is that it is difficult to know what projects are attached to which tenant with this setup.
You can see that
Website API and
Website Client is attached (with the same environment) multiple times. This allows for all deployments for the tenant to be defined in one place. If Tenant needs a third deployment of the API/Client, we can add them there as well. This also reduces confusion of which tenant has the
Product B deployment. With our current solution of having multiple tenants, it would be difficult to know if
Product B is attached to
Tenant A or
We are looking at it from a Customer basis instead of a pure Tenant basis, but that seems to be the most natural way of looking at it considering we have multiple products that scale differently - As in the proposal screenshot, we have products that we only have 1 deployment per customer, and others that could have between 0 and 5 deployments per customer. The only other option would be to create a tenant per product/deployment combination (so the
Tenant customer would actually have 5 tenants, instead of 1 or 2), grouped by a Customer-type Tenant Tag, but that seems like it would be unnecessary clutter when scaling out or adding new customer tenants.
Thanks for sending through that extra information. I’ve been taking some time to talk with other team members, and to sleep on your suggestion. I really can see the potential convenience of your suggestion, but I also see the potential complexity it will add to an already complex system. I’m sorry, this is sounding like it’s only bad news.
So far with people using the multi-tenant deployment features in Octopus, the existing model of one-connection-per-tenant is matching their process. And in their situations, tenant maps directly to a customer - which suits well.
In your situation, it sounds like each customer could be modelled by one-or-more tenants. In Octopus terms, tenants allow you to deploy to multiple instances of your projects in the same environment. So where you say each of your customers can have multiple deployments, I think this suits really well to each customer can have multiple tenants in Octopus parlance. _And you said this is what you’re currently doing with 3.4, but I can see the friction you’re experiencing not having built-in support for managing a customer having multiple tenants.
This is where I would suggest building a lightweight, custom portal over the top of the Octopus API for managing your customers. We’ve built Octopus API-first, and we’ve paid a lot of attention to the tenant-related APIs to make it as easy as possible to build your own sign-up forms, provisioning apps, tenant orchestrations etc.
I wonder if something like that would suit your situation best, where the modelling of a tenant in Octopus maps to your “customer deployment”, and you introduce an aggregate model over the top of the Octopus API for your “customers”.
I really think this would be the best overall solution given my shallow understanding of your circumstances, and I’d be happy to work through some design ideas with you if that would be useful.
Hope that helps!
I completely understand. I gathered this could be a not insignificant change to (as you say) an already complex system. In essence, we have a multi-tenant environment, but some (not all) of our customers are also multi-tenanted for their customers. And since we ultimately provide the software, we have to support that type of relationship.
When I was thinking over the original suggestion, I hadn’t thought of building a custom portal on top of Octopus, but now that you describe it, it seems like it would be a reasonable option. Given that the system is manageable the way it is (and with the right Tenant tags can even eliminate some of the issues I’ve described), I can certainly accept this as an answer.
Thanks for everything done so far - tenants are huge for us, and we love everything you’ve done, and look forward to seeing what’s next.
Thanks for getting back to me. If you decide to start a customer portal, don’t hesitate to reach out for help if you need it. We’ve got some samples of using the C# SDK we’re hoping to share, and your browser developer tools are a really good way to understand how Octopus uses its own API.
Hope that helps!