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
Production and we have three different tenants connected to this project for different environments.
Customer-3deploys to just
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-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
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
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-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!
Octopus Deploy is used by thousands of developers across the globe, from small companies to large enterprises. Find out if it meets your deployment automation needs by taking advantage of our free 30-day trial. You can spin up an instance with just a few clicks!