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.
Tenants are assigned to targets.
Tenants can also be scoped to teams.
In addition, you can create project variable templates.
When a new variable is added without a default (or if a new tenant is added), you will be notified via a UI prompt that a variable is missing.
Clicking into the tenant will show you this:
If you would like to see an example please go here: https://samples.octopus.app/app#/Spaces-2