We are working with an existing application that is deployed to a matrix of targets and we are not sure how best to model them using environments and roles.
Simple start
In the Dev environment there are three target machines: DEVWS1, DEVWS2 (load-balanced), and DEVSTAFF.
We build a version of the app for public use, deployed to DEVWS1 and DEVWS2.
We build a different version for internal use, deployed to DEVSTAFF.
We have public and internal roles that the deployment targets have assigned.
Each deployment requires some variables, whose values may be different for internal and public, or may be the same.
Odd and even
There is complexity layered on top of this. The same application will be deployed to the same machines a second time, listening at a different address and using a different database. These are known as odd and even, referring to the years for which they will be used.
Some variables are different for odd and even but others are the same. We have (simplified):
Target
Year
Users
Pool Name
RunAs User
DEVWS1
odd
public
dev-odd
DEV_DB-ODD
DEVWS1
even
public
dev-even
DEV_DB-EVEN
DEVWS2
odd
public
dev-odd
DEV_DB-ODD
DEVWS2
even
public
dev-even
DEV_DB-EVEN
DEVSTAFF
odd
internal
dev-staff-odd
DEV_DB-ODD
DEVSTAFF
even
internal
dev-staff-even
DEV_DB-EVEN
So some values are determined by whether the users are internal or public, and some by whether the year is odd or even.
Odd and even environments?
How to we deploy only to odd or even targets? This is the common scenario, where there are potentially different releases of the application between the two.
A simple solution appears to be to create DevOdd and DevEven environments (and similar for Test, Preprod etc.). This way we can define Odd and Even deployment lifecycles.
Has anybody seen this approach, or something similar? Has it worked for you?
Other options
We considered creating odd-public, odd-internal, even-public and even-internal roles and specifying those instead.
Might it be feasible to use tenants (i.e. odd and even) for these deployments?
Thanks for getting in touch! Looking at your scenario here, it appears that your suggestion of using Odd and Even environments would be a good solution.
Your setup sounds similar to a Blue/Green deployment pattern with some differences.
It may be a good idea to integrate Channels into your solution. You could create a Channel for Odd/Even and use this to determine which Lifecycle should be used in the release.
If you were to use Channels, you would probably benefit from enabling Discrete Channel Releases in the applicable projects. This would enable you to manage the Retention Policies individually for each Channel and display them separately on the Dashboard.
Your idea of Tenants could also work here, though I believe integrating Channels into your deployment would serve you better. The Channel option would provide better representation on the dashboard and potentially be easier to manage.
Does this help give you some ideas?
If you have any further questions or thoughts here, please let me know.
But I notice that all packages are unpacked into the same directory before transformation and copying to the installation directory. Is there any change that could cause problems?
I found out the answer for myself. Octopus never overwrites an existing directory; instead it creates a new one. Examples are, for separate Odd and Even deployments:
