Best practices for using the same environment across different projects/teams

[#1]

In addition to having a source control and proper branching process in place, What are the factors to consider/best practices if we decide to use a single environment across different teams irrespective of the teams working on the same set of API proxies or different.

Here are some of the things to consider if we decide to use a single environment across different teams

#1 API proxy name, Cache, KVM, target servers names should have their team names as the prefix. (Environment entities)

#2 We can have team specific virtual hosts too if the certs are a wild card or the ops team is responsible for creating the virtual hosts and provide them to the dev teams to avoid classification errors.

#3 App name, developer, company names should have their team names as the prefix. (org level entities)

#4 Externalize all the configurations. for example : config.json(dev binding) or KMVs. (runtime binding)

#5 If the teams are working on different API proxies, we don't need to worry about the base paths but if they are working the same proxy it will create base path conflicts. At least, the dev environment should be different.

Are there any other factors to be considered or any pros and cons?

[#2]

Below are some of the things to consider if we decide to use a single environment across different teams

#1 API proxy name, Cache, KVM, API proxy basepath, target servers names should have their team names as the prefix. (Environment entities)

#2 We can have team specific virtual hosts too if the certs are a wild card or the ops team is responsible for creating the virtual hosts and provide them to the dev teams to avoid classification errors.

#3 App name, developer, company names should have their team names as the prefix. (org level entities)

#4 Externalize all the configurations. for example : config.json(dev binding) or KMVs. (runtime binding)

The above applies only to dev environment and no specific measures to be taken care in other environments.

Are there any other factors to be considered or any pros and cons?

[ozanseymen]

I am having trouble understanding the reason behind all this. What is the real benefit of having this segregation? Is it RBAC, is it marking your territory? Most teams are used to sharing such resources - I've never seen devs doing this for SAP projects or IIS, etc when they are developing against a shared component.

Also there is a danger here from environment promotion POV that once code is out of dev, many org level resource references, e.g. KVM name, need to be changed/replaced by CI/build tool. This seems like an unnecessary headache and may cause confusion.

What are the reasons you feel require such naming conventions?

[#4]

Hi @oseymen@apigee.com , thanks for your answer.

I came up with the above post trying to address a common question "whether I should go for single env or multiple env when I have multiple isolated teams working on different features(different API proxies) on the private cloud."

Here are some of the pros of cons I could think of

Multiple environments:

Pros:

Environment(teams) can scale by binding mps-environment.

Teams don't need to worry about namespace conflicts.

Cons:

A specific cache resource cannot be accessed across the environments.

Redundant Virtual hosts, target servers creation.

More operations effort in managing the multiple environments

Environment-specific Analytics records are captured.

Single environment:

Pros :

Environment-specific Analytics records.

Less complicated configuration management.

Cache resources can be used as they are at environment level.

Cons:

Cannot scale to a specific team's capacity requirement. (We can’t bind MPs-teams(environments))

( bad code with memory leaks can bring the whole system down, not always but we will lose the benefits of isolating when needed or in specific cases)

Resources are shared.

Config entities namespace conflicts.

And the points I mentioned in the post, conventional naming, etc. is to address the # 2 and #3 (cons) if we want to have single environment from dev till prod. If the teams are working on different API proxies, we don't need to worry about the base paths, but if they are working the same proxy, it will create base path conflicts. At least, the dev environment should be different in this case which will not affect the environment promotion + their testing strategy.