Prevent releases from Tenant Restricted Channel being released to un-tenanted environment

Legacy Scale
1

I have a project with two channels - one is un-tenanted and the other has a tenant tag restriction. I would like any releases belonging to the tenant restricted channel to never be able to be deployed to an un-tenanted environment, however I can’t figure out if this is possible.

Related to this I push packages from TeamCity and have set the tenant flag to wildcard expecting at least that this would only deploy to the Tenants linked to the project - however it’s also pushing to the un-tenanted environment. I assume I can use flags here to restrict it - but it seems counter intuitive that an explicit tenant flag (even if it is a wildcard) would release to non-tenants.

2

Hi Rich,

Thanks for getting in touch! I’ve been talking with my teammates about this one a bit. We are hesitant to add another option/switch to channels if we can avoid it at this point. We don’t want things to get more complicated without a really compelling reason, and then UX, behind it.

Reproduction

I’ve been trying to reproduce what you’ve described, but I can’t seem to make it happen.

For example, when I use the latest version of octo.exe, when I use this command line with --tenant=* it does what I expect, and finds all the tenants who are ready for the release, then queues deployments of that release only for those tenants.

Octo.exe deploy-release --project=Alternize --deployTo="MT Test" --version=1.0.0 --server=http://localhost:8065 --user=admin --pass=password --tenant=*
Octopus Deploy Command Line Tool, version 1.0.0

Handshaking with Octopus server: http://localhost:8065
Handshake successful. Octopus version: 0.0.0-local; API version: 3.0.0
Authenticated as: admin <null>
Finding project: Alternize
Finding release 1.0.0
Found 10 Tenants who can deploy Alternize 1.0.0 to MT Test
Deploying Alternize "1.0.0" to: MT Test for Pedro Webb (Guided Failure: Not Enabled)
Deploying Alternize "1.0.0" to: MT Test for Hunter Banks (Guided Failure: Not Enabled)
Deploying Alternize "1.0.0" to: MT Test for Clifton Ramirez (Guided Failure: Not Enabled)
Deploying Alternize "1.0.0" to: MT Test for Edward Marshall (Guided Failure: Not Enabled)
Deploying Alternize "1.0.0" to: MT Test for Ray Harrison (Guided Failure: Not Enabled)
Deploying Alternize "1.0.0" to: MT Test for Sylvia Porter (Guided Failure: Not Enabled)
Deploying Alternize "1.0.0" to: MT Test for Lester Henderson (Guided Failure: Not Enabled)
Deploying Alternize "1.0.0" to: MT Test for Edith Montgomery (Guided Failure: Not Enabled)
Deploying Alternize "1.0.0" to: MT Test for Brandon Bradley (Guided Failure: Not Enabled)
Deploying Alternize "1.0.0" to: MT Test for Claudia Craig (Guided Failure: Not Enabled)

To perform an un-tenanted deployment I need to omit the --tenant= option altogether. I believe octo.exe is already working the way you expected?

Could you send me through some logs which show how TeamCity is calling octo.exe and the resulting deployments that are queued?

Consider moving your project to Tenanted Only

To remove a lot of this kind of complexity and confusion I commonly recommend moving away from having “hybrid” projects, where Multi-tenant deployments: Allow deployments with or without a tenant, instead moving towards Multi-tenant deployments: Require a tenant for all deployments.

The upside is all of your deployments are consistent: variables come from the same place, your deployments will all run the same, and you don’t have confusion about why un-tenanted deployments are allowed in certain scenarios.

All you have to do is create a single tenant to replace your current un-tenanted deployments, then connect that tenant to all the environments where you would previously perform un-tenanted deployments.

Is there a reason why you decided to use un-tenanted deployments? Or is there a reason why creating a single tenant to replace the un-tenanted deployments is not practical for your scenario?

Un-tenanted deployments were designed to provide an upgrade path, and at some point you’d disable un-tenanted deployments. We are finding quite a few customers are persisting with un-tenanted deployments and are trying to understand why. :slight_smile:

Hope that helps!
Mike

3

Hi Mike,

Thanks for reaching out. I think I’ve resolved the most pressing issues - but thought I’d add my input as to why I’m doing things the way I’m doing them :slight_smile:

Firstly to the reproduction issue - this was totally a PEBCAK issue - I’ve had my lifecycles setup with an auto deploy to the first environment, so that was deploying to the untenanted build as soon as the release was created by TeamCity. Removed that - and at least it’s not deploying to the untenanted environment (although it’s still available to deploy within the OD UI but we can keep that locked down)

Regarding the ux issue - my channel is setup to restrict to tenants and it feels like the way it’s worded implies already that a channel setup like that is already restricted to tenants only and a release in that channel being able to be deployed to a non-tenanted environment was a surprise (at least to me - others opinions may vary :slight_smile: )

I actually moved away from having exclusively tenanted environments for a couple of our projects. I found it a bit easier to manage - yes there was the odd variable that was being modified, but the environment was only ever being deployed to once, regardless of project - so it meant I could create consistent variable sets for all projects whether their other channels within a particular project required tenants or not. I then had the tenants override those variables with tenant specific information to ensure consistency regardless of type of deployment.

The biggest thing for me was not having to specifically add the project into the tenant, an annoying extra step, particularly for a one => one environment/tenant setup that I keep forgetting to do even with projects that are completely tenanted.
To be fair I’m yet to understand this step - you don’t have to explicitly add a project to an environment instead using process setup to determine which environments a project is deployed to - so considering you have the (amazing) tenant tagging system that can get far more granular than adding a project to a tenant it feels like repeating yourself.

One further question
Is there any way to have a step only run after all tenants have run? I have added a step in one of my projects to trigger the release of another project within Octopus but would only like it to run once (not for every tenant) but don’t think there’s an option to do this? I can manage work arounds so not the end of the world - but while I had your ear thought I would ask :slight_smile:

one little feature request if I may :smiley:
I would love to have a tenant exclusion option for a step like you have for environments - I have a couple of steps which can’t run on exactly one tenant - but my only option is to add all the tenants that it can run on (I’m using tags to do this). Would be great to say exclude this step from tenant/tenant tag so in the event I add a new tenant / tenant tag I don’t have to remember to add it in to the white list.

Thanks :slight_smile:
Rich.

4

Hi Rich,

Thanks for keeping in touch! Some good feedback here and I’ve been talking with my teammates about it a bit.

The friction of having a “test tenant” where you’d need to connect them to all the appropriate projects/environments is true - I hadn’t personally realised that friction point. It’s good food for thought, but it sounds like you’ve got a nice solution in place right now where you override the project variables once you do tenanted deployments.

Running a single step after

No, each tenanted deployment is an independent deployment. What is the actual event you want to trigger from, and what is the task you want to happen?

  • All of “these” tenanted deployments are completed? (Say you queue a deployment for 15 of your tenants)
  • Release 1.2.3 of Project XYZ has been successfully deployed to all tenants for Production?

At this point, your options are a bit limited. You could choose a “special” tenant and scope a step to that tenant, and always run that tenant’s deployments last - yuck. Otherwise you could build a fairly simple app which polls the Octopus Dashboard API, looking for certain situations. My favourite way is to subscribe to the Octopus event stream using a WebHook and aggregate those events to trigger higher-order orchestrations.

Tenant exclusion

Yep, that’s on our list :slight_smile: https://github.com/OctopusDeploy/Issues/issues/3337

This is a good place to look for what we’re planning to do as we get capacity: https://github.com/OctopusDeploy/Issues/issues?q=is%3Aopen+is%3Aissue+label%3Afeature%2Ftenants

Hope that helps!
Mike