Rob Pearson on 24 Apr, 2017 01:56 AM
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.
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?
Rob Pearson on 26 Apr, 2017 05:31 AM
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.
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?
Rob Pearson on 27 Apr, 2017 02:43 AM
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.
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.
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.
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?
Rob Pearson on 22 May, 2017 10:27 AM
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.
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
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.
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.
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.