Common database (step) for environments / tenants

I’m wondering if there is a possibility to set up steps common for multiple environments, for example, to deploy database that is common for 2 different environments.
My case:
I’m deploying application to 2 localisations, let’s say US and UK, but both the applications are using the same database. For now, every environment configured in Octopus is duplicated for US and UK, so I have DevUS, DevUK, TestUS, TestUK etc. I have configured process to deploy database during UK deployments, but it’s not a perfect approach since I’d like to deploy application only for US.
UK process (for UK envs.): 1. Deploy database; 2. Deploy web
US process (for US envs.): 1. Deploy web
Is there a way to set up process to deploy database once for both environments?
What about multi tenant deployments? Is there a feature that could resolve my problem?


Hi Piotr,

Your situation is a little unusual in that it looks like you can deploy separate versions of your Web app to the UK and US but have them use the same database version? Usually if they need the same database version you just deploy everything at once and have them in the same environments, or if they need different database versions they have their own db and you can deploy completely independently.

Or if the database is really completely independent you just make it it’s own project and deploy it when required.

I think in your situation I would change my database deployment process so that it can be run multiple times with no problems. So either through a script step in Octopus or just in your database code, as the first step check the current db version (again either checking Octopus’s version, or write a dbversion value into the db as part of each update) then if the db version already matches the one we’re applying exit without doing anything.

That would allow you to just include the deploy database step in all deployments, and it would just run in with whichever one is first.


Thank you for the fast reply.
I know that this approach is a little bit weird, but I can’t refactor my process right now and turn everything upside down. I think, I’ll stick to the solution with deploying database during UK as well as US deployments. In the worst scenario, database will be deployed twice.