Deploying two apps to odd and even targets selectively

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?

Hi Michael,

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. :slight_smile:

Best regards,

Hi Daniel

Thanks for your reply. We are creating Odd and Even channels and I think this will work well for us.


1 Like

Hi Daniel

We have been deploying the Odd channel so far, but will soon deploy the Even channel. Same code but with different configuration.

The deployment process includes a custom installation directory, set to:


Odd and even examples are:


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:

1 Like

Hi Michael,

Thanks for the update! I’m glad to hear that you figured this out.

Please don’t hesitate to get in touch at any time. :slight_smile:

Best regards,

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.