Tenant promotion does not display all tenant environments

Legacy Scale
1

We have a lifecycle for code reviews that is like the following:

Development (at least 1)
- Dev (automatic)
- Sandpit
Test
- Test

We have configured Sandpit and Test to be tenant environments and added all the tenant tags to their target machine.

We have a release that has been automatically deployed to develop (non-tenanted). We then want to promote to test. The environment option displays the available environment options as Dev, Sandpit and Test, however the tenant option only displays sandpit.

For some reason we are not able to promote to the next level of our lifecycle and this is blocking our tester from validating our builds.

Any idea where this is going wrong?

2

To unblock us, I removed the tenant tags from the Sandpit target machine and removed the Sandpit environments from the tenant/project configuration. We were then able to deploy tenants to the test environment again.

3

Hi Rory,

Thanks for getting in touch! How many of your tenants usually require a deployment in Sandpit? Perhaps you should only connect your Tenants to the Test environment, and if you want to temporarily add a deployment to Sandpit, just connect the Tenant at that point in time.

When considering how a lifecycle works for tenants, we look at the lifecycle from the perspective of a tenant. From the lifecycle configuration you showed it’s like saying “Please make sure I’ve deployed to at least Dev or Sandpit for TenantA before allowing me to promote that release to Test for TenantA”.

I hope that makes sense! We’ve written a blog post on the design decisions we made with tenant-aware lifecycles: https://octopus.com/blog/tenant-aware-lifecycle

No doubt about it, lifecycles, and now tenant-aware lifecycles are complicated beasts. To help me understand what’s going on I usually come back to this post from the original RFC: https://octopus.com/blog/rfc-multitenancy#comment-2402888124 The idea is for Octopus to enforce a policy that you deploy to the UAT environment for TenantA, let them test it, then promote the release to Production for TenantA. If you don’t want to enforce that kind of promotion path, you could disconnect the tenant from some environments in the lifecycle, or create “different” tenants like “TenantA-Sandbox” and “TenantA”.

Hope that helps!
Mike

4

Thanks Mike. That makes sense that we would have to promote to Sandpit with a tenant before going to Test. We are happy to leave it as a manual configuration for the time being. It is really only in test where we need to validate the two tenants. We have disconnected production environments where the configuration of tenants don’t apply. We can switch this on for Sandpit as required.

5

Hi Rory,

I just wanted to mention we’ve raised a UserVoice suggestion based on this kind of scenario. https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/17836114-add-lifecycle-option-to-allow-progression-if-other

Do you think this kind thing would help? It would be really nice if you could join the conversation over there and help us understand the specific details of your scenario better

Hope that helps!
Mike

6

Hi Mike,

Thanks for the link. The feature sounds great and I don’t have anything else to add at this point.

Based on your feedback to this discussion and talks with my team, we have made a change to our strategy which puts us in a much better position. Our promotion strategy is now:

Development
- Dev (automatic)
Test (at least 1)
- Sandpit
- Test

Dev was automatic anyway so there was little point having Sandpit off the side of it. We can now promote any release from Dev to Sandpit and/or Dev to Test, one of which must happen before going to UAT (non-tenant environment).

My original configuration was quite simply flawed and this new configuraiton solves our issue with promotions.