How Do I Segregate Environments (Testing, Development, Staging, Production, and more)

Each development environment has its own unique purpose. Different organizations have different policies and use cases for environments, but below are the most common ones in a typical app development process:

This article gives an overview of each of these environment types before going into four best practices on how the segregation of environments should be done correctly. Towards the end, we’ll propose an excellent solution on how to create these environments more efficiently. 

Table of Contents

1. Overview: The Environments You Need

2. How to Segregate Environments Correctly

a. Create an Infrastructure as Code Environment 

b. Create Data Anonymization Pipelines

c. Create Automatic Processes

d. Test Third-Party Services & Microservices

3. The Easiest Way to Create All these Environments - Bunnyshell

A development environment allows developers to write code and make changes or updates without breaking anything in a live environment. New features and updates can be tried and your end users aren’t affected. This environment is great in reducing potential errors and maintaining a streamlined workflow. Additionally, at this stage, a lot of preliminary testing happens before moving on to the testing environment.

You know that a test environment is a setup where software undergoes a series of experimental tests. These environments allow you to test individual components of your app, eliminate bugs, provide accurate feedback about the quality and behavior of the app, and encourage improvement and innovation, among others. 

The staging environment is an exact replica of your production environment. It allows you to extensively test changes the dev team made to ensure they work as intended, as well as discover coding or data quality issues that wouldn’t be possible to spot in earlier test environments before moving to production. 

The production environment is the stage where all apps, software, or product are live for their intended use and its users. Any bugs, issues, or versions are tested and fixed prior to this stage, so the product or update should work perfectly. The production environment contains only the final version of the product or app in order to avoid any confusion or security vulnerabilities. This type of infrastructure (development, testing, staging) allows teams to ensure high-quality products for their users, while encouraging fast innovation and improvements.

Source

You probably already know that you should never mix testing and production environments. Since there’s a lot of debugging and testing that occurs in development, this can lead to unwanted downtime, production data getting into the wrong hands or intermingled with test data, or an incorrect program can damage a server’s CPU cores or memory, among other reasons. 

One wrong move can adversely affect your production environment, further affecting live users and their mission-critical data, especially if you deal with sensitive and private data (ID, client,  health, or financial information). You must ensure that development and testing of any kind take place in completely segregated environments. Read on to find out how to do so correctly.  

You can create a template using an Infrastructure as Code (IaC) tool and instantiate multiple copies with different resource types.

The solution: Use Terraform to describe your environment dependencies.

As your project grows in size or complexity, Terraform offers advanced features that allow you to describe your environment dependencies and simplify how you provision infrastructure in the cloud to manage it in a versionable manner.

Depending on your project needs, you may be thinking of extending the infrastructure across multiple geographical areas or adopting a multi-cloud strategy. If this is the case, you’ll need to configure multiple environments with your infrastructure as code tool. Terraform allows you to do so in many ways. Below are two ways to create multiple environments, along with their pros and cons:

1. Separated directories

Source

Pros:

Cons:

2. Workspaces

Source 

Pros:

Cons:

Also, multiple workspaces are a good idea when you want to test or deploy a modified version of the main infrastructure, so you don’t have to create a separate project and set up authentication keys again. However, these workspaces don’t address the application code deployment, they only track the application infrastructure dependencies. Therefore, multiple workspaces using only an infrastructure as code tool, are not a complete solution for creating multiple environments for staging and production. 

The way you choose to use Terraform to manage multiple environments depends on your project expectations. You may choose to use a different solution altogether.

Data anonymization protects confidential or private information by encoding or erasing identifiers that connect individuals to stored data. In this same way, devs can create data anonymization pipelines to safely use data from production environments to staging and testing environments. 

To enhance velocity in both development and QA teams, the code written by developers should be as bug-free as possible. To do so, developers need to have their database data or assets resemble as much as possible with the production data. This data also makes teams confident that each release will remain stable. You can either replicate a subset or the entire production database into a staging environment. However, it introduces challenges when trying to prevent customer details from leaking into the dataset.

To combat this, a dev might write a pipeline to define specific anonymization transformations per column and table. This process requires that the dev knows the following things: 

Your team must ensure these factors are properly managed to ensure customer privacy isn’t compromised.

You can create automatic processes to maintain all of your stage and testing environments up-to-date with the latest releases. Use CI/CD tools with webhooks to update environments to the latest versions. You can do so when a merge request occurs in your repository, or a new image is available in your docker image registry.

GitLab is an amazing platform for automating processes, allowing you to track issues, maintain Wikis, host packages and registries, and set up CI/CD pipelines, among others. Find out exactly how to build a CD pipeline with GitLab in this tutorial. Once you automate the deployment chain, you’ll be able to share code changes with any stakeholders, and development cycles may become shorter as less time will be required to gather feedback to deploy any code changes.  

You must always monitor key parts of your infrastructure to ensure things keep working. Your apps or services will likely use third-party APIs (ones that you don’t control and ones that you do). These third-party services are a part of your application, so you’ll want to monitor them. Specifically, you’ll want to continuously monitor and test the ones you don’t control or don’t  have access to.

* Services you don’t control can include: payment gateways such as PayPal, Braintree, and Stripe, or customer success tools such as Zendesk or Intercom.

* Services you do control can include the storage backend or notification service for your app. 

In a mock, you record the result of the API, manually validate that it says what you’d expect, and then run the test against the saved mock during your build. However, issues can occur with mocks. Therefore, it’s vital you make them a part of your infrastructure monitoring. 

On the other hand, your app or service may rely on other third-party services or microservices that fall under the general umbrella of code that you do have access to (but maybe aren’t directly working on). In this case, you’ll want to avoid live testing and instead set up integration tests, so you’re a part of these tests in some way each time another version of the service is built and allow testers to make changes to their environment deployment by mimicking third-party services. You can do so by:

Bunnyshell is the solution to all your environment needs. Not only can you automate any (of the above) processes with Environment as a Service (EaaS), but you can automate environment creation. EaaS facilitates fast and reliable team collaboration and feedback on your latest environment code changes and at various points of the process so you can confidently move to production. You’ll also be using a Continuous Delivery (CD) pipeline. Furthermore, you’ll have complete flexibility in making any future changes to your app.

Segregating environments got you down? Don’t worry; you learned about four best practices to correctly segregate them and found an excellent EaaS solution to more efficiently create your testing, development, staging, and production environments. Bookmark this article so you can find it in the future when you need to revisit it. So what are you waiting for?