In my scenario, I have an application which needs to be deployed in multiple locations(Targets). Now each location has a TEST and a LIVE environment. So I simply created a lifecycle consisting of 2 phases TEST Phase and LIVE Phase and added all TEST environments for different locations to TEST Phase and all LIVE environments to the LIVE Phase of the lifecycle.
Now my problem is, when I deploy my project on TEST environment of say location A but did not deploy it on TEST environment of other locations say B and C as they do not want the new deployment and are happy with the old deployment. But due to this situation even when the TEST deployment for location A is tested successfully and can be deployed to LIVE environment of location A, I cannot do so as the deployment has not happened for TEST environment of location B and C which is desired. The promote to LIVE will be disabled till I deploy the a release to all environments in the TEST phase.
The only solution I see here is having different octopus project for each location which doesn’t seem to be a good idea as deployment process will be repeated for all of them and the variables will be useless. Moreover I will have to sync all future changes across all projects and many more octopus features will be waste. I will end up having 20+ octopus projects for a single build/service and I have more 50 such applications!
Quick question before I give you a full answer: Lets say you deployed to A to LIVE successfully. Should you be able to deploy to B or C straight to LIVE, without passing through TEST first? or before you deploy to B LIVE you need to go through B TEST (same logic for C)?
You got it right! Once A is deployed to LIVE and if B needs to be deployed to LIVE then it should first be deployed to B TEST and then only to B LIVE. Same for C…
We are currently working on a feature called Multi-Tenancy which will be released at the end of August in v3.4, which will basically solve this situation.
A,B and C will be tenants and you will be able to deploy to all of them at once, or separately, but they will always have to follow their full lifecycle pipeline (e.g. you won’t be able to deploy to B-LIVE until you passed through B-TEST). You can read more about this in the blog post below, and in the doc links mentioned in there.
Now, if you don’t want to wait until 3.4(*), you could achieve something very similar using Channels. You would need 1 Lifecycle per target (A,B,C) and each will have its own TEST and LIVE. Then under a single Octopus project, you’ll have 1 channel per target, and each channel will be scoped to one of these Lifecycles.
(*) Should you wait until 3.4? To be honest, both approaches are good. The only advantage I can see from Tenants over the Channel-Oriented approach, is that once 3.4 is out It’ll be easier to add new targets as tenants (D,C,E,Etc) , and It’ll be easier to quickly figure out on which version is each tenant. This last one is not particularly easy with Channels, but definitely not impossible.
