Test environments

Today, let's talk about test environments and why they are needed.

Testing in production can be fun and effective, but not all users want to be testers. Therefore, test environments are used to roll out new functionality and ensure that old functionality hasn't broken, as often happens.

We can highlight the following popular environments:

• dev: This is where all changes from feature branches are merged and tested on a test dataset.
• stage (also known as staging): Here, testing is done in an environment as close to production as possible, ideally even on a copy of the production database.
• production: This is where users test what wasn't caught in earlier stages. =)

Additionally, separate branches (feature branches) are often tested where only one specific feature has been added.

For URLs, you can adhere to the following scheme:

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

✔️ This way, testers know exactly what they are testing and in which environment.

Of course, the creation and updating of environments should be automated, especially when it comes to dynamic feature environments, as you wouldn't want to manually create everything for each task. Different approaches exist for automation depending on the platform you use for deployment. This is easiest to implement in a containerized environment (Docker/Kubernetes).