What is an environment?

An environment refers to a complete set of hardware and software components that are utilized to build, deploy and execute a software product. This includes, but is not limited to, physical or virtual machines, database systems, cloud services and offers, internal and external services, development tools (e.g.: IDE) and other tools used by the development team.

Why do we need separate environments?

Having multiple and separate environments enables teams involved into development lifecycle to work on parallel activities. With multiple environments developers can implement new features or fix issues while testers can validate their previous changes independently.

Multiple environments also help reducing or eliminating downtime and saves the company from loss of revenue. Only well tested changes can reach Production, which means less end users facing issues after the product or solution is delivered. This helps building the trust and keeping the customer satisfied on the long term.

Maintaining multiple environments provides better security. With proper access management, integrity of Production data can be protected. This setup also prevents sensitive information from being made available to people who shouldn't have access to it.

Leveraging on multiple environments promotes innovation. With multiple environments, team is free to experiment on environments designated for this.

Last, but not least, multiple environments support Continuous Integration and Continuous Delivery best practices to reduce time-to-market.

Environments @ OSB

Development (DEV)

The dDevelopment environment is used to build your application. This is where developers complete the majority of their work. Typically, the Development environment is set up on local computers, and work is facilitated by a Git repository. Requirements for Development environments, like which tools have to be installed, have to be documented per project. Before committing any changes, all tests which can be executed on the development environment, e.g. unit tests, have to be executed, and committing is prohibited if there is any failed test case.

Code changes must be peer-reviewed by at least one other team member before they can be merged into the branch which will be deployed into the Test environment.

Once the team has a version ready to release, a new version of the application is deployed to the Test environment following CI / CD best practices.

Test (TEST)

Test environment is where tests are executed to ensure the functionality and usability of each new feature added to a project. These tests include integration tests, end-to-end tests and manual tests. Testing environments usually requires less resources than production.

In order for integration tests to be meaningfull, the ideal case is to have a full end-to-end environment (incl. all 3rd-party systems and solutions) mimicking the Production setup, so that integration issues are identified and tackled as early as possible in the development lifecycle.

A new version of the solution/application can only be deployed to test environment by means of a package following CI / CD best practices.

Pre-production (Pre-PROD)

Pre-production environment is an environment that attempts to match Production as closely as possible in terms of resources used, including hardware and architecture. In order to keep it as Production-like as possible in terms of data quality and volume, environment should be regularly updated - and at least before each testing campaign - with production data. To protect production data and not expose confidential information for unauthorized persons, environment refresh process should include data obfuscation for sensitive data. In this environment customers can verify that the new features fully meet their requirements. Ideally the same set of manual tests are executed than in test environment and business can involve their key users into the validation process (User Acceptance Tests, or UAT).

Beside UAT conducted by key users, this environment may also be used for performance & load testing, as it (in principle) has similar infrastructure configuration (i.e. comparable performances) and same amount of data than Production.

A new version of the solution/application can be delivered into Pre-production only when customer has agreed to it and that all previous validation steps are successful. Package deployed to Pre-production must be the same as the one deployed into the Test environment, notwithstanding configuration differences (e.g. connection strings...).

New version can be deployed only from a package following CI / CD best practices.

Production (PROD)

Production is the final environment, where the work is made publicly available. Only thoroughly tested code should end up in Production. The infrastructure of the Production environment must be able to handle large amount of traffic, cyber-attacks, hardware failures, etc.

A new version of the solution/application can be delivered into Production only when customer completed the acceptance tests and gave its final approval. Deployment might happen outside of working hours, during a pre-defined outage window, in case of business-critical solutions. Deployment strategy must be agreed with the customer upfront.

New version can be deployed only from a package following CI / CD best practices.

When a new version is delivered to Production package must include all required deliverables, including at least test exit reports, technical and functional specifications. List of deliverables might vary customer-by-customer based on contractual agreement. When a deliverable is not required by the customer proof of exemption must be provided.