this was pulled from a good article outlining the application development infrastructure. I often reference this to remind me what each software development environment is responsible for.
.......
Application development, deployment, and hosting in a large IT organization often involve separate development teams working in parallel on numerous applications for deployment to a shared hosting environment. This kind of dynamic environment demands an orderly process for promotion of application elements from the initial development stages to a highly stable and tightly managed production environment.
The ways in which an application is exercised at the various stages of its life cycle and deployment schedule require several different parallel instantiations of the application. These instantiations or environments go by many names in different organizations, but the following names are commonly used:
| • | The development environment is where unit level development is done. Therefore, software and data structures tend to be volatile in this environment. It is here that the developer is at liberty to modify the application module under development and its test environment to suit unit level development needs. In this environment, developers typically work solely on development workstations where they often have full administrative rights. The development environment is a “sandbox” environment where developers are free to use various application infrastructure elements without the constraints, for instance, of the security that will exist in other environments. This allows developers to focus on building application logic and learning how best to use the various application infrastructure elements available without limitations imposed by the environment. |
| • | The integration environment is where application units (software modules, data schemas, and data content) are first assembled and then tested as an integrated suite. This environment is also volatile but is much less so than the development environment. The objective here is to force coherence among the independently developed modules or schemas. This is typically an environment where developers do not have all the permissions that they had in the development environment. As a result, this is often the first time that issues such as installation, configuration, and security requirements for the eventual target infrastructure are addressed. |
| • | The test environment is where a “release candidate” grade version of the application is run through testing exercises. It is as tightly controlled as the production environment and also substantially less volatile than integration. The objective here is to assume relative stability of the integrated application and test its stability, correctness, and performance. This environment is usually off limits to developers. Deployment and updates to applications in this environment are controlled by the test team and are often done by a member of the build or infrastructure teams. |
| • | The staging environment is where an application resides after it has been fully tested in the test environment. It provides a convenient location from which to deploy to the final production environment. Because the staging environment is often used to perform final tests and checks on application functionality, it should resemble the production environment as closely as possible. For example, the staging environment should not only have the same operating systems and applications installed as the production computers, but it should also have a similar network topology (which the testing environment might not have). Usually, the staging network environment mimics the production environment in all respects except that it is a scaled down version (for example, it may have fewer cluster members or fewer processors than your production servers). |
| • | The production environment is where the application is actually used by the organization; it is the least volatile and most tightly controlled |