Hi,
My scenario:
1.- 200 Octopus projects (all clones): P001, P002, P003…
2.- Each of those projects has multiple steps that need to run against web servers.
3.- Staging environment has 20 web server targets: S01, S02, S03…
4.- Live environment has 20 web server targets: L01,L02, L03…
My requirements:
For each project, the steps need to run on only a subset (pair) of the web servers; e.g:
a.- Project P001 needs to run the steps on S03 and S04 in Staging, and on L17 and L18 on Live.
b.- Project P117 needs to run the steps on S03 and S04 in Staging, and on L05 and L06 on Live.
The naive way I was thinking of doing it was to give each pair of targets a role, and then modify each project’s steps, i.e:
a.- S03 and S04 have roles staging-webserver-pair-B.
b.- L05 and L06 have roles live-webserver-pair-C.
c.- L17 and L18 have roles live-webserver-pair-I.
d.- All of P001's steps are individually configured to target staging-webserver-pair-B and live-webserver-pair-I.
e.- All of P117's steps are individually configured to target staging-webserver-pair-B and live-webserver-pair-C.
This would involve quite a bit of work to set up and manage, even using the Octopus API.
Is there a tidier way of doing this (e.g. configure the target machines of every step in each project as a single project variable)?
Thanks for your help!
Hi Martin,
I’ve taken this ticket. I want to really give you a good response so I apologize for the delay in getting back to you.
i’m sure we can come up with a good idea on how to get this working for you. I will get back to you hopefully in the next day or so when I’ve taken it in and had a good think about the best way to manage this.
Vanessa
Hi,
Could you give me an update on this question? In a week’s time I’ll be configuring 100+ sites and I want to do it right! 
Cheers,
Martin.
Hi Martin,
I am so sorry! I responded to you, and thought I moved this back into my Q but I must have mis-clicked or it might have timed out. Otherwise I would have responded much sooner!
I’ve spent the last hour going over your situation and looking at it from all the places you could configure this. Environments, Lifecycles, roles, steps.
I even drew bad diagrams - many boxes.
I think roles are the best way to go. The way you have described below. Mostly because two areas you cannot use variables in are roles for a step, and specific machines to deploy to. Neither can be variables. (For very long important wordy reasons that won’t and can’t change soon or easily.) It would be the least management, and the easiest to make changes to and to identify what projects deploy to what machines. It is also the least hacky and error prone.
Note: I considered 20 environments, 1 Lifecycle and scoping steps to environments, but you make a mistake and could deploy to many more than intended as the Lifecycle would allow it. Roles make this very clear and would not venture outside if left out (ie. roles are inclusive and specific, environments default to all).
The only way you could change the complexity even a little is if you always deployed to the same pairs on each environment for each project. Then you wouldn’t have to have a set of 10 stage roles, and 10 live roles, just 10 roles in total for pair names.
Doing it this way would mean that when multi-tenancy comes in you wouldn’t have to do a lot of migration, and you could make use of the tags we are introducing.
So I do think this is the least effort now, and less effort to convert this data over to our multi-tenancy solution which would help here.
So in conclusion (tl;dr;):
- 2 environments stage and live
- each environment has 10 roles, where each role is assigned to 2 machines
- a single lifecycle with stage phase and live phase
- each step of your project/s has one stage role and one live role
Again sorry for the delay, I even had a day where I just answered existing tickets and didn’t take on any new, but yours wasn’t in my queue due to my mistake.
Vanessa