2012-02-06
Each organization has their own system for the environments used to make sure their IT systems will work in production.
Often the environment setup varies within an organization since different teams has different development methods, organization, processes and needs.
The followin table states some of the names encountered more frequently, and their respecively characteristics.
Bear in mind that the names may vary a lot, and in some organizations switch places.
The rise of container based environment infrastructure and more automation also renders some of these obsolete for those types of organizations.
True DevOps organizations also has a more fluent ownership of environments.
For mainframe systems even more rigid test environments exist since for example date-rolling environments require a lot of coordination to be performed when a lot of different systems depend on the same database and what batchjobs has been run.
Often the same environment changes use over time. It may be for example a Migration Environment that become both fail-over and staging environment after migration is performed - and may be used for large scale performance tests at times.
Sometimes you encounter even more creative, but descriptive names too:
In many teams/organizations a mandated process for environments exist. Any new version of a software should go through (built to, or binaries copied to) a series of environemnts to reach production. Most of the time a fast-track exist for panic patches, but the general idea is to test things in a certain order like:
CI -> Dev -> Test -> Ver -> UAT
Function test -> Program test -> System test -> Integration test
Unit test -> System test -> Acceptance test -> Staging
| Environment name | Purpose | Characteristics | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Hardware capacity (and configuration/CPU core count/bit length) | Component versions | Data requirements | Ownership / Change request process | OS and system change rights | External interfaces | SLA/Alarms/Surveillance degree | Scheduled jobs | Other comments | ||
| Unit test Environment | Run automatic unit tests and system integration in the small (vertical and horizontal) | As fast as possible, but no specific needs. | Latest build | Fast. Memory databases. Constructed test data. | Dev team | Liberal | It depends, generally a minimum | Very limited | Fast test execution for fast feedback of broken code. Often the same server as the build machine. | |
| Production environment (=operational environment) | Providing service to the core business | Full | Latest fully released system versions | Production data | Operations | Locked down to operations alone | All. Full. Data in sync with external production environments. | Full set of monitoring | Scheduled. Executed. | Often redundant environments (with fail-over capacity). Backup routines, proper DB. |
| Test automation environment | Environment to run the automated testing in. Often separate from system test environment and from unit testing environment | As fast as possible, but no specific needs. | It depends. Generally a late version. | It depends | Dev team | It depends | Varies | Low - test automation will tell if system fails | Mostly manual | Often only used for automated system integration testing |
| Performance test environment | Verifying the performance of the system, optimizing performance, long term tests to find resource leakage | It depends. For many types of tests a production equivalent environment is desirable | It depends | Most often full production like data volumes. Sometimes not even anonymized unless nessesary. | Dev team / Operations | For exploratory performance optimization: Liberal. For performance verification: as production like as possible | Relevant ones should be at hand | Low. System is monotored during load | Sometimes executed | |
| Education environment | Hold educations and presentations of new functionality or for new users | As fast as possible, but no specific needs. | Stable build | Realistic test data, possibly a sub-set of production data. | Business team | Manual | ||||
| Build environment | Mechanisms for resolving code dependencies, building the application binaries and deploying application files to other environments. Possibly code sync and merges (depending on the version management system for code). | As fast as possible, but no specific needs. | Absolute latest | Configuration data, user data and meta data for deploy usage, and possibly for unit testing usage | Dev team | It depends | Minimum | Monitored in CI environments | No | |
| Migration environment | Environment to develop, trial run and test data migrations in | As fast as possible, but no specific needs. | Late version | Full copy of production data. Unrestricted. | Dev team | Liberal | All relevant integrations | Rare | ||
| Production verification environment | New versions of applications are smoke tested by Operations in this environment. Error analysis for incidents in productions are performed in this environment. Patch releases are tested in this environment. | Often tested on hardware that mirrors hardware used in the production environment and configuration settings reflecting the ones in production. | Latest stable, expected for production. | It depends. Often a copy of production data. | Dev team / Operations | Locked down for any but representatives from Dev Team and from Operations | It depends. It's used with caution since a copy of production data often is used. | Manual | Often the same as staging environment | |
| Staging environment (Pre-production environment) | Used to assemble, test and review newer versions before it is moved into production. | Often tested on hardware that mirrors hardware used in the production environment and configuration settings reflecting the ones in production. | Latest stable, expected for production. | It depends. Often a copy of production data. | Dev team / Operations | Locked down for any but representatives from Dev Team and from Operations | It depends. It's used with caution since a copy of production data often is used. | Manual | Often the same as Production verification | |
| Fail-over environment | Some systems has passive waiting redundant systems ready to take over as production environment if the ordinary production environment should go down. Sometimes the same problem is solved by redundant servers instead. | Full copy of production environment. | Same as in the production environment | Possibly with replicated databases or synchronous write to production and fail-over environments. | Operation | Locked down like the production environment | Connection to external systems should be possible with minimum time spill. | Full monitoring | Often scheduled and executed. | In multi-tier architecture these generally are redundant |
| System test environment | An environment incorporating the full system, so the complete system can be tested (possibly with system integrations to relevant external systems) with production like component versions and settings. | It depends | Deployed system version is a balance of having as recent build as possible and having a reasonable stable build. | It depends. Could contain any kind of test data. | Dev team | It depends. Generally quite liberal. | Relevant ones. Sometimes mocks/fakes. | Some batch jobs executed by schedule. Most manually. | Mirroring the production environment in relevant aspects (what is considered relevant varies depending on the tests performed). | |
| Development environment (Sandbox) | An environment that should be quick and easy to do changes to, since development is carried out on it | PC | Working area for latest | Small data set , often of constructed data. | Developer | Full user rights | Stubs and mocks | Manual | ||
| Development test environment | An environment where frequent deploys of freshly built code is delivered so that testing of latest can be performed (by developers or others). | As fast as possible, but no specific needs. | Most often contains latest build. Sometimes the latest stable build (that passes the unit tests). | Small data set , often of constructed data. | Dev team | Liberal | Rare | Manual | Often liberal user rights to enable elaboration and defect mitigations. Sometimes frequent “system unavailable” due to new builds/deploys | |
| Acceptance test environment | End user testing in a production like environment to assess if the system is ready for production. | It depends | Late, quite stable | Production data. Possibly production like data. | Dev team / Operations / Business | Locked down, with few exceptions | Fairly complete set, with caution since production like data is used. | Most scheduled jobs executing. Some manually. | Production like data, stable system version, full configuration, all system integrations but to test environments | |
| Editorial environment | Sometimes new/altered content of a system needs to be taken care of on a massive scale, which might call for a special editorial environment for content to shorten lead time from code to production. | As fast as possible, but no specific needs. | A stable version, with stable data model and schema. | When used this environment often is connected to a separate semi-production database | Business team | Irrelevant | Only relevant ones | |||
| Continuous Integration environment | A build server that make controled builds upon check-in of code and often run unit tests on the built software | As fast as possible, but no specific needs. | Latest | Small data set , often of constructed data. | Dev team unless enterprise solution | Liberal | None or next to none | No | ||
| System integration environment | An environment with component versions making interface versions (and test data) in sync with external systems so that system integration tests can be carried out with them. | It depends | Late, stable. | Data in sync with external system, often meaning a recent copy of production data. | Dev team / Operations | It depends | The ones currently being used in testing connected to external test enabled systems | Mostly manual | ||
| Admin environment (from Jennys service description) | CI build target, or for developer testing of side effects Used by business users to enter data or media | It depends | It depends | It depends | Operations | It depends | It depends | Same as Editorial Environment and/or Development test environment? | ||