Hey, I was glancing through the RFC here https://octofront.com/content/blog/rfc-multitenancy-take-two and was looking for clarification about how environments and tenants will be mapped and associated, and wondering if it will be able to meet our use-case.
We plan to have a significant number of projects for our application, and we plan to deploy to several pools of environments – both internally and for customers who build on our platform – which will not be in sync with each other. Each pool will have a test-stage-prod set of environments which should be released to in that order. We will also have a few internal dev pools, which would follow a different lifecycle than test-stage-prod. As the number of pools of environments grow it quickly becomes difficult to manage a lifecycle per-pool approach, especially when the number of projects grows. Each environment needs its own set of variables, but these are just different values for the same variables. We will be setting the environment variables via scripts, since most will be automatically extracted from the provisioned environment. Ideally we will use either variable set templating and/or tenant variables with three different values per variable, each scoped to the respective environment for that tenant (pool).
Our goal is to be able to add and remove these ‘pools’ of environments with minimal effort. Linking a new lifecycle per-pool to each existing project is not minimal effort. It would be convenient to be able to define environment groups (like dev, test, staging, and prod) and lifecycles that use those, and then link specific environments in those groups to a specific tenant (pool).
If a deployment target could be limited to a specific tenant, then we could simply define 4 environments and a few lifecycles and then when a new tenant (test-stage-prod pool) is added we could just add the new deployment targets for that tenant to the environment, and specify that these targets should only be deployed to when that tenant is deployed to. For our use case, we would want Tenants and Tenant environments not to be project specific, and we when adding a new pool of environments we would like to have to only define a new tenant, a set of variables for each of the tenants environments, and the environments (or just the deployment targets specific to that tenant). We want to avoid scale-ability issues as our number of projects and number of environment pools grow.
I am hoping that the multi-tenancy model will enable this sort of use case, as it stands now there appear only to be completely non-scalable ways to achieve these goals. Cloning projects per tenant/pool/environment is NOT an option, and projects will share the environments variable set, so we shouldn’t need to manually import a set of variables per-project when a new environment or pool of environments is added.
Reading the RFC, I wanted to describe our use case and make sure it will line up with the plan for multitenancy, and also to see if there is something we are missing that could solve this issue without going down the API-automation rabbit hole.
Thanks!