An Environment for Every Season

Video Presentation

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 touchpoints between your system and other teams operating on their cycles and timelines. They configuration tuning points where control 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 of the data.

Future Code Pipeline - vNext

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 codebase health and white box testing.  

Some companies have a 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 to 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, are 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 than 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. These are sometimes called names like Production Triage.

Partner testing against current Production Versions 

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 is 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's QA environment.  Some teams will forgo this and use the Prod Mirror environment mentioned above.


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 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 datacenters 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.


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs