This post is a part of our Octopus 3.4 blog series. Follow it on our blog or our twitter feed.
Enabling multi-tenant deployments in the Octopus 3.4.0, you may have noticed the term "un-tenanted deployment" in a few different places. So whats the deal? I thought I turned on the multi-tenant deployments feature! Rest assured that an un-tenanted deployment is something you have already been doing.
Path of least surprise
Enabling multi-tenant deployments adds another whole dimension to the deployment equation. The same release in an environment can now be deployed for different tenants, bringing along their own whole context of variables, machines and permissions to the process. If you want to individually manage the deployment of your web app to production across 100s of your own customers, this is now easier than ever.
In providing this new feature we have striven to ensure that it is not an all or nothing approach. With 1000s of projects out there in the wild and many more environments to boot, we wanted to make the transition to using tenants as seamless as possible. When you initially toggle on multi-tenant deployments, you can keep deploying your existing projects without any further changes. Until you start adding tenants or tags, you might not even notice that much has changed at all. Don't worry, this is by design!
Artificial additives
Multi-tenant deployments is an additive feature of Octopus Deploy. When you start creating tenant tag sets you will see them start to appear throughout the system on machines, steps, variables and even (eventually) permissions. Your existing projects will work exactly the same as before and you can keep managing, creating and deploying releases without having to learn any new concepts. When you make a deployment without any tenants using the conventional flow, this is considered an un-tenanted release.
You might decide to scope some of your machines to a specific tenant because they are only approved for a particular tenant for security reasons. Perhaps the machines may instead be grouped by different tag sets to partition them for resource management within an environment. Similarly you may start adding email steps to only trigger for VIP tenants or package deployment steps in a project for only those tenants who receive a certain module. It's only once you enable and start using these new features that your project will evolve into something more flexible.
The point to all this is that it's only when you need and start using tenants that we want to expose to you the toggles and dials that allow you to really create an advanced deployment process that fits your requirements. For everyone else who doesn't need to use the added complexity that managing tenants brings, it should be completely hidden away and business as usual.
This should not force you to learn new things to do what you have already been doing.
Ok Ok... But why not just create a default tenant?
During the design phase there were some suggestions to just create a default tenant that could be linked to deployments and used for environments where no explicit tenant is connected. For those of you who have familiarized yourself with the channels feature, you may have noticed that in upgrading from 3.1.x to 3.2.0 we automatically added a default channel to all your projects as a part of introducing the channel concept. Going forward, all new projects also have their own default channel that is initially connected to the default lifecycle. The difference here is channels are owned by and effect only the specific project they are connected to.
Multi-tenant deployments however, add a new layer over the top of the whole Octopus Deploy experience, the results of which can effect various parts of the deployment process, such as which machines or accounts are involved or how global variables get included in deployment across the board.
At what point should a default tenant be created, is it when a project is created or only when another tenant is connected? Automatically creating a default tenant, even if it was abstracted under the hood, could have caused confusion when the behavior couldn't be abstracted away. At worst it could potentially risk blockages of user's existing project releases by weighing them down with new concepts that need to be understood (and even rectified) before continuing. Would the default tenant be created per project or global? We reasoned that a better solution would be to treat deployments that don't include a tenant as an un-tenanted deployment.
In the database we record this against the deployment with a null tenantId.
Octopus Deploy & Cheese
Our mantra in providing any new features is this:
Upgrades should avoid moving your cheese (even if we try to wrap the 'cheese move' with an excuse like we've upgraded your generic brand cheese slices to some fancy European style cheese that you can't pronounce.)
The path of least surprise means that for those who don't immediately need to use multi-tenant deployments features can keep deploying without having to learn anything new. For those for whom multi-tenant deployments solves a deployment architecture problem they have been having, then they can feel free to slowly ramp up to fully tenanted deployments. Eventually we expect that many teams who use multi-tenant deployments may toggle all their projects to require tenanted releases for even finer grained control on the deployment lifecycle.
