Filter out packages based on tenant tags

Legacy Scale
1

Hi,

Consider the following. We have a multi-tenant project (5 tenants up to now), each tenant have multiple dedicated environments (from 4 to 10 per tenant). Because of different client needs, this is impossible to have a standard lifecycle for that project, so we had to define 3 lifecycles per tenant (Release, FixPack, HotFix) so a total of 15. Our project is an integrated solution that uses up to 18 different applications (so up to 18 nuget packages to deploy to different server roles). Not all of our clients uses all the components, so we have some that uses only 10, but some others use 18. Also, each of the components could have different deployment procedure based on the version that needs to be deployed and our clients do not run the same versions. I know, this is a big puzzle.

I want to remove some steps from the process for some tenants, so I’ve used the “Channel” filter on the step level to enable the step only for the given channels. This works, but it’s hight maintenance since as soon as I will add a new tenant, I’ll have to go to each steps of the process and add the 3 channels to the list (I have 55 process steps). I’ve then decided to use the tenant tags. I’ve created a “Component used” tag and then selected each used components for each tenant (sounds like a good idea)… When I go to my process steps, I see I can “filter” on tenant tags. So I’ve selected one of the steps and assigned it to tenant tag “Component 1” only. When I try to create a release for a tenant that does not have the “Component 1” selected, I’m still prompted to select a package number for “Component 1”

I expected to see all the packages except the one associated to “Component 1”. Am I missing a step?

Thanks (and sorry for the long post)

2

Hi Frédéric,

Thanks for getting in touch! It sounds like you are exploring some interesting concepts and approaches to your deployments in Octopus. :slight_smile:

Octopus Releases

I think there’s one misunderstanding here: releases are not tenant-specific. You create a release for a project, which gives you the potential to deploy that release to your Tenants and Environments. This is a really good page to help understand how releases are modelled: https://octopus.com/docs/key-concepts/projects/releases

When you create a release, you get the opportunity to define the version of packages which will be used for each of the Package Steps in your Deployment Process. If you decide to skip a Package Step for some reason, that package won’t be deployed, even though it was defined in the release.

In other words you can happily create a release of your project which covers the full gamut of packages, but have each deployment of that release opt-in and opt-out of certain steps.

Tenant-aware lifecycles

One interesting point I noticed is that you’re creating environments for your tenants, and then specific lifecycles for each tenant, which requires a channel for each tenant. Personally this is an approach I would avoid, since it negates a lot of the benefits of using Tenants in Octopus.

The general idea when using tenants is to create common environments and a common lifecycle. You then connect your tenants to the appropriate projects and environments where you want deployments. Octopus will interpret your lifecycle according to which environments each tenant is connected to, and calculate the most appropriate promotion pathway for your releases.

Is there a reason that would prevent you from creating a more generalised set of environments and lifecycle?

Consider multiple projects

Depending on your scenario, you may want to consider splitting your big project with 18 packages into smaller, more manageable projects which iterate on their own cadence. Each tenant could be connected to a different set of projects depending on their requirements.

Guidance

If you haven’t already, I would recommend reading through our guide on multi-tenant deployments which illustrate a simple, but canonical example. Granted, Octopus has some very advanced features now, and it can be difficult to know exactly how to model your deployments. Each modelling decision will come with a series of tradeoffs and you will need to decide which pattern suits you most.

If you feel like I’m missing some important context, or have further questions, please don’t hesitate to reach out!

Hope that helps!
Mike