How to configure deployment on-demand to multiple servers

We have 2 test web server targets that will both be used for application testing but should only be deployed to when the Test Team want that specific server to be updated (i.e. not both at the same time).

Since they are both in the Test environment, however I configure the lifecycle, both targets will be deployed to at the same time, either manually or automatically. It doesn’t seem correct to add more environments to work around this (although we could theoretically call one e.g. PenTest and the other WebTest) but otherwise I can’t see how to split out the two targets so they can be deployed to independently.

Please can someone point me in the right direction?

Hi @luke1,
Thanks for reaching out and asking this question! It is a bit of a tricky question, even if it doesn’t seem so. This kind of question is an important one to ask as it can determine how releases flow and sets you up for the future. Neglecting to ask this question can end up with 100’s of environments and then have to deal with environment sprawl. However, it is a bit of a balancing act, and there are trade-offs. We have some recommendations in our documentation.

First off, are you aware that you can select individual targets when you are deploying?

This may be as much control as you are looking for, but it does have trade-offs in the fact that it’s not as easily noticeable from a dashboard perspective what machines were deployed to.

Deploying to one machine in the environment would also satisfy the lifecycle so a machine could be missed. For these reasons, it might make perfect sense to set these up as separate environments.

By treating them as separate environments, you will gain some more control and visibility over the flow of your application through the pipeline. Plus, often a pen-testing environment may have additional requirements that a normal web infrastructure won’t. You can set up your lifecycle like so:
where either the PenTest environment or WebTest environment need to have a successful deployment in order to proceed or require both if that is your business use-case.

Your dashboard will be more obvious as to when the application is where.

You also gain a bit more control deploying to the appropriate environments and can lock this down by team if needed.

You do want to keep your environment count low, or else it can become unwieldy. A general guideline from our documentation,

In general, keep the number of environments under ten. Having fewer environments makes configuring and maintaining your Octopus Server easier.

Tenants would be the next option, but it doesn’t sound like you are there yet. They would also add more complexity which I don’t think you need at this point.

I hope this helps! Please let me know if you have any further questions.

Happy Deployments!

Thanks @mark.reeder

Yes, this answers the question. I was aware of selecting the deployment target but its good to know that there aren’t any other magic ways of doing this. I didn’t particularly want to use another environment since we already have a sprinttest environment, external pentest, dev, staging, DR and production but that might be the most obvious way to do things for now.

I will have a ponder.