We are busy developing a system which needs to be deployed to multiple clients. Each client will have their own instance of the system. The system consists of an API, website, Windows services and specific infrastructure components (e.g. MSMQ queues). In summary we need to deploy a single system (collection of components) multiple times across multiple servers.
I have attached a simplified illustration of what we are trying to achieve.
The question relates to how best to structure our Octopus set up to enable efficient deployments.
We have a couple of ideas to solve the problem:
1) Set up an environment for each client
- We can control to which servers to deploy the system for a specific client
- We can deploy updates to specific clients without affecting other client instances
- We are looking to deploy the system to 100+ clients. This will make the Dashboard view in the Octopus website very difficult to navigate and it loses it’s effectiveness
- Once the system is built in our development and test environments, we will need to promote the single deployment from test to 100+ different clients
2) Set up a single environment for all our clients and have a Powershell script on the server to publish the release to the relevant locations on the different servers
- Rewriting Octopus and not using Octopus effectively
3) Write our own front end on top of the Octopus API to manage the promotion from our test environment to the 100+ client
- Still use the power of Octopus to do the heavy lifting
We use Octopus extensively for our other projects and it has changed to way we handle deployments completed, so we are very hesitant to deploy this system in a different way. With this in mind option 2 is not really an option for us.
What would your recommendation be to best handle the scenario?
Attached a clearer image depicting the multiple client instances across multiple servers
Sorry for the delay in getting back to you here. Multi-tenancy deployment is on our road map http://octopusdeploy.com/roadmap, but even a generous estimate would have it at 6 months away.
Until then the only way to deploy in such numbers like your scenarios is to make the compromise based on management versus deployment.
If you want to deploy to all customers within the one Project, then having a machine per customer per environment with its own role is the only way to really do this.
It does make the dashboards pretty unusable as you say in your cons for this scenario, but you do not need them for promotions. We re making some changes to the dashboard in an upcoming release which should make it more manageable. We also have customers who have 700+ machines in single environments and still use the UI, others with more who use the API and command line. (A combination of 1 and 3).
Here is a bit of documentation on handling multi-tenant deployments in our current Octopus state. http://docs.octopusdeploy.com/display/OD/Multi-tenant+deployments
Thank you for the feedback, we will read the documentation provided.
I am sure we will find a solution to the problem and if it is on the roadmap, we can handle the “pain” for a while.
Are you able to provide any further details about the changes you’re making to the dashboard? If the environments wrapped, to span over multiple rows instead of continuing horizontally, that would help.
We don’t have anything concrete, and are working through a few different ideas, it’s part of a few new features coming with 2.6.
The following UserVoice is probably going to be a part of it, while it’s being completed:
If you have any comments it might be best directed there, as that ticket will be looked at as part of the evaluation.