Before software is deployed, it has to go through several environments. These typically include development, integration, testing and QA, staging, and production. These steps are meant to refine and test the software before it gets to the final user.

At the final staging environment, the software is tested in an environment that replicates a real production environment, where the testing data must be repeatable and explainable. 

This article will explain the multiple environments software and data go through before being deployed to the end users to access, with a special view on how data is managed in each environment.

Why Have Multiple Environments?

Having multiple environments is crucial, especially if you are working on complex projects requiring refining before the software is finally deployed for your end users. Multiple environments also reduce your chances of having bugs in the final product. At the end of the day, this leads to a stable application, more uptime, and happy customers. 

Software goes through multiple environments before deployment, including; local, development, testing, SIT, staging, and live/production. Let’s look at each of these environments in much more detail. 

Local Environment

A local environment involves using your local machine or servers to run your application instead of the online servers provided by a web hosting service provider.

Your local environment gives you the freedom to do all the customization you need without worrying that the changes will be reflected on the live site. It also gives you the chance to thoroughly test the application/site before pushing it to a repo (and potentially aggravating your coworkers by uploading untested, dangerous code).

Developing Environment

A development environment includes all the tools and processes used to develop the source code of an application or website. In practice, it may be a watered-down, near-replica of the production environment. During development, developers have more freedom to make changes, test new features, and explore (but within reason, as the dev environment may often be shared with others).

The development environment facilitates all the processes involved in creating, testing, debugging, patching, updating, and maintaining software. This is often a shared server where developers can do further tests that they may not have been able to on their local environment.

Again, using a test data management tool makes it easier for developers to have all the test data they need while in the development environment. Otherwise, a developer will be managing the same data, not only on their local machine but wherever the dev environment is hosted. Remember, testing is necessary, but value is added to the company with new features, not when writing tests, so any testing roadblocks should be one of the first to be automated.

System Integration Testing (SIT) Environment

SIT environment refers to a setup where high-level software testing processes are done in order to verify that all the related systems maintain data integrity and can coordinate with other systems in the same environment. The main goal of this environment is to ensure all the subcomponents of a system are properly integrated and work as expected. 

So, this environment essentially validates data on the different parts (sub-components) of a system to confirm that they work well together. The main goal of having the SIT environment is to test the automation of aggregated components of a system and the dependencies between them. 

This environment is ideal for developing complex systems that have multiple components that work together. Some of the popular tests done in the SIT environment include; use case testing, state transition testing, load testing, volume testing, usability testing, graph-based testing, and decision table testing. 

If you are working on a complex system, it is crucial to have an SIT environment in the process to avoid a situation of deploying a system with disintegrated sub-components. Using a test data management tool provides all the test data needed by the various subcomponents of a system in real-time. 

Testing Environments 

“Testing environments” refer to the hardware and software setup for testing an application/website using various end user scenarios. In this stage, the setup should be as close to production as possible and developers have to imagine the different ways their software could be used by the end users, then test them to see how the software behaves. 

Test environments in a microservices world can make managing multiple testing setups a real pain, especially as your application grows to hundreds of services. This is where the test data management system used in development comes in handy—but be sure not to use the same test datasets as the development system. Instead, generate synthetic test data, preferably on-the-fly, to ensure full and varied test coverage.

Staging Environment

A staging environment is a replica of the live website and the last step in the deployment process before changes are implemented on the live site. The staging site enables you to test all the changes made by the developers before deploying them on the live website for the end users. 

The staging environment minimizes the number of bugs on the final product on the live site. That is why some refer to this stage as the Quality Assessment (QA) stage, because its primary role is not to add changes, but rather to ensure the changes made in the previous stages are well implemented and have no significant shortcomings. 

There are two common tests made in the staging environment:

1. The Smoke Test: Used for testing the essential functionality of the software to ensure it executes the intended goals. 
2. User Acceptance Test (UAT). Performed with the customer in mind to evaluate how the software would behave with the end user. 

A staging environment is a great way to present your final product to your clients and give them the ability to test it themselves. This can also be seen as part of the User Acceptance Test because it gives the developer a chance to see how the final consumers use the app and the challenges they may discover along the way. 

The staging environment has limitations, one of them being the inability to test real-world use cases, like how the application will handle the different traffic volumes. For applications that are to be used by the general public on the internet, testing some of these scenarios may not be possible in the staging environment. 

In the past, these aspects had to be tested live in the production environment when real users were actually using the application. This inevitably led to bugs.

These days, due to declarative infrastructure management tools, you can bring up expensive 1:1 production replicas, and remove them at the click of a button. This means production can be perfectly replicated from an infrastructure standpoint. The only question is—what about testing the data?

Due to security and privacy concerns, it’s not always possible to simply replicate the production database. Special care must be taken to mask sensitive data and ensure any remaining data is later deleted. Here again, a test data manager comes to the rescue.

Final Thoughts

There are other environments that could be involved in the development processes beyond the ones we have just discussed. The choice of which environment to include in your process should largely depend on the kind of system you are building and its level of complexity. You can also choose to merge some environments to save costs and time.

For instance, small development teams working on smaller systems may choose to merge the development, testing, and local environments in order to save costs. So, before kicking off the development process, you should first agree on which environments are necessary for the kind of system you are developing. 

Due to the increasingly ephemeral nature of certain environments from the rise of microservices and declarative infrastructure-as-code tools, it is best to look into test data managers, such as Broadcom’s Test Data Manager, to help automate the process and to help find, secure, create, and deliver test data faster.