Creating a release with multiple channels

Here’s my scenario. We have two sites (London and Chicago) which each have a set of Test, Staging and Production tentacles. We have two lifecycles, one for each site, which only allow the deployment to Production machines when the release has been deployed to one Test and one Staging machine in the same site. We used to have one lifecycle which merged the two sites but that meant we could deploy to Production Chicago when we had deployed to Staging London, which wasn’t correct so we split the lifecycles apart.

Some of our software will be deployed to one site or the other, but some will be deployed to both, and we don’t know this in advance. When I create a release for the current version of the software, I would like to assign both lifecycles (or channels) but I can only choose one. If I create another release with the other channel, I get an error saying ‘Release already exists for this project’. We could create a release with a different name but we automate a lot of our process so the name of the release in Octopus has to match the version of the software being deployed or our scripts will fail.

How can I create a release so that it can follow two lifecycles? Is this possible? Is there any other way I can do this?


Thanks for getting in touch. You’re correct, you can’t connect a release to two lifecycles, and in your situation I can see how this would be a sensible move.

We are planning a feature for Octopus 3.4 as part of multi-tenant deployments which will enable tenant-aware lifecycles. This would require you to deploy a release to Customer A: Staging before you can deploy the same release to Customer A: Production. With this feature in place, you could model London and Chicago as tenants, and the tenant-aware lifecycle would provide the safety you desire.

This feature is still a ways off, but multi-tenant deployments are our next priority.

In the meantime, one approach you could take would be to make a more linear Lifecycle like this:

  • Dev
  • Test
  • Chicago - Staging
  • Chicago - Production
  • London - Staging
  • London - Production

This would ensure you went to the staging environments before production, but it would require you to deploy to Chigago’s Staging and Production before moving on to London’s Staging and Production.

Personally I would lean towards the multi-tenant solution since it seems like a really natural fit - it’s just not available yet!

Hope that helps!


Sorry, I forgot to attach the link to the Multi-tenant deployments RFC which describes the tenant-aware lifecycle. Unfortunately our site is experiencing problems and I can’t provide a deeper link tonight:

Hope that helps!

Thanks for the reply, is there any timescale for when 3.4 will be ready? The multi-tenancy feature does sound very useful for us.



Hi Chris,

Thanks for getting back to me. If everything runs as planned you could expect us to ship a pre-release in about two months from now.

Hope that helps!