I’m looking for some advice on how to structure our Octopus setup. We are currently working mostly with Octopus Environments but with the addition of multi tenant deployment I’m reconsidering what the best approach is.
For our own software everything is fine and I know when to use multi-tenant deploy, but we use Octopus also to deploy 3rd party software (e.g. Windows Services) with quite a few dependencies. For this I am not sure if we should use multi tenant or if we are fine without.
Say we purchase ProductA from a company. ProductA is essentially a .msi package and potentially some dependency such as a C++ redist package.
We provide a running ProductA to different in-house departments (e.g. DeptA - DeptD), each department has their own environment (consisting of several servers) and we have a test environment to try out new versions.
So far so good. We set this up like this:
Configuration of the software is done completely outside of Octopus because it is a larger system with it’s own proprietary management interface. So mainly, we use this to deploy different versions of the software automatically. In the future configuration might be partly included, which would bring up the topic of different configuration settings for different departments. As of today we do not do this.
Dependencies are currently handled via the Process:
So we have a Project for a dependency that might be needed in ProductA, and ProductA’s process includes a step to also deploy “Dependency Project”.
I guess what I am asking is: How much of a train wreck is this approach? I figure that multi-tenant deployment could potentially do the same thing:
We would reduce the Environments to "Test Environment" and "Production". Each department would become a separate tenant instead of a separate environment.
Are my assumptions correct? If so, what benefits would this bring? So far the only benefit of a multi tenant setup would be the possibility of a department specific configuration.
Sorry if this question is too broad.