Question

I know we should have at least 3 different environments while developing a solution:

  • Development: The programmers are free to change and push changes any time in order to quickly test their code and integrate with other changes, without the fear of breaking anything - this is connected to the TEST databases and services;
  • UAT: Should be treated with reverence by the developers, as it should contain a "as good as possible" copy of the production environment regarding hardware, with the difference being that this environment is connected to UAT databases with an editable copy of production data - it's used both by the Q&A team and the users to validate changes that'll go to production
  • Production: The real deal.

I've looked into this question on SoftwareEngineering, and this question on ServerFault, and they seem to differ on what's the meaning of the Staging Environment. Also, Wikipedia page about the subject states that:

The primary use of a staging environment is to test all installation/configuration/migration scripts and procedures, before they are applied to production environment. This ensures that all major and minor upgrades to the production environment will be completed reliably without errors, in minimum time.

For me, Staging equals UAT, where you must test the application and deployment procedures before pushing to the real world. So, we push the package with the changes to UAT the same way we push to production, fully automated and with all the ceremony we should have with the production environment.

That being said, what's the proper difference between an UAT environment and a Staging environment ?

--

EDIT: Just to be clear, I'm thinking in terms of a Web Application, be it an internet website or an intranet website. No "forms" app or mobile app.

Was it helpful?

Solution

The difference is the data.

A UAT environment is set up for "user acceptance" of new functionality. In order to test that functionality, QA or stakeholders may set up user profiles a particular way in order to exercise particular features, or may set up mock products or configurations to check them all out.

A staging environment is often set up with a copy of production data, sometimes anonymized. Some corporations regularly "refresh" their staging database from a production snapshot. The primary focus is to ensure that the application will work in production the same way it worked in UAT. Instead of setting up data anew, testers will search the database for profiles and products that match an essential set of test cases. Often the "real" data have quirks in them that give rise to unexpected edge cases that were missed during UAT. Also, any data migration testing would need to take place in the staging environment.

OTHER TIPS

Use of these different environments really, really depends on your needs. From your comment that "staging == UAT", it sounds very much as if you have a very small application with no QA team, and only a couple of developers.

Larger application environments might have an integration test environment, as well as a QA environment, the former where developers run their integration tests and the latter where the QA team run their tests. There might be a training environment which has stock data that is restored before each training session. The staging environment would be under control of the operations team, to ensure that roll-outs occur properly. The user-acceptance-test (UAT) environment would be used by the customer team. There might also be a production-snapshot environment for reproducing customer issues.

My point is to beware the single viewpoint when determining the environments you need.

| Environment | Software version  | Way of usage of software |
 ------------- ------------------- --------------------------
| UAT         | New               | Same as production       |
| Staging     | New or production | New for this version     |

Definition of usage is very broad here and might include all kinds of things ranging from some change of configuration done by end users to costly infrastructure feature not available on UAT environment. Importantly version of software product on staging can be either new or current one but always one which had passed acceptance already.

In other words:

  • UAT exists to prove that new version of software product would work if used in the same way as how current version is used.
  • Staging exists to prove that new way of software product usage with some accepted version of software product would work in the same way as how current version of software product is used now.

Note: as it was depicted in the question itself there are different understandings of "Staging environment" and one used in your company/environment might be different.

UAT stands for "User Acceptance Testing" and is the environment in which user acceptance testing is performed. Note the emphasis on user - your QA testing is different, UAT is a chance for actual users (or at least your training team, sales, support staff etc...) to try out new features and evaluate the software before it is deployed to their production systems.

What this means exactly will depend on your processes:

  • UAT (the environment) might be "level" with production, and is essentially a sandbox for users to try new features with.
  • UAT (the environment) might be "ahead" of production, so that new features are not deployed to production until they have been evaluated. (I'm not keen on this approach as it necessarily means you have longer lead times).
  • It you have a multi-tenant system you might not even need a UAT environment, instead you could choose to have users evaluate new features in production systems by making use of feature flags.

In terms of Continuous Deployment / Continuous Delivery, the staging environment is used to test software in a "production-like" environment, as its likely that developers will be working in an environment with significant differences to production (e.g. no load balancing, a smaller dataset etc...)

Licensed under: CC-BY-SA with attribution
scroll top