In what exact cases should staging / beta and production / stable environments share a database?

Question

In my past and current web development positions, Staging / Beta and Production / Stable environments have shared a database.

Here's my understanding of what is going on:

• Staging / Beta is basically identical to Production / Stable's server(s), except the public at large cannot access Staging / Beta

• Once QA's tests pass the upcoming iteration of code on its own sanitized subset copy of Production / Stable data, the next step in the development is to make sure that the upcoming iteration of code will work with the full set of Production / Stable data while not breaking the existing Production / Stable website - that's the purpose of Staging / Beta. Also, a company can let beta-testers test out the code using the same data which the world at large can see. Then, when the beta-testers give the thumbs up, it should be a simple switch from the older iteration to the newer iteration of code.

One of my direct reports called this a "smell". He suggests that Staging / Beta should have a full and complete copy of Production / Stable's database -- thus if there truly is a problem with Staging / Beta code which was not caught during QA, it won't affect the Production / Stable experience. That was the answer with these two links:

• Staging enviornment setup
• Staging database predicament

So here's my question: in what exact cases SHOULD Staging / Beta and Production / Stable share a database server? Or are my current and previous companies doing things wrong / being cheap / etc.?

Thank you in advance for your thoughts.

Answer 1

Sharing resources should only be done if you don't have enough resources :)

I have to agree with your direct report. A couple of issues you can run into, and they aren't too uncommon:

1. The process of testing steals resources from production.
2. New code is broken an consumes way too many resources (variation on #1)
3. New code requires a new schema that can't live easily side-by-side with the production schema.
4. In the process of installing changes for beta, you break production.

I really don't see how you can excuse not hosting staging/beta separately.

Answer 2

The goal seems to be:

1. Allow for the new version for a subset of users (great for agile work flow)
2. avoid data loss or unique key loss/duplication since both versions run concurrently

I am in a similar environment, and I can't seem to find a documented development life cycle that allows for the above. I would say it is a cross between A/B Testing and "Canary Release Strategy".

We solved this with a fourth environment, between testing and production (we call it beta even though it is actually production):

1. alpha developer testing. This is where developers push branches and merge code.
2. QA/staging user testing. This will be identical to production once new version is released.)
3. beta production for a subset of users. (we are trying to come up with a better name since having production data on "beta" makes auditors nervous.. I'm not sure if "canary" will fly... no pun intended.
4. www (Generally Available production)

Show stoppers should never make it to beta (in this context) since it is production, which is separate from staging/QA.

If you like this answer, maybe you can name the release cycle or deployment strategy after me :)