In most DevOps settings you’ll find that there are multiple environments in the pipeline. You might have conditions that change the environment based on which branch was merged or when a branch is tagged for release. There are a number of reasons you want to have more than just a production environment, the biggest reason being testing.

Keep in mind that every organization does things slightly different. You might see more environments than the ones covered here or they might not have the same names. The important part is to know what purpose each environment serves. They will have different access levels to services and varying public side access.

Environments you might see

Development

The development environment is like a step up from your local environment. It’s where you can deploy little changes to see if they work somewhere other than locally. Your code doesn’t have to work perfectly to deploy to this environment. You might need to test how a new endpoint integrates with your application and you need to get around CORS issues.

You might work on a large feature with other developers in this environment when you all are testing approaches to a feature or bug. It’s like an advanced sandbox that gives you slightly more access to other services than your local environment might allow.

Staging

In most cases, this is where your code goes before it gets shipped to production. You should have gotten code reviews and tried some individual testing to make sure that all of the functionality is there and there haven’t been any regressions. The changes that get deployed to staging should be working with little to no issues.

This is where your integration tests run and any third party services get the secrets they need. Some companies will set up completely separate services for staging because this is the environment closest to the production environment that we can get.

Once you have your code on staging, you can verify that all of the data is loading like you expect and that you are getting the correct responses from services. This is a good place to run chaos engineering tests to check how sturdy your system is with the resources it has available. The available resources the staging server has is usually lower than what production has so keep that in mind for performance testing.

#devops #environment #continuous-integration #software-development #coding #code-quality #productivity #continuous-delivery