This is really talking about different types of software environments and how they are used during the various phases of software development, integration and support.
Environments are the touch points between your system and other teams operating on their cycles and timelines. They are also control points where controls is incrementally applied or where access is restricted based on the sensitivity of the data in that environment and its distance from production or development.
System Complexity
The number of system environments (sandboxes) required depends on your system complexity, your tolerance for defects, your level of Ops and DevOps automation and the needs of other systems that yours integrates with. This diagram shows a couple application components that integrate with 4 different partner teams and 3 data stores. Each partner team has its own release cycle and testing needs. We aim for loose testing coupling but that is often impossible either because of the heavy investment in mock services or because of the complexity of the interactions or the data.
Future Code Pipeline
Different companies have different names for their various stages in their pipeline. Partner teams testing against a future release will integrate with environments on this pipeline.
The environments in white represent highly accessible environments with low stability and low risk. The yellow environments represent more stable environments with significantly less manual access than the earlier environments. The red environments represent highly controlled "production" or "production like" environments that are treated as if they contain sensitive information.
CI represents the build and unit test environment. It really isn't a true environment at all and is solely used for code base health and white box testing.
Some companies have Mock Integration environment that can be used to run basic automation, integration or smoke tests. Partner systems are mocked so that this environment is not at the mercy of partner deployments and stability. Mock Integration environments tend to get developed after a team has had trouble running the nightly automation tied some other team environment's stability issues. Dev Integration represents the first environment where your system integrates with partner systems. Tests here should run nightly or several times a week. Basic automation, functional or smoke tests, run in this environment. Stability depends on the integration points . Some companies have a partner integration environment that represents the next release but is more stable that Dev Integration.
QA (yours) is the environment used by true testers doing either manual tests or using various types of automation. This environment is owned by "your" QA team. It integrates with QA environments provided by other teams. Builds here usually happen several times a week.
User Acceptance Test environments are the place end users, product owners and other interested parties run their tests. Deployments are "on demand" of the users in this environment. Agile doesn't really talk about or support this within the sprint concept. This is normally the environment used to get "external sign-off".
Prod is production. You knew that. Prod Mirror usually mirrors the current code in production. It is used for production triage where testers and developers are , rightfully, not allowed access to the production system. This is sometimes called names like Production Triage.
Partner on Production Path.
Partner teams need a place to test their future code against your current release. They use this so that they can release without being locked into your release cycle. These really depend on integration complexity and how different the release cycles are. Note that these environments use the "current" data model and schema while the new development environments use a "future" data model and schema.
Partner Integration is your integration environment that is consumed/used by the partner integration teams. This where they run functional or integration tests.
Partner QA is the environment foreign QA test teams integrate with. Their Internal QA environment communicates with your Partner QA environment. Some teams will forgo this and use the Prod Mirror environment mentioned above.
Tradeoffs
The number of environments can clearly be reduced by software teams that don't think they need it. It can also be expanded to include branches, security testing or for other needs. The decision is a tradeoff between operational complexity and conflicting needs with respect to the data available, environmental SLA and the version of the code to be deployed.
My last three major enterprise customers all had between 5 and 7 environments. This doubled if the same application was deployed in different data centers like cloud and on-prem.
Highly automated companies, running in the cloud, have the added option of tearing down environments while they are not being used. Good examples might be various QA environments or Performance testing environments.
