26

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.

Machado
  • 4,090
  • 3
  • 25
  • 37
  • 4
    I want more people to weigh in, but this seems primarily opinion based. In my current environment, Staging and UAT are different. UAT is a live, public environment that is synchronized with production deployments but with a different data load to allow users to play around with the software. We refer to it as a Sandbox environment for users. Staging is a private place to test deployment and infrastructure changes before running them in Production and UAT. There are obligations to customers around availability and use of UAT, but not Staging. Other companies are likely to be different. – Thomas Owens Aug 04 '17 at 14:27
  • @ThomasOwens the point is precisely that: Both environments are different and for some people it seems to be one thing and for other people it means other things. The question on Server Fault stated that you use staging pointing to online production data and just "flip the switch", which I think it's an interesting approach, but it's a different view than what you're saying. – Machado Aug 04 '17 at 16:57
  • 2
    The fact that it's one thing for some people and something else for other people is what makes this primarily opinion based - there isn't an answer. I haven't pulled the trigger on closing it yet, in case I'm wrong. It's a well-written question, and there may be a standard definition out there. Now, if people choose to ignore that standard definition and use their own is another story. – Thomas Owens Aug 04 '17 at 17:15
  • @ThomasOwens, fair statement. If you don't mind, let's keep it open for a couple of days and if it spawns just opinion-based answers I'd gladly vote to close with you. :) – Machado Aug 04 '17 at 17:36
  • @ThomasOwens agreed I feel this question is also somewhat subjective in what people refer to as staging. Our UAT and staging environment are the "same thing" but this is because we have many releases so when we are ready for release, we take over the staging environment and prepare it for UAT to release it. Developers who are working on their own things still have a way to use feature branches on our stage environment so it doesn't block them though. – aug Aug 04 '17 at 18:28
  • @ThomasOwens, I'm surprised at your stance here. You often close and lock questions that do not attract overly opinion-based answers, yet here you are being unsure whether to close this one. The terms have no fixed meanings and so any answer - save for "they mean different things to different people" answers - will inherently be purely opinion-based therefore. So I've voted to close it. – David Arno Aug 04 '17 at 19:17
  • I support @ThomasOwens regarding the point that difference depend on what definition of "staging environment" you are using, it seems to be not so established as "UAT environment". Moreover in Wikipedia page you are referring to: "Stage/.../External-Client Acceptance" which makes them the same thing! – Vlad Aug 04 '17 at 19:31
  • @Vlad, hence the question. The best definition I saw so far for staging, however, was one where you'd run in parallel with your production, pointing to the same dataset, and you could just "flip the switch" by pointing the production environment to the staging environment, which got me thinking about if we're misusing the term. – Machado Aug 04 '17 at 19:38
  • Let's narrow the question then to "What is staging environment". – Vlad Aug 04 '17 at 19:43
  • Should release candidate builds (`rc`) be deployed to staging and UAT equally? – Con Antonakos Sep 07 '18 at 19:21

5 Answers5

23

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.

John Wu
  • 26,032
  • 10
  • 63
  • 84
1

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.

BobDalgleish
  • 4,644
  • 5
  • 18
  • 23
  • It seems than that you have 3 different test environments, with different purposes, but still test environments: 1 focused on Q&A, 1 focused on developers and one focused on operations team. But all of them are still testing environments, and tied to test databases, for example. Is this correct or am I missing something ? – Machado Aug 04 '17 at 16:54
  • Each of them would be tied to their own databases, yes. – BobDalgleish Aug 04 '17 at 17:41
1
| 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.

Vlad
  • 559
  • 1
  • 3
  • 6
1

UAT is User Acceptance Testing PROCESS , environment for this could be any stable environment, which can be send to the User which will execute testing. Most frequently - stage environment is used for it.

essential light
  • 11
  • 1
0

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...)

Justin
  • 1,728
  • 10
  • 16