Should I have separate environments per team in Octopus Deploy?

Bob_Walker · 14 January 2020 20:10

I have three sets of teams:

Development
Sales
Customer Success

Each team has a set of VMs assigned to them. I want to prevent the development team from deploying to the sales team’s VMs and vice versa. In Octopus I see I can restrict a team’s permissions to a specific environment. Each team would have a set of environments. Is there a better approach?

Bob_Walker · 14 January 2020 20:39

This is not something I would recommend, as that is going to cause all kinds of problems later down the line.

Problem #1: Variables, if you add a new environment to a team then you will have to find all the environment scoped variables and add the new environment to it.
Problem #2: Lifecycles, if you add a new environment, you will need to add that environment to the lifecycle. The problem will then become, how will you get to production? If each team has their own environment(s) what is “production?” Each team will have to have their own lifecycle, and their own channel in the project.
Problem #3: The main dashboard and project overview screen will be a bear to scroll and find anything.
Problem #4: Maintenance and more maintenance, there are lots of hidden costs with having dozens upon dozens of environments.

Recommendation: Leverage Octopus Deploy’s Multi-Tenancy Feature

Keep your environments simple. Have a dev -> stage -> production.

Create tenants for each of your teams. If necessary create multiple tenants to support various use cases. For example, in this picture, check out the “internal customer”, it has multiple tenants. Each to support various use cases.

Tenants can be assigned to 1 to N environments. A common use case is sales and customer success team won’t have access to the development environment. They only have access to items ready for testing.