The deployment Lifecycle is one of the key concepts to understand in order fully leverage the benefits of multi-phased deployments. Usually, the current phase of a release can be determined through the straightforward linear progression of deployments through that Lifecycle's environments. As soon as you enable and start using multi-tenancy however, the picture may start to become less clear. Let's take a look at how the inclusion of tenants influences the deployment Lifecycle process.
Tenant Aware Lifecycle
We will start by setting the scene of a typical multi-tenanted configuration. The default Lifecycle for our Synergy project looks like Testing -> Staging -> Production and we have three different tenants connected to this project for different environments.
Customer-1deploys toStagingandProductionCustomer-2deploys toStagingandProductionCustomer-3deploys to justProduction
We have added no tag scoping complexities to machines or steps and will assume that the deployments, once started will complete successfully.
Step 1 - First deployment to Testing
Looking at the new project dashboard that's available from the 3.4.0 build, we get a good overview of all the tenants linked to this project along with a release filter. Only tenants who can deploy to this release's channel (in this case the default channel) will show up in this filtered view.
Creating our release 0.0.1 we find that, as per the standard understanding of Lifecycles, we can initially only deploy to the first environment Testing. Nothing so far has changed. Since none of our tenants are connected to this environment, we can only perform the deployment un-tenanted to the Testing environment. Given there are no tenants involved, this means any references to variable templates will resolve to template defaults or appropriately scoped project variables.
Step 2 - Testing complete, first Tenant deployment
With the success of our testing environment, the current Lifecycle phase has moved to Staging. At this point we now have two customers who can deploy to this environment, Customer-1 and Customer-2. Since Customer-3 is not connected to Staging however, then they still cannot yet deploy this release. Note that the nature of the un-tenanted deployment means that it can still also be performed to Staging despite tenants now being available.
Let's assume we have continued by deploying Customer-1 to Staging.
Step 3 - Staging? Production? Where? Who?
The current phase of the Lifecycle is now a little more complex depending on which tenant we are referring to. Because Customer-1 has gone to Staging it makes sense that we can now promote the release with a deployment to Production for that tenant.
Customer-3, who can only deploy to Production, is now also available to perform their first deployment for this release directly to Production. This is because the deployment of any tenant to an environment constitutes a promotion for the un-tenanted Lifecycle for that release. This explains why a Customer-3 deployment and an un-tenanted deployment can now be performed to Production, despite neither having performed a Staging deployment.
We defined Customer-2 on the other hand as being connected to the Staging environment in addition to Production. What is suggested with this configuration is that we require Customer-2 to first deploy to Staging before promoting to Production. Let's stop and think about what this means for a minute. Although according to Customer-1 and Customer-3 we can now perform Production deployments, any deployment for Customer-2 must still take place to Staging first. As a result, it's almost as if we now have a parallel Lifecycle of this release which is still at the Staging phase specifically for Customer-2, while other tenants can continue through the next phase. Linking tenants to an environment for a project requires their deployment to that environment before phase progression. This feature allows you to prevent your tenant deployments from proceeding to subsequent environments without first having gone through each of the configured stages, all without impacting other tenants from continuing with their deployments.
Tenant Required Projects
One result you may have noticed about this out of the box behaviour of multi-tenancy, is that you are always able to perform an un-tenanted deployment to any environment that any tenant can deploy to. In your particular case however you may find that it doesn't make sense to perform an un-tenanted deployment to Production. Perhaps some of the required variables would otherwise be missing since they can only be defined on the tenant in variable templates. Perhaps you want to prevent un-tenanted deployments from accidentally getting deployed to production infrastructure. To support these scenarios where you want to disallow the un-tenanted deployments, we have included the following option on the project settings page.
By selecting the Require a tenant for all deployments option, un-tenanted deployments will no longer be able to take place for that project. We expect that this will be the advanced configuration that some teams will adopt as they begin to move across to a fully tenanted architecture. In this scenario you might also set up a special internal test tenant, that is linked to the dev or test environments where your customer specific deployments don't make much sense. Perhaps you will also create a test tenant for each of your testers, allowing them to receive individual deployment of your release to different machines for testing side-by-side. (Remember that when disabling un-tenanted deployments you will need to ensure at least one tenant is able to deploy to each of your Lifecycle environments or it wont make much progress!).
We think there are many different ways that your deployments can benefit from the multi-tenancy feature, even if your project doesn't actually have the need to deploy the same release for multiple customers. Let us know how you might make use of tenants that isn't just the obvious tenant=customer design!
