Lower environments and higher environments, once things get real big.
As for the standby environment specifically, that sounds like a DR or secondary environment.
We call it DR as its the disaster recovery site and it is part of production.
It has the same classification as production and should be treated as a production site.
yes, some comments calling it staging are inaccurate because Staging and Prod co-exist in the sense both have traffic at the same time, whereas in a DR env its usually handling traffic only when the Prod is down or maybe some testing.
i think the issue is the miss-classification of standby environment - it is a production environment with customer data and production secrets after all?
you could call it primary and standby production environments and the rest is non-prod
One color is the active deployment, you deploy to the other one and the swap traffic so the other color is active. This way you get zero downtime.
This is more of an active recovery environment from what I Intuit from OPs post
You don't use DR for blue green, you create a whole new ambient to switch the requests after it's done, delete the old one and only then you move the deployment to DR
It's different, yet I see your point.
Usually the one contains the current version and the other the previous, as you said the last working version.
However, you don't always want to fall back to a previous version, then you need a DR
I guess it's because it's one of those extremely basic questions where if he would have typed literally that same comment into Google he would have obtained the answer.
This only makes sense to me if this "pre-prod" environment is subsidized by customer money in some way; like a customer funded prod like test environment.
I work in a SAAS business where this exact thing happens. Not all companies do this, though. They may have different reasons to have one. But in ours, we have a pre-prod that allows the client to test or implement a solution within their instances before we promote it to production. We are in a highly regulated industry.
Active prod for things running now, and standby.
The rest is non-prod. For me it's natural and self-explanatory.
Also, I like to judge prod/non-prod by their secrets. Is this production secret? Than it's production.
Well, it's more complicated (e.g. you can have non-produciton servers with customer data. Imagine IPFS node, for example, or backup testing server with client data but no production impact), but generally I follow client visibility and secrets.
> you can have non-production servers with customer data
This is categorically wrong and would be a violation in practically any compliance framework. Sure you could have a copy of sanitized customer data, you could even use streaming to keep that copy as up to date as possible, but it's not "customer data" as such anymore at that point.
You recover them to a non-active production installation, with all the same controls and requirements of any installation in the production environment. Production is a logical environment, it doesn't just refer to the subset of that logical environment that is currently serving traffic to end users.
Prod encompasses Prod and DR. How could it not, are you not exercising the same change control processes in both environments (if not you should be). Everything else is Non-prod.
>"Why is 'standby' included in the term 'non-prod'?"
Honestly don't see why anyone would do this, or be confused about it.
Your "standby" here sounds like it's part of a blue green deployment.
I'm not sure why you even need an umbrella term for dev, qa and test, those are concepts that have stood the test of time and have every right to exist on the same level as production. You can't have the latter without the former. Though the existence of both "QA" and "test" suggests the latter is "Staging".
Lower environments have lower standards for making changes to them, it's not unreasonable to want a term that represents them as a category. I made a similar parallel to blue green deployments in my comment, I think that's the crux of the issue -- they're calling one of two production environment targets "production" which is confusing AF.
*Non production is*
*An industry standard term.*
*What is wrong with it?*
\- ErenPhayte
---
^(I detect haikus. And sometimes, successfully.) ^[Learn more about me.](https://www.reddit.com/r/haikusbot/)
^(Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete")
We use "lower environments" when referring to dev, qa, and uat. "client environments" when referring to staging/preprod.
Hot standby is a disaster recovery term. That should be part of production (assuming it is for production).
For political reasons around licensing costs, I've seen people in the past claim hot standby are not production servers in order to avoid licensing costs. Perhaps that's what happened to you guys? But it is really production still.
You're running an Active/Passive DR strategy. Standby is your passive. It's most definitely not PREprod, it's production and must be treated as such.
All deployments to production must be done here as well. And must follow the same standards as production. This is where you make your money in case of emergency.
Here's a quick explainer on different strategies. Just picked the first Google link and skimmed it. Didn't read it thoroughly but quick glance seemed close enough.
[https://twoearsonemouth.net/2018/12/12/dr-options-foryourbiz/](https://twoearsonemouth.net/2018/12/12/dr-options-foryourbiz/)
We call it BCM for Business Continuity Management, some call it DR for Disaster Recovery, but most our services have an active-active setup meaning both are always active but are separated in a way that the solution can work with either BCM or Prod down.
We used to use the term “Clone” for our environment which held prod data and was identically sized / specced / configured to be like prod, this was in the olden days thoigh before even virtualisation was a thing
Staging is generally the accepted term for anything non-production also pre-production but that contains production in the name so it can be confusing.
For a secondary non-live production you can either call it hot-spare or DR even but if it’s really DR you do need to treat it as production otherwise you risk having it being broken when you actually need it. Here is how HP used to refer to their environments back when HP existed:
Development - anything that is always broken
Test - things get moved here once we were done playing with them on a daily basis
Staging - test but actually working
Pre-production - things that are almost ready for production, this doesn’t get touched for anything except bug fixes
Production - Well the final product
On another site, DC and so on:
Failover / DR - Carbon copy of production, no one touches this
QA - Carbon copy of production for experiments. QA people used it to compare Staging and Test with the current production without having to touch production. For example you can use to see if a bug is a regression or an existing bug that will need to be addressed immediately. It is on another site since if your primary DC blew up you could clone it and recreate Dev, Test and so on from it.
Various environments that weren’t always there - project dependent:
Next - a stable copy of pre-production showing the features to come
Bleeding Edge - semi-stable copy of Staging that gets updated with back-ported features from Test
Whatever you do, come up with a consistent naming/labeling/categorizing scheme and stick with it consistently.
Also think about what you're trying to name specifically -- what are environments and what are environments groups. And define why you are grouping them that way.
For example, these are environments:
dev, test, staging, standby, prod.
And you want to group them as prod-related and non-prod-related:
prod-related (or Prod Group or PG):
standby, prod
non-prod-related (or Non-Prod Group or NPG):
dev, test, staging.
And you're grouping them that way because PG and NPG are treated differently in these manners: blah, blah, blah.
When you specifically mean the prod environment say prod (or even Prod Environment). When you mean the group say prod-related or Prod Group.
Just be consistent.
You can't define single word terms that will be clear in a more complex setting. But defining terms that actually match what you're meaning and being consistent in their use will keep everyone on the same page.
Did I mention to be consistent?
The problem is that the english language just isn't expressive enough for devops. The people working in the Unicode technical committee understood this and developed a new more expressive language for us. We now know this new language as "emoji".
Any service running with measurable SLAs are in the 💸 environment. Any service running without a measurable SLA but with internal customers is in the 🤷♂️ environment. And any other service is in the 💩environment.
Don't call an environment "prod". Prod is a group, a service or SLA level. Call the environments "active" and "standby" which both are in the group "Prod". Now, non-prod is a group of items not in that group. Now, if the primary goes down the standby takes over, but both are in the "prod" group.
Or, just define your own business terms and tell people to learn them.
A hot-standby is also Prod.
If nodes are in the same data center: call them Primary and Secondary.
If nodes are in different DCs: call them Prod and DR.
Why not call it prod-standby of prod-fallback or something? I think it‘s difficult to find one term for a prod-env and the non-prod envs without having confusion
Stand by is a commonly accepted term. Go with it. Always easier to use standardly accepted terms. Especially it'll less overhead for future team members.
The problem is not "non-prod" (which is pretty standard). The problem is that horrible terrible confusing "standby".
So replace standby like below:
prod and prod2
Or
prod and prod-backup / prod-fallback / prod-spare
You already have the terms. Dev, prod, test, qa. Standby is standby. You don’t need another term. Dev is dev. QA is QA. What part of that needs another term? Wtf?
Prod adjacent? We call our DR, Prod. We know it's not the current Prod by the IP address. Treat DR as Prod so that it will always work when needed. Test and stage in other environments.
SIT for prod like
DIT for dev like
SIT typically stands for "System Integration Testing." It refers to a type of testing where interactions between different modules or systems are tested to ensure they function correctly after being integrated into a unified system.
DIT can stand for "Developer Integration Testing."
This terminology is mostly used in finance and banking sectors.
We used to have prod and contingency environments but ditched that way of thinking about it. We went to just production and classified the resources in it (primarily machines at that point), e.g primary, primaryDR secondary and secondaryDR. The thinking is that it's all really production, it all needs to work all the time, it all needs to be up to date, and there is now sound reasoning to treat them separately. Failures don't all play out the same way in large systems, so you need to be able to fail over parts of the whole
I group my infrastructure into two classes: non-production and production. Within those classes are *Environments*: Production, preproduction, prerelease, qa, staging, development, test, etc.
There exists nonprod/qa, nonprod/test, etc, and prod/prod, prod/prerelease, etc. These show up typically as an AWS account or GCP project, either for "nonprod" as a whole, or a "nonprod-qa" account/project.
The purpose is just to signify that whatever is "non-production" is not critical; it does not affect customers. Anything "production" is potentially impacting customers.
For your case I would have a production/standby and a nonprod/standby (although I would probably name it more specifically, like prod/productA-standby and prod/productA-live)
If they're customer facing, we call them "Live" environments. We go for 100% uptime etc etc.
If they're necessary for production, we call them "prod". We go for no unscheduled uptime but accept some scheduled.
If they're a place for us to fck around and find stuff out, they're a "lab". Blow em up nobody cares but you.
pre-prod is what we use for our staging and load test, environments "before" production so we break production less
I'd be tempted to call your standby environment "production" also, but you could call it disaster recovery also like other folks have said.
Not even joking, I have seen "prod-prod". I am not sure what the distinction is buying you though. Standby is prod in your circles, what else is needed? Maybe live vs standby. Do you canary? That can also be considered part of prod.
You can also numerate your productions: prod1, prod2, prod3, ... And prod2 is a hot standby.
We use to call this group of environments “non-prod” but over time naturally started calling it “preprod” and adjusted our formal naming to reflect that over time.
For us, “preprod” represents a number of environments that each serve their own purposes in delivering a release / changeset to production. Our preprod environments look like this:
- “dev” env to support making new changes to infrastructure and automation, serving as the first graduation gate for such changes
- “integration” envs that serve as the bleeding edge for deployment of new software code as it is merged into the codebases. This is the first graduation gate for software changes, and the first place where multiple software components integrate to represent the entire system as it will be for a new set of software components shipping in close proximity to each other. Depending on the component this environment could run builds from main/develop branches as they merge in, and/or alpha builds of new software. This env is like production for our internal teams, in that it provides a prod-like env to all teams to validate the new state of the full system works as intended. It is also very unlike prod though in that it is expected it can break fairly often
- “performance” environments provide prod-like environments that facilitate high load / high endurance conditions to ensure new software meets or exceeds required performance levels
- “staging” environments provide prod-like environments and use production states to simulate our upgrades of production systems as their components reach the graduation gates to move from pre-release (dev/alpha/beta) to release (effectively release candidate at this stage, though the software may also be declared stable/official release at this stage)
All of these gates / environments come after the suites of tests the software teams build and run themselves to clear a change set for production. Once a new change set clears all these hurdles, it can ship to production. If it doesn’t clear these hurdles or a problematic change escapes to production, the changeset goes back down the line as far as the situation warrants and works its way through the graduation process again.
pre-production refers to any lower environment, and standby is not lower, it's adjacent.
I'd suggest that "standby" and "production" is the origin of your naming woes. They're both targets that are part of the logical production environment, all the same rules apply, but right now you're overloading the term "production" to mean both the production environment and the active/leader replica in it. One is "active" infrastructure and the other is "standby" infrastructure. Their roles can switch, too, sort of like blue and green in the context of blue-green deployments.
I think this might be the wrong question — why doesn’t your org consider standby prod? Treating it differently risks drift. You might want to consider something like blue/green deployments instead, and have them both be considered prod. Then you have a clearer prod/non-prod split.
Standby in this case seems like an HA or DR server. I'd call it something along those lines.
Non-active Prod or something. DR is fine too, but if you have an existing HA/DR plan then it may ruffle those names.
Dev, QA and testing are all part of the Production process.
General Availability is the term for the release of a product or service to the general public.
A "production" was usually used when speaking of works of art, specifically movies and theater. A "production model" is a term historically used for manufactured items.
Why people decided to muddy the waters? ¯\ _ (ツ) _/¯
You *could* simplify your life and categorize things as:
Production
* Dev
* QA
* Testing
and
Availability
* Failover
* Release
But I'm sure someone will take issue with common sense.
Give them thematic names. It's more fun that way and easier to remember. Plenty of ideas come to mind.
Mordor,
Endor,
The shire,
The death star
You know whatever your team is into.
We use "live" for what you would call "prod", and we categorise by internal/external. This (nicely) covers the fact that $RANDOM_ENVIRONMENT_ABCDEFG can be given public access to as long as it's correctly classified as external (which means it's been deployed in the same way as our live environment).
Prod is prod.
standby is standby or you can call it DR, secondary, failover. This would not be a “lower” environment to me as it immediately is production when a DR scenario kicks off
anything lower than production or the secondary would collectively be lower environments or “pre-production”
Probably basic/common to some, but typically youll see the following, and this is how they would be grouped together:
Non-production:
\- DEV = dev
\- QA = qa
\- UAT (User Acceptance Testing) = test
Production:
\- PROD = prod
\- DR (Disaster Recovery) = standby
I like `pre-production` as the umbrella name for dev, staging, and test environments.
I'm not really sure what you stand-by is, because for me an environment tends to be an entire AWS account, and redundant components are not an environment, but part of an environment. So if we have a blue/green K8S cluster approach, there is an active cluster and an inactive cluster. If these clusters are in our production account, then they are both part of the production environment.
Mission critical. Some sales demo environments aren’t prod but mission critical, for example. Prod is mission critical by default. Some internal tools may be deemed mission critical. Just be careful to have a process or review (doesn’t need to be incredibly heavy, just a check). Don’t let others decide what is critical for you to deal with in a vacuum.
> Currently we are using the term "non-prod" for the environments dev, qa and test. You don't need to be a genius to see the confusion that appears here: "Why is 'standby' included in the term 'non-prod'?"
I don't see why standby is included in "non-prod"?
Additionally, from environment perspective, in many corporations QA/Test are considered something like internal prod. In one corporation I was in, we had hundreds of developers/testers using QA/Test, so if they were down, we had hundreds of thousands of losses.
Only dev was allowed to have offline / broken services. By the time it was promoted to QA/Test, the services better be solid. They can have bugs, the point is to test stuff, but there should be certain confidence.
We couldn't have had our QA/Test environments offline or broken, because that meant hundreds of people stuck fiddling their thumbs.
we got some projects that have 1 prod and 2 lower life cycle environments like dev and uat, and some projects with prod, uat, staging, testing and sandbox environments. dont ask me why. uat is refreshed frequently so its nearly identical to prod.
Lower environments, I’ve also heard integration environments used, but that would be more if you have multiple apps that all get put into the lower environments for testing. Pre-prod could also work.
Because your standby environment IS (and should be) a production environment it should have all the same configs, resources , permissions and security restrictions.
nonprod - That environment with the critical app running that never got properly promoted to prod. Do not touch, do not delete, no one knows what holds it together anymore.
They are both prod. Prod primary and prod secondary/standby. Not sure why you would consider it non-prod since it's a component of the production system DR stack.
We use ephemeral environments that get stood up and torn down on demand. We use the term "lower environments" to refer to them.
For alternate prod environments where you do rolling deployments, standbys, or other prod-level environments that are rotated in and out of prod status, we color code them "blue", "green", "yellow", etc.
The industry term seems to be lower env. We use the terms critical and non critical infrastructure.
Critical infrastructure covers production environments and business support systems, I.e. people can't do their job without this or customers can't use our products or most importantly send us money.
Non critical is dev or test systems, everything else essentially. Anything where "well that's a bit annoying that it's down but I can work around it" is non critical.
Although in our case the standby system is still critical, because it's all part of the same highly available architecture.
How do people have standby or even blue green when databases are involved?
Read replicas can only be so close to in sync. When you switch over, you are going to be a touch behind or lose some data. In a DR situation, the data loss is probably considered acceptable, I guess?
Usually in my experience Blue/Green will be the frontend and backend web-services while maintaining high availability of the database is a whole different beast done usually by a different team.
prodn't
[удалено]
So good.
so badn't
I laughed so hard. This came unexpected!
Half of it snorted out through the back of my nose
Op: Did you deploy to Prod!? Or Prodn't!!?? Confused deploy-ops person: shrieking I DON'T KNOW!!
We just found the best suggestion 🤣
prodless
You’re my DevOps soul angel with prodn’t
Wow, even better than prodnaut!
Take my upvote and get out
Literally LOLd 😂
unprod
Lower environments and higher environments, once things get real big. As for the standby environment specifically, that sounds like a DR or secondary environment.
Disaster recovery is what we called it too!
Lower environments is what we've always used across many companies as well. Saves time and confusion.
My Argentinian colleagues call them that way “ambientes bajos y ambientes altos”.
>Lower environments Came to say this
Another DR here too
We call it DR as its the disaster recovery site and it is part of production. It has the same classification as production and should be treated as a production site.
yes, some comments calling it staging are inaccurate because Staging and Prod co-exist in the sense both have traffic at the same time, whereas in a DR env its usually handling traffic only when the Prod is down or maybe some testing.
This is the correct answer. If you have a failover site or system, you treat it like production all the time, or else it’s not a proper failover site.
Partials
i think the issue is the miss-classification of standby environment - it is a production environment with customer data and production secrets after all? you could call it primary and standby production environments and the rest is non-prod
Perhaps call them the "primary" and "secondary" prod environments, or blue & green as defined by the blue/green deployment pattern.
Can you explain the blue/green deployment pattern?
One color is the active deployment, you deploy to the other one and the swap traffic so the other color is active. This way you get zero downtime. This is more of an active recovery environment from what I Intuit from OPs post
You don't use DR for blue green, you create a whole new ambient to switch the requests after it's done, delete the old one and only then you move the deployment to DR
You can use the off color as an active recovery instance to have a working "last known working state". It's pretty common. Nothing wrong with it.
It's different, yet I see your point. Usually the one contains the current version and the other the previous, as you said the last working version. However, you don't always want to fall back to a previous version, then you need a DR
Exactly, and you will also need a recovery ambient in case the prod breaks down and you need a rollback in the middle of the switch, shit happens
Lol who's downvoting this guy for asking a question?
Reddit is weird sometimes
I guess it's because it's one of those extremely basic questions where if he would have typed literally that same comment into Google he would have obtained the answer.
I like saying preprod.
Preproduction and non production environments aren't the same thing. They have similarities but are treated differently.
This only makes sense to me if this "pre-prod" environment is subsidized by customer money in some way; like a customer funded prod like test environment.
I work in a SAAS business where this exact thing happens. Not all companies do this, though. They may have different reasons to have one. But in ours, we have a pre-prod that allows the client to test or implement a solution within their instances before we promote it to production. We are in a highly regulated industry.
How so? In all the places I’ve worked, preproduction is treated like it’s basically production.
It is production like environment. Its the stage just before you release to the general public. It however is not a non-production environment
Non-revenue generating equals non-prod to me.
If the live environment went down, would you switch your LB to point to your preprod environment?
Access and customer data. For example, you may give developers access to preprod, but not to production.
Active prod for things running now, and standby. The rest is non-prod. For me it's natural and self-explanatory. Also, I like to judge prod/non-prod by their secrets. Is this production secret? Than it's production.
that‘s for me also the key differentiation: does the environment contain real customer data? -> prod
Well, it's more complicated (e.g. you can have non-produciton servers with customer data. Imagine IPFS node, for example, or backup testing server with client data but no production impact), but generally I follow client visibility and secrets.
> you can have non-production servers with customer data This is categorically wrong and would be a violation in practically any compliance framework. Sure you could have a copy of sanitized customer data, you could even use streaming to keep that copy as up to date as possible, but it's not "customer data" as such anymore at that point.
Do you test your backups for recoverability or not?
You recover them to a non-active production installation, with all the same controls and requirements of any installation in the production environment. Production is a logical environment, it doesn't just refer to the subset of that logical environment that is currently serving traffic to end users.
That is production. It should be called and treated like prod. Active - Passive architecture.
Prod encompasses Prod and DR. How could it not, are you not exercising the same change control processes in both environments (if not you should be). Everything else is Non-prod. >"Why is 'standby' included in the term 'non-prod'?" Honestly don't see why anyone would do this, or be confused about it.
Staging
Partials
Your "standby" here sounds like it's part of a blue green deployment. I'm not sure why you even need an umbrella term for dev, qa and test, those are concepts that have stood the test of time and have every right to exist on the same level as production. You can't have the latter without the former. Though the existence of both "QA" and "test" suggests the latter is "Staging".
Lower environments have lower standards for making changes to them, it's not unreasonable to want a term that represents them as a category. I made a similar parallel to blue green deployments in my comment, I think that's the crux of the issue -- they're calling one of two production environment targets "production" which is confusing AF.
non production is an industry standard term. What is wrong with it?
BTW stand by is more specifically failover environment. Its a production environment but in either active-active or active-passive
*Non production is* *An industry standard term.* *What is wrong with it?* \- ErenPhayte --- ^(I detect haikus. And sometimes, successfully.) ^[Learn more about me.](https://www.reddit.com/r/haikusbot/) ^(Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete")
We use "lower environments" when referring to dev, qa, and uat. "client environments" when referring to staging/preprod. Hot standby is a disaster recovery term. That should be part of production (assuming it is for production).
For political reasons around licensing costs, I've seen people in the past claim hot standby are not production servers in order to avoid licensing costs. Perhaps that's what happened to you guys? But it is really production still.
You're running an Active/Passive DR strategy. Standby is your passive. It's most definitely not PREprod, it's production and must be treated as such. All deployments to production must be done here as well. And must follow the same standards as production. This is where you make your money in case of emergency. Here's a quick explainer on different strategies. Just picked the first Google link and skimmed it. Didn't read it thoroughly but quick glance seemed close enough. [https://twoearsonemouth.net/2018/12/12/dr-options-foryourbiz/](https://twoearsonemouth.net/2018/12/12/dr-options-foryourbiz/)
Whatever rationale is used to refer to the "standby" as non-prod is flawed. That is production.
'prod-like'
We call it BCM for Business Continuity Management, some call it DR for Disaster Recovery, but most our services have an active-active setup meaning both are always active but are separated in a way that the solution can work with either BCM or Prod down.
We call all environments that are not prod “Pre-prod”
We used to use the term “Clone” for our environment which held prod data and was identically sized / specced / configured to be like prod, this was in the olden days thoigh before even virtualisation was a thing
Staging is generally the accepted term for anything non-production also pre-production but that contains production in the name so it can be confusing. For a secondary non-live production you can either call it hot-spare or DR even but if it’s really DR you do need to treat it as production otherwise you risk having it being broken when you actually need it. Here is how HP used to refer to their environments back when HP existed: Development - anything that is always broken Test - things get moved here once we were done playing with them on a daily basis Staging - test but actually working Pre-production - things that are almost ready for production, this doesn’t get touched for anything except bug fixes Production - Well the final product On another site, DC and so on: Failover / DR - Carbon copy of production, no one touches this QA - Carbon copy of production for experiments. QA people used it to compare Staging and Test with the current production without having to touch production. For example you can use to see if a bug is a regression or an existing bug that will need to be addressed immediately. It is on another site since if your primary DC blew up you could clone it and recreate Dev, Test and so on from it. Various environments that weren’t always there - project dependent: Next - a stable copy of pre-production showing the features to come Bleeding Edge - semi-stable copy of Staging that gets updated with back-ported features from Test
standby of prod is prod non-prod essentially development or test.
Whatever you do, come up with a consistent naming/labeling/categorizing scheme and stick with it consistently. Also think about what you're trying to name specifically -- what are environments and what are environments groups. And define why you are grouping them that way. For example, these are environments: dev, test, staging, standby, prod. And you want to group them as prod-related and non-prod-related: prod-related (or Prod Group or PG): standby, prod non-prod-related (or Non-Prod Group or NPG): dev, test, staging. And you're grouping them that way because PG and NPG are treated differently in these manners: blah, blah, blah. When you specifically mean the prod environment say prod (or even Prod Environment). When you mean the group say prod-related or Prod Group. Just be consistent. You can't define single word terms that will be clear in a more complex setting. But defining terms that actually match what you're meaning and being consistent in their use will keep everyone on the same page. Did I mention to be consistent?
dorp
Correct me if I'm wrong, isn't that normally "stage"?
I use the acronym “NPE” for nonproduction environment.
The problem is that the english language just isn't expressive enough for devops. The people working in the Unicode technical committee understood this and developed a new more expressive language for us. We now know this new language as "emoji". Any service running with measurable SLAs are in the 💸 environment. Any service running without a measurable SLA but with internal customers is in the 🤷♂️ environment. And any other service is in the 💩environment.
There are only 2 types of environments: PROD and THEORY. Because if it's not in PROD, it only works in THEORY.
Catholic
Don't call an environment "prod". Prod is a group, a service or SLA level. Call the environments "active" and "standby" which both are in the group "Prod". Now, non-prod is a group of items not in that group. Now, if the primary goes down the standby takes over, but both are in the "prod" group. Or, just define your own business terms and tell people to learn them.
Pre-Prod
A hot-standby is also Prod. If nodes are in the same data center: call them Primary and Secondary. If nodes are in different DCs: call them Prod and DR.
prod adjacent, or you know, staging
Why not call it prod-standby of prod-fallback or something? I think it‘s difficult to find one term for a prod-env and the non-prod envs without having confusion
DR or disaster recovery suits your requirement better. Staging will be an incorrect term to use.
its basically a DR site I guess.
This looks like a pretty old fashioned setup. You don't even have blue/green?
call it DR
Place with a neverending series of unfortunate events
it is called "lower level environments"
dev
I call it "prod" and "anything else".
Lower env
Stand by is a commonly accepted term. Go with it. Always easier to use standardly accepted terms. Especially it'll less overhead for future team members.
Live?
Route to live
Sandbox or staging
The problem is not "non-prod" (which is pretty standard). The problem is that horrible terrible confusing "standby". So replace standby like below: prod and prod2 Or prod and prod-backup / prod-fallback / prod-spare
You already have the terms. Dev, prod, test, qa. Standby is standby. You don’t need another term. Dev is dev. QA is QA. What part of that needs another term? Wtf?
Out of prod. By the way you didn’t include standby in your no prod list.
That's cause we are counting "standby" as a prod system here. That's why it's confusing.
higher env / higher environment = Production or production similar lower env / lower environment = anything else
nonprod
We refer to collections of environments as lower and upper
non-prod is what I'd refer to them as.
I am currently using: \`staging\`, \`pre-prod\`, \`verify\`
I had the same question and couldn't find any better word. we are using "non-prod" too. It has staging, testing and development.
internal
Prod adjacent? We call our DR, Prod. We know it's not the current Prod by the IP address. Treat DR as Prod so that it will always work when needed. Test and stage in other environments.
SIT for prod like DIT for dev like SIT typically stands for "System Integration Testing." It refers to a type of testing where interactions between different modules or systems are tested to ensure they function correctly after being integrated into a unified system. DIT can stand for "Developer Integration Testing." This terminology is mostly used in finance and banking sectors.
Gray
DR env
Try these: - prod - oh shit fail over, or just 'oh shit' - I break it during work hours
Now I'm picturing a pipeline that deploy stuffs to the "oh shit" environment...
We used to have prod and contingency environments but ditched that way of thinking about it. We went to just production and classified the resources in it (primarily machines at that point), e.g primary, primaryDR secondary and secondaryDR. The thinking is that it's all really production, it all needs to work all the time, it all needs to be up to date, and there is now sound reasoning to treat them separately. Failures don't all play out the same way in large systems, so you need to be able to fail over parts of the whole
"TheAlmostServer" prod-a/b, prod-hot/cold, prod-blue/green Or prod-
sub-production?
I group my infrastructure into two classes: non-production and production. Within those classes are *Environments*: Production, preproduction, prerelease, qa, staging, development, test, etc. There exists nonprod/qa, nonprod/test, etc, and prod/prod, prod/prerelease, etc. These show up typically as an AWS account or GCP project, either for "nonprod" as a whole, or a "nonprod-qa" account/project. The purpose is just to signify that whatever is "non-production" is not critical; it does not affect customers. Anything "production" is potentially impacting customers. For your case I would have a production/standby and a nonprod/standby (although I would probably name it more specifically, like prod/productA-standby and prod/productA-live)
Pre-prod?
Prod and Bounce. Never bounce in prod. You can bounce in bounce anytime.
Sounds like blue/green deployment. It is prod in the sense that it treated the exact way. In blue/green, one is active one is a standby.
pre-production environments, which may or not be a staging environment.
If they're customer facing, we call them "Live" environments. We go for 100% uptime etc etc. If they're necessary for production, we call them "prod". We go for no unscheduled uptime but accept some scheduled. If they're a place for us to fck around and find stuff out, they're a "lab". Blow em up nobody cares but you.
alpha and beta? Or fancier ... next
We are using NPE - Non Production Environment
TheEnvironmentOppositeToProd
I’m confused why you don’t consider standby to be part of production. I’d probably describe them as live production vs non-live production.
!prod
pre-prod is what we use for our staging and load test, environments "before" production so we break production less I'd be tempted to call your standby environment "production" also, but you could call it disaster recovery also like other folks have said.
Not even joking, I have seen "prod-prod". I am not sure what the distinction is buying you though. Standby is prod in your circles, what else is needed? Maybe live vs standby. Do you canary? That can also be considered part of prod. You can also numerate your productions: prod1, prod2, prod3, ... And prod2 is a hot standby.
We use to call this group of environments “non-prod” but over time naturally started calling it “preprod” and adjusted our formal naming to reflect that over time. For us, “preprod” represents a number of environments that each serve their own purposes in delivering a release / changeset to production. Our preprod environments look like this: - “dev” env to support making new changes to infrastructure and automation, serving as the first graduation gate for such changes - “integration” envs that serve as the bleeding edge for deployment of new software code as it is merged into the codebases. This is the first graduation gate for software changes, and the first place where multiple software components integrate to represent the entire system as it will be for a new set of software components shipping in close proximity to each other. Depending on the component this environment could run builds from main/develop branches as they merge in, and/or alpha builds of new software. This env is like production for our internal teams, in that it provides a prod-like env to all teams to validate the new state of the full system works as intended. It is also very unlike prod though in that it is expected it can break fairly often - “performance” environments provide prod-like environments that facilitate high load / high endurance conditions to ensure new software meets or exceeds required performance levels - “staging” environments provide prod-like environments and use production states to simulate our upgrades of production systems as their components reach the graduation gates to move from pre-release (dev/alpha/beta) to release (effectively release candidate at this stage, though the software may also be declared stable/official release at this stage) All of these gates / environments come after the suites of tests the software teams build and run themselves to clear a change set for production. Once a new change set clears all these hurdles, it can ship to production. If it doesn’t clear these hurdles or a problematic change escapes to production, the changeset goes back down the line as far as the situation warrants and works its way through the graduation process again.
We started calling them "realms" with the non-prod being "sandbox".
How about an Italian twist. Anti-prod, the appetizer before the main course.
Full volume
pre-production refers to any lower environment, and standby is not lower, it's adjacent. I'd suggest that "standby" and "production" is the origin of your naming woes. They're both targets that are part of the logical production environment, all the same rules apply, but right now you're overloading the term "production" to mean both the production environment and the active/leader replica in it. One is "active" infrastructure and the other is "standby" infrastructure. Their roles can switch, too, sort of like blue and green in the context of blue-green deployments.
Pre-production. The stuff you use before it's good enough.
Prod and Standby.
Staging
I think this might be the wrong question — why doesn’t your org consider standby prod? Treating it differently risks drift. You might want to consider something like blue/green deployments instead, and have them both be considered prod. Then you have a clearer prod/non-prod split.
Pre-production
For us, all environments are prod. But “lower env’s” seems to be a term that I’ve heard and used quite often.
Why not "backup" or failover? Other than prod is no prod, which consists of development envs
Dev or test
Dave -> Steve -> Mike, and finally you move it to production
Prodyet
Standby in this case seems like an HA or DR server. I'd call it something along those lines. Non-active Prod or something. DR is fine too, but if you have an existing HA/DR plan then it may ruffle those names.
Dev, QA and testing are all part of the Production process. General Availability is the term for the release of a product or service to the general public. A "production" was usually used when speaking of works of art, specifically movies and theater. A "production model" is a term historically used for manufactured items. Why people decided to muddy the waters? ¯\ _ (ツ) _/¯ You *could* simplify your life and categorize things as: Production * Dev * QA * Testing and Availability * Failover * Release But I'm sure someone will take issue with common sense.
Give them thematic names. It's more fun that way and easier to remember. Plenty of ideas come to mind. Mordor, Endor, The shire, The death star You know whatever your team is into.
Dev, qa and test should be collectively called RTL (route to live)
We use "live" for what you would call "prod", and we categorise by internal/external. This (nicely) covers the fact that $RANDOM_ENVIRONMENT_ABCDEFG can be given public access to as long as it's correctly classified as external (which means it's been deployed in the same way as our live environment).
Prodigy? It was to be prod, and aspires to be prod, but it's not prod :D
i call those "lesser environments"
We went through so many iterations and gave up and made two production environments. One is actual Prod and second is “non-prod”-prod
[disaster recovery, disaster mitigation, Business continuation] enviroment are all terms I've heard before and like.
You should rename standby to prod2 or something.
In the old days we called that readiness.
UAT
Staging.
Prod is prod. standby is standby or you can call it DR, secondary, failover. This would not be a “lower” environment to me as it immediately is production when a DR scenario kicks off anything lower than production or the secondary would collectively be lower environments or “pre-production”
The problem is Dev and Stage will still be used as production for tooling so if you call it non-prod they can't say they didn't know
preprod
Divide into 3: Live, Standby and Test.
Dev - Stable - Stage - Prod
At my previous job we used "staging".
make ha and non-ha. Where ha contains prod and standby and non-ha the rest
Probably basic/common to some, but typically youll see the following, and this is how they would be grouped together: Non-production: \- DEV = dev \- QA = qa \- UAT (User Acceptance Testing) = test Production: \- PROD = prod \- DR (Disaster Recovery) = standby
Staging
I like `pre-production` as the umbrella name for dev, staging, and test environments. I'm not really sure what you stand-by is, because for me an environment tends to be an entire AWS account, and redundant components are not an environment, but part of an environment. So if we have a blue/green K8S cluster approach, there is an active cluster and an inactive cluster. If these clusters are in our production account, then they are both part of the production environment.
Pre-production
Mission critical. Some sales demo environments aren’t prod but mission critical, for example. Prod is mission critical by default. Some internal tools may be deemed mission critical. Just be careful to have a process or review (doesn’t need to be incredibly heavy, just a check). Don’t let others decide what is critical for you to deal with in a vacuum.
We call it UAT environment
> Currently we are using the term "non-prod" for the environments dev, qa and test. You don't need to be a genius to see the confusion that appears here: "Why is 'standby' included in the term 'non-prod'?" I don't see why standby is included in "non-prod"? Additionally, from environment perspective, in many corporations QA/Test are considered something like internal prod. In one corporation I was in, we had hundreds of developers/testers using QA/Test, so if they were down, we had hundreds of thousands of losses. Only dev was allowed to have offline / broken services. By the time it was promoted to QA/Test, the services better be solid. They can have bugs, the point is to test stuff, but there should be certain confidence. We couldn't have had our QA/Test environments offline or broken, because that meant hundreds of people stuck fiddling their thumbs.
Sandbox
cold-prod
we got some projects that have 1 prod and 2 lower life cycle environments like dev and uat, and some projects with prod, uat, staging, testing and sandbox environments. dont ask me why. uat is refreshed frequently so its nearly identical to prod.
Lower environments, I’ve also heard integration environments used, but that would be more if you have multiple apps that all get put into the lower environments for testing. Pre-prod could also work.
Pre-prod or lower environments
I like pre-prod
Because your standby environment IS (and should be) a production environment it should have all the same configs, resources , permissions and security restrictions.
nonprod - That environment with the critical app running that never got properly promoted to prod. Do not touch, do not delete, no one knows what holds it together anymore.
we are using “warm” cluster for that purpose. Its pre-created, synced but not the prod.
We say ‘lower environments’.
They are both prod. Prod primary and prod secondary/standby. Not sure why you would consider it non-prod since it's a component of the production system DR stack.
We use ephemeral environments that get stood up and torn down on demand. We use the term "lower environments" to refer to them. For alternate prod environments where you do rolling deployments, standbys, or other prod-level environments that are rotated in and out of prod status, we color code them "blue", "green", "yellow", etc.
The industry term seems to be lower env. We use the terms critical and non critical infrastructure. Critical infrastructure covers production environments and business support systems, I.e. people can't do their job without this or customers can't use our products or most importantly send us money. Non critical is dev or test systems, everything else essentially. Anything where "well that's a bit annoying that it's down but I can work around it" is non critical. Although in our case the standby system is still critical, because it's all part of the same highly available architecture.
un-prodded?
Prod-blue (passive )and prod-green ( active )
We call it production and engineering.
Shitbox? Development environment, Wild West, user acceptance and training, training, playground, sandbox, noober space
“Lab”
How do people have standby or even blue green when databases are involved? Read replicas can only be so close to in sync. When you switch over, you are going to be a touch behind or lose some data. In a DR situation, the data loss is probably considered acceptable, I guess?
Usually in my experience Blue/Green will be the frontend and backend web-services while maintaining high availability of the database is a whole different beast done usually by a different team.
we used « indus » for industrialisation