Environments usage query

pratik.surani's Avatar


22 Apr, 2017 09:54 AM

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.

  1. Support Staff 1 Posted by Rob Pearson on 24 Apr, 2017 01:56 AM

    Rob Pearson's Avatar


    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!



  2. 2 Posted by pratik.surani on 25 Apr, 2017 11:14 AM

    pratik.surani's Avatar

    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?

  3. Support Staff 3 Posted by Rob Pearson on 26 Apr, 2017 05:31 AM

    Rob Pearson's Avatar


    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!



  4. 4 Posted by pratik.surani on 26 Apr, 2017 09:17 AM

    pratik.surani's Avatar

    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.

  5. Support Staff 5 Posted by Rob Pearson on 27 Apr, 2017 02:43 AM

    Rob Pearson's Avatar


    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.

    You can learn more about this at the following URL.


    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!



  6. 6 Posted by pratik.surani on 17 May, 2017 02:55 PM

    pratik.surani's Avatar

    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?

  7. Support Staff 7 Posted by Rob Pearson on 22 May, 2017 10:27 AM

    Rob Pearson's Avatar


    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
    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.


    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.

    Hope this helps.



Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac