Test environments

Today let's talk about lab environments — what are they for?

Testing in prod is fun and effective, of course, but not all users want to work as testers. That's why people use lab environments to break in new functionality and gain confidence that the old functionality hasn't broken, as so often happens.

We can highlight popular environments such as

• dev — all the changes from feature branches are merged here and tested on a test dataset
• stage (also known as staging) — here testing is done in an environment as close to prod as possible, ideally even on a copy of the production database
• production — and here you test on users whatever didn't get caught at the earlier stages =)

In addition, individual branches (feature branch) where only a single feature has been added are often tested.

For URLs, you can stick to a scheme like this:

• dev: dev.mycompany.com
• stage: stage.mycompany.com
• prod: mycompany.com
• A single feature: feat-123.mycompany.com

✔️ This way testers know exactly what they're testing and in which environment

Of course, creating and updating environments should be automated, especially when it comes to dynamic feature environments — you're not going to manually create everything for each task. There are different approaches to automation depending on the platform you use for deployment. The easiest way to implement this is in a containerized environment (docker/kubernetes).