Multiple Deployments

Legacy Uncategorised
1

Hi,

We have a number of client-specific set-ups, so we have created a number of environments: one per customer per stage. So for customer A, we have:

  • A Dev-QA
  • A UAT
  • A Live

We have these for B thru N as well. This is a lot of environments, but is needed because we need to separate the config for each customer, which we do by installing to folders that depend on the client code (which is different per customer).

The problem is that for a new release to (say) UAT, we need to configure 14 separate deployments. This is error-prone and fails to scale. Is there a way we can configure one release of one product to go to all 14 environments in one hit? Given that all 14 deployments are going to two machines, it is acceptable for the release steps to queue and process as and when.

Thanks.

We are on 2.5.4.280.

2

Hi Rhys,

Thanks for getting in touch! Just to help you here can you clarify something for me.
It sounds like you have the 3 environments per customer but also a project per customer? Is this correct?
Are the actual machines you install to for each customer different or just tentacle installs on the same machine with different directory paths?
Could you also explain a little about your variable use, and is it mostly just for directory pathing and config items?
Understanding a bit more about the software you are deploying here will help give the best advice.
Vanessa

3

Hi Vanessa,

We have one project in total. This is our core product. There are other projects on our Octopus system, but they don’t concern the team I’m in.

Within this project we have a couple of builds, which are slightly different product options. Each one has a latest release. We only ever deploy the latest releases.

We have three delivery stages, Dev/QA, UAT, and Production. Each stage has a different set of servers in it, and we use variables to point to these. We have a web server, service server, and database instance serving all customers in each delivery stage. We have a tentacle on each web server and service server, and we run scripts on the service server to do the database work (as we’re not allowed to put a tentacle on the database servers).

As our application doesn’t support multi-tenancy, and may not be able to due to clients requiring separate data stores, we have one install per client, installed into separate folders. We have parameterised this (so the install folder is something like “D:\App#{clientshortcode}”, for example, and other client-specific settings are similar).

For a given customer instance in a given stage, we need some variables that are scoped across Dev, UAT and Prod for a given customer, and we need some variables scoped across all clients for a given stage. However, the only way we’ve found to separate out the settings is to create an environment per client per stage. This means we have over 50 environments, all called something like “Product-Stage-Customer”. We’ve found this is very error-prone, as we have a massive list of variables per customer, and we’ve made a fair few mistakes with the deployments. We also can’t multi-deploy like this, so when we put a new build into UAT, we have to do something like 20 separate deployments, one at a time, to the correct environment. This also is painful and error-prone.

What I’d like to know is if there’s a better way to manage all of this?

Please let me know.

Rhys

4

Hi Rhys,

Thanks for the reply. I’ve been considering this for a day or two, and what I think it comes down to is 1. management and 2. what process is proving the most frustrating/error-prone.
In your case it seems to be the deployments, so maybe your system could be tweaked a little.
Such as you could have the environments being back to single machines only for every machine you deploy to, then instead of a single project per customer you could have a few projects setup in such a way that it has a step per customer (and all variables could be scoped to that step) - and say the projects were separated into groups of 10-20 customers (alphabetically, package based whatever). This would allow for single deployments to x customers at once.

This way also ‘steps’ can be skipped if there are customers you don’t want to release to, (but then versions would be slightly out for them, just something to consider).

There really isn’t anything you are doing wrong, it’s a very unique situation, but maybe with a grouped-project approach the deployment side of it would get a little less painful.

Hopefully these ramblings help a little.
Vanessa

5

Vanessa,

Thanks for the feedback – I’ll take this back to the team and we’ll discuss. It’s nice to know that we haven’t missed anything major as well, that’s nice to know.

Rhys