Channels and tenants are two features that let you create multiple release strategies within your projects. While their main use cases are very different, there is some functionality overlap between the two that might make you ask when you should use channels vs choosing tenants.
You can use channels to deploy your application to a different lifecycle with a modified set of steps and variables. This can cover scenarios like:
- Deploying a different version of your application (V1 vs V2, or Latest vs Stable) with new steps
- Deploying a hotfix release to Test and Production, skipping Development environments
- Deploying a feature branch to Development only and not allowing it to promote to higher environments
You can use tenants to deploy your applications to different customers with customized configuration and process per customer. Tenants are designed to be generic so you can also use them to categories other than ‘customer’ like:
- Datacenters
- Physical Locations like Stores
- Grouped Environments (“Test 1”, “Test 2”, and “Test 3” that all represent isolated infrastructure in one Test environment)
The overlap really shows up when customizing the deployment process and supporting feature branch deployments.
There’s one question that you can ask to determine if incorporating tenants into your process will help.
Do I need to deploy to different targets in the same environment?
In the example case of deploying feature branches with channels, deploying the same website with custom names in IIS on the same target works well. It starts to break down if you need to deploy to different targets in the same environment.
Without tenants, you might be inclined to create multiple environments like “Dev”, “Dev - SSO”, “Dev - Cloud Backup”. This means you’ll also need to create a custom lifecycle per feature branch. This can be a suitable solution for a small number of environments, but after that, it becomes hard to manage and clutters your dashboards with extraneous environments.
With tenants, you can put all of the targets in a single “Dev” environment and associate them to the appropriate tenant that represents either that feature or the team responsible for it. With this approach, you won’t need to create new lifecycles and channels.
One project that I worked on had ten different QA systems for testing changes in development. This was before tenants so we had ten QA environments. If I had the same requirement today, I’d use tenants without a doubt.
Of course, there are some scenarios that can be solved by combining channels and tenants. You can find out more about those in our docs.