Environment naming -Best practices

[abiramradhakris]

Hi,

As per Environment docs and Best practices naming

Do we have the any naming convention for Environment, like Docs indicates "dev", "uat" and "pod" etc, but what if we have env name as "business-partner" & "private" as name of Env ? Is that a correct naming representation ?

.Do we have any recommendations/link for Env ?

Env naming allows multiple characters and few of symbols for the naming. but to define or derive the name of End, do we have any best practices ?

[ChrisHood · Accepted solution]

You can name your environments anything you'd like. The question is around what do we see as being best practice or common.

In most cases, terminology like dev, stage, qa, test, uat, prod, are understood. These are common names that can be found in just about every company that has development responsibility.

Consider onboarding new developers and you had to explain that private1-us -> actually meant your development environment, or that pub-est-delta -> actually meant your staging environment.

The naming is about maintaining consistency as well as simply naming your environments based on the role they play. When you see UAT, you know what UAT means. When you see QA, you know what QA means.

This also plays into the consideration of how open your API program is. The more open, the better. Building digital ecosystems that are easy to follow and understand without proprietary internal naming conventions, will help developers find what they need, and develop what you need.

Things like business unit names, or partners, private vs public, etc, can all be managed inside of your API products, or with access controls. For example, Partner A and Partner B could possibly see different API Products, but they would still access those APIs on the same environment. Business units would function the same way, where Team A only has access to API Product A and Team B only has access to API Product B, but both API Products would be on one environment.

My recommendation will always be :

2 Orgs --- A Non-prod Org and a Prod Org. You might call them company-np and Company-prod
Where company is the name of your company.

Then on non-prod you would have :
dev, test, perf

And on the prod you would have :

mock, sb (sandbox), uat, stage, live or prod

Ultimately, name your environments with what those environments functionally are supposed to do. It's the easiest to understand and manage.

[dchiesa1]

Do you mean "business-partner" as ¿ORG NAME?

I'm not sure that "private" is a good name for an environment. Normally we recommend you name the environment to correspond to the SDLC stage. Eg, prod, dev, stage, uat.

"private" does not seem to fit into that model.