What is the definition of a staging envronment when developing web applications?

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.

Answer 2

To me the implication in "staging" is that you're on the verge of deploying to production so you need an environment that as closely mimics the production environment as possible to minimize any problems that may crop up as a direct result of different environments. For example the development and testing environments may have certain utilities the production environment doesn't, or the production environment may have stricter permissions and authentication that could cause issues with your app.

As such, an ideal staging environment is one that is an exact clone of the production environment (albeit without public access). If you're using virtualized servers this should be near trivial. If not, then the environment should as closely mimic the production environment as possible (the app should be deployed to the same path, permissions should be identical, configuration files should be copies of production, et cetera). To answer your questions:

• Does the web server have to be on a separate physical machine than the database? If that is how it is in production.
• Does the database have to be exactly identical to the production database? Exact structure, it can be filled with dummy values.
• Can the staging environment go down for maintenance? Yes.
• Can the staging environment be used to test out new features (ie. a beta env)? No, that's what I would use a development or testing environment for. Staging should be for features that will immediately go into production (i.e. a "release candidate" environment).

Answer 3

"What properties would be appropriate when defining a staging environment?"

Technology stack must be the same. Indeed, you should be able to simply clone staging to rebuild production.

"Does the web server have to be on a separate physical machine than the database?"

For staging? Not necessarily. If your configuration management is rock solid then you'll have all the necessary config. parameters in staging and correctly fix them when moving to production.

If your CM is not rock solid, you'll need staging to have the same physical architecture as production so you can make configuration changes.

"Does the database have to be exactly identical to the production database?"

Depends on the use case. If you're upgrading the database, then they can't be identical.

If you're not upgrading the database, they will be identical.

"Can the staging environment go down for maintenance?"

Why not?

"Can the staging environment be used to test out new features (ie. a beta env)?"

It has to be used for this. How else do you do an upgrade?