My preferred development release cycles list of environments

Many companies can't afford this, so there are many variations, but when I have been fortunate enough to work for organizations (or I had the money myself) to have the ideal resources in place, this it what it looks like for me to ensure 99.999% or better up times each year...

In a bare bones situations, some companies have no choice but to do all of their development on their production environment.

You do what you gotta do, but that approach is rife with obvious problems. And yet, in the past 10 years, I have been seeing a disturbing increase in the number of companies doing exactly this, even when they have millions of dollars at their disposal! These are usually startups created and run by developers, who have no real concept of reliable up times.

I come from a world of service level agreeements (SLAs) where I have had to build and support environments in which every second of down time can be thousands, hundreds of thousands, or even millions of dollars in lost revenue or equivalent in productivity. So anything less than "5 9's", or "6 9s" up time (99.999% uptime <= 5.26 minutes downtime, or 99.9999% <= 31.56 seconds downtime).

The more of these environments and process methodologies that can be properly implemented, the more likely higher quality releases and up times can be implemented and maintained.

DEV0 = the developer's own (usually local but can be remote) development environment and sandbox that is "localhost".

DEV1 = (dirty) shared development environment (usually servers/cloud) that are pushed for multiple developers to be able to test their code in a server setting that isn't "localhost".

TST1 = cleaner (often reset) shared testing environment that the developers can test before sending to QA. This environment is often wiped and reset to avoid cruft that may be left in DEV0 or DEV1, to make sure it is actually working as desired before sending to QA. This reduces "bounce back" from QA team to developers.

QA1 = Quality Assurance testing team (and automated tools) environment. Developers send their running code to this environment for testing by third-parties (never trust developers as the only testers of their code). If any issues are found, this is reported and the code is "bounced back" to the responsible developers, or a junior "bug fixer" developer to resolve and resubmit to QA.

RND1 = Research & Development R&D. This is a freeform sandbox for use by an individual or group of people to "try out" different ideas. This is often a completely wiped and reset environment, and will have many different things on it. It is often "pre development" to try out other products or code bases to consider if want to add to the scope of future projects. It might be a basica proof of concept environment that is not part of the normal release cycle, but can use for demonstration to stakeholders to consider using it in the future. It is often also used for load testing benchmarking and capacity planning evaluation. I personally live a lot in this environment.

DMO1 = Demonstration environment. This is where code that has passed QA1 goes for either performing a controlled demo (speaker screenshares and shows user very limited and controlled use cases (To avoid known bugs) to get buy-in that the development is going in the right direction, and feedback for any changes that might need to be put into the near-term roadmap or next sprint cycle. This can also be used for more free-form hands-on use for early yay/nay by less senior stakeholders to "kick the tires" and see if they are happy with what is there or if any tweaks needed before it goes to UAT.

UAT1 = User Acceptance Testing. This is the final testing and approval by stakeholders, especially senior ones. This is the last chance for stakeholders to yay/nay if it should go to production or if it needs changes in the roadmap or next sprint cycle before going to production.

STG1 = Staging. Aka QA2. This is the final chance to catch any mistakes, typos, etc. This is usually checked by the QA2 (or higher) team (and automated tools) It is also a final chance for full load testing for capacitance estimates. Basically, all of the final sanity checks before going to production live public environment. This is the last chance to prevent something embarrassing going public. The hardware and software is as close to identical as the production environment to catch any subtle compatibility issues as well.
PRD1 = The final production public environment.