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
Pros:
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
Cons:
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
Pros:
Simple set up in Octopus
Cons:
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
Pros:
Still use the power of Octopus to do the heavy lifting
Cons:
Extra work
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?
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).
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: https://octopusdeploy.uservoice.com/admin/forums/170787-general/suggestions/6150522-collapsible-environment-tabs
If you have any comments it might be best directed there, as that ticket will be looked at as part of the evaluation.
