Hi
Suppose if we have several branches (for each country) and their client machines.
For e.g.
Branch A and its ‘x’ number of clients
Branch B and its ‘y’ number of clients
.
.
Branch C and its ‘z’ number of clients
and similarly for other countries.
I am currently using each branch as a environment. i.e. Branch A environment, Branch B environment, and so on
So Branch A environment will contain its application server and all its clients…
However Octopus assumes environment to be like, Test, UAT, Pre-Production and Production.
So is it wise to use the way I am currently using environments for each branch? Or it is not recommended way?
Please advise.
Hi,
Thanks for getting in touch. In general, we don’t recommend that you’d use an environment per branch. I’d suggest reviewing our Channels documentation as the Channels concept was created to help manage multiple active versions of your product. In your scenario, you’re using branching to do this for different clients in different regions. You could create a branch with a version rule matching the packages created for each branch and have a single project to manage it. This also enables you to use a different project lifecycles to control the way releases are promoted between environments. You could use the same lifecycle or customise it as required for a certain region.
I’d also suggest reviewing our multi-tenant deployments documentation to see if you think this would suit your application. Multi-tenant deployments enables you to deploy a single project to the same environment multiple times and customise the deployment (process, variables etc) for each tenant (think of them as a customer/client) or group of tenants. From our guide …
Tenants in Octopus Deploy allow you to deploy your projects into multiple isolated containers inside your environments. It’s kind of like slicing up your environment into multiple pieces.
This could potentially help you depending on how your manage your client specific information.
Hope this helps!
Thanks
Rob
Hi Rob, Thanks for your response.
I have already created channels for different versions of the software.
However we have got ‘x’ branches and their ‘y’ client machines in total across ‘z’ number of markets.
So ideally it will be ‘z’ no. of environments to contain all the above target machines.
Thus we decided to keep each branch and its clients in a single environment so that it will give flexibility of choosing the environments(branches) accordingly for deployment. Each branch has an application server and its some number of clients
Application servers will be identified using ‘App-Server’ role
and clients will be identified using ‘Client’ role.
We will still club market specific machines into single environment in case we have to mass roll-out or do any activity on all machines together.
But need your advice, whether it is the right approach of having each branch(app + clients) into single environment?
Hi,
Thanks for the reply. After thinking about it, I realised that you’re essentially following a pattern we called environment per customer. This is a valid pattern that was used prior to the introduction of multi-tenant deployments as a first class concept. It was one of the most common approaches to handling deployments of a project for multiple customers/clients. The main disadvantage of this approach is that Octopus doesn’t handle a huge number of environments gracefully. It’s functional but it’s not ideal. Multi-tenant deployments was designed to handle tenant/client specific differences and it’s supported nicely in our projects and dashboard.
So to answer your question, yes, this is a valid approach however I don’t think we’d recommend it as you miss out on a lot of the benefits from the richer multi-tenant deployments feature.
Hope this helps!
Thanks
Rob
Thanks Rob,
what is the valid approach as per your view then?
As i said, I have already implemented channels for different versions of software,
We will use lifecycle to do rollout in phases i.e. starting with pilot branches, then phase-1 branches and then phase-2 branches.
What configuration would you recommend in my case?
Will it be grouping all the machines under single environment?
Please advise.
Hi,
I think that you’re on the right track using projects with channels but I would recommend using multi-tenant deployments as it makes deployments easier in the long run. That said, it is a relatively advanced feature and it can take some time to get it up and running. I’ll point you to a few specific pages to help you better understand it’s advantages in handling config and how to structure your environments.
Config
Deploying an app to multiple clients generally has common configuration values and as well as client/customer specific values. We introduced a mechanism to handle this with variable templates whereby you can provide only the values needed.
You can learn more about this at the following URL.
Environments
In general, you would still have a DEV, TEST, PROD environment structure (or whatever suits your team/company) and you still mark your deployment targets with roles. Multi-tenant deployments introduces tenant tags and tag sets to help you manage and organise your machines. You can create a tag set and tags to group your tenants/clients together as it makes sense to you. This could be something like ‘customer type’ with tags like pilot, phase 1, phase 2 etc as you described. Tagging your deployment targets then makes it easy to ensure your deploying to the right infrastructure for your customers. They can be combined too. This helps you at deployment time as you can simply select which tenants to deploy using one or more tags.
You can learn more about this at the following URLs.
Overall, I’d recommend reviewing our multi-tenant deployments guide and testing it out.
Hope this helps!
Thanks
Rob
Hi Rob, Thanks a lot for your efforts in emphasizing on multi-tenant deployment.
I am convinced that multi-tenant deployment is the right way to go.
Please can you see the attachment and let me know if my understanding is correct.
So lets say, I have three regions (environments) US, UK and Russia
Each environment will have ‘n’ number of tenants. and Each tenant will have a server and its clients. So basically my tenant is nothing but a branch.
I have tried to draw this as a picture in the attachment. Please can you advise whether this can be achieved?
Hi,
Thanks for following up. I think you’re definitely on the right track and your plan/structure should work fine. I’ll walk through a example structure based on your diagrams.
Environments:
I’d recommend having a DEV or TEST environment as most teams have an integration/test servers before going live. If this suits your environment, I think it’s a good idea.
DEV - Any servers used for development
TEST - Any servers used for testing
Region X
Region Y
Region Z
…
NOTE: The alternative to grouping your servers by region would be to maintain a more traditional DEV, TEST, PROD structure and use tenant tags to specify which ones should be used for each region.
Projects:
Creating one or more projects w/ channels as you described should work fine. I’d recommend having a custom lifecycle per channel to suit each region. i.e. Region X might need DEV -> TEST -> REGION X whereas Region Y might need DEV -> REGION Y. Essentially, I would structure this as it suits your environment.
It’s worth noting that it’s a good idea to utilise variable templates here to ensure each tenant specifies the variables required for it to work correctly.
Tenants:
Create as many tenants as needed and associate them w/ the appropriate project and environments. I’d suggest thinking about if there are any categories/tags that could help you organise/manage your tenants. Tenant tags make it quite easy to select and deploy to specific tenants or groups of tenants.
Hope this helps.
Thanks
Rob
Thanks Rob, Do you think the attached picture will work the way i am thinking using multi-deployment? And is there any limitations in number of Tenants?
I will tag the target machines in environment with specific Tenant names and it will be visible as attached.
Hi,
I don’t see any issues with your structure. It should work fine. Further, there aren’t any limits on the number of tenants. We currently have some customers with over a thousand tenants.
Hope this helps!
Thanks
Rob
