Question

When developing a web application for others, multiple environments for testing are a good idea. However, different development teams have different definitions for the meaning of each environment.

Currently, I like to keep it simple, and have a development environment (my local machine), a staging environment (someone before I deploy my app to the world), and then to production. Although there may be value in more environments, I’m going to be sticking with these three for now.

My main question is:

What properties would be appropriate
when defining a staging environment?

However, here are some related questions:

• Does the web server have to be on a separate physical machine than the database?
• Does the database have to be exactly identical to the production database?
• Can the staging environment go down for maintenance?
• Can the staging environment be used to test out new features (ie. a beta env)?

Answer 1

I’d suggest that your staging environment resembles your production environment as closely as possible.

If you use separate servers for the DB and the Web Server, try to keep that in staging as well, if you use a load balancer, try to configure it for staging as well, etc.

In my experience, however, this was not the case, and our staging environment was always less powerful in terms of hardware than the production environment. The problem with this is that you can’t test every feature and be sure production will work the same.

As for your other questions:

• Staging can usually go down when needed, you can have a more flexible schedule for that, to install new versions.
• We had cases where we installed more than one instance of the application on staging. One resembling the version in production and another with new features for the client to test.