As with others comments I cannot attest to the "standard" however I was involved in the early foundational days for the multiple environments evolution. I was

As with others comments I cannot attest to the "standard" however I was involved in the early foundational days for the multiple environments evolution. I was the first programming hire in 1997 for a small electronic commerce company, being the first hire they had no systems and I was tasked with figuring it all out. Having written and managed in entirety one of the first API payment servers on the internet a problem quickly surfaced, near immediately actually, how do people learn to comprehend what it does without seeing it do it? Since there was nothing to look at, that mysterious 'black box' system when you swipe your payment card, the only solution was to have a 'fake' one that just didn't talk to the card networks. So the word 'fake' was not very well received in the business circles and almost immediately another issue arose - What do people code against to validate their own API client payment calls? Simple, I'll refactor the 'fake' API payment server to process API development test requests also. For those that have lived it and comprehend where this is going one can see the 'fake' payment server quickly becoming its own living and breathing platform to support. This led to the creation of four distinct separate environments all that matched from hardware up through software versioning in a staggered staged rollout window originating around 1999. I labeled the environments as DEV, QA, UAT, and PRD and each one had its own designated critical business flow reasoning. DEV was the environment the internal LAN technical parties tested against and to clarify this was NOT some developers personal system they kept running but was a match of PRD. QA was internal LAN quality assurance for all business test cases that needed stability outside of DEV along with load testing. UAT was external WAN User Acceptance Testing for new customer development as well as existing customers new feature development. PRD was of course external WAN and live production. This approach was tried and true tested leading up to Y2K and greatly alleviated countless PRD issues as I had established a code promotion procedure from Development to DEV, DEV to QA, QA to UAT, and then UAT to PRD. One can see three distinct code pushes before reaching PRD and this significantly increased uptime when such things were just becoming a topic. "Can someone who has been writing software since before the internet remember why we started to do things this way?" Clearly I am "old" as I sit here trying to remember how I remember this. :) Been through, done, and seen some crazy things in the last 30 years but what I'm building now…