Understanding environments
Even if you are new to software development, you may have heard about running your code in a development environment versus a production environment. You may have even deployed something you have written somewhere like Heroku or Netlify, or in GitHub pages — which is running your application in a production environment.
What are these environments and why do we care as developers?
An environment is just a system or configured set of resources on which your code executes, and from which it is accessed by users.
In this article, I will focus on four general types of environments — development, test, staging, and production — named for their purpose. I will give a short explanation of each and how they are used.
Development
The development environment is where you develop and test your code, generally on your laptop (although you may develop your code on a remote system in some cases). It is where you run your code editor (like VS Code), and where you run and test your application locally (using localhost for web applications).
Each developer on a team has their own development environment, and each developer is responsible for making sure that their development environment is in sync with the appropriate source code repository.
Test
There are often multiple test environments that are used to test different configurations or releases of an application. A test environment will be used by quality assurance (QA) engineers and developers to run automated and manual tests on application code before changes are signed off as complete and ready for production.
Test environments are also a crucial part of integration testing, to make sure code changes to one part of the application by one developer work with changes made in other parts of the application by other developers.
Test environments are the gatekeeper to production. It is a common practice to use a Continuous Integration (CI) pipeline that deploys the application code to a test environment and runs automated tests before it is released to production.
Staging
A staging environment is another type of test environment, but some of our customers and business partners have access to this environment so they can run their own testing. Partners and customers run their own tests to make sure any changes made will not break their specific use cases, and because they often use their own proprietary data in the testing, to make sure the changes work with their data.
Because our customers have access to a staging environment, we treat it a lot like a production environment — carefully. After code “passes” in the test environment, it is released to the staging environment, and our special partners are given some period of time to run their own tests and report any issues.
Production
When our code is running in a production environment, our end users are accessing our application. A production environment also stores customer data and our production business data. You can probably imagine that this makes it very risky to test in a production environment. It is important to be VERY CAREFUL running any type of testing in a production environment because of concerns about security, stability, and availability of the application.
Harming a production environment can destroy an entire business (which is why enterprise businesses spend a lot of money on high availability).
So, should you test in a production environment? Yes! But the focus of testing is often different in production, and it has to be done in different ways to maintain the carefully controlled configurations in production.
Read more about testing in production in this great article by Ann Marie Fred on opensource.com.
