1

I looked at this question. As far as I understand test env is for qa department to conduct their tests, and staging is identical to prod, but hidden from end user.

My questions are:

  1. Should staging be 100% identical to prod, or is it ok for staging to have "messed up" data in it? Just how much is it ok for staging db to differ from production db?
  2. Is it normal/standard procedure to copy tables from staging env to prod env? Is that how other companies do it in the real world?

Why am I asking (or where I am coming from)

I have a txt file and I have to dump contents of this file into database. We have 3 environments: dev, test, prod. I can dump data to dev, test but not prod. We are not allowed to dump data directly to prod database. We are only allowed to move data by requesting a database move. Then somebody will copy table from test to prod for me. My concern is that while doing testing in test db I may corrupt correctness of data, and if I submit db move document and it gets approved messed up data will make it to production database. I want to avoid this, obviously.

  • I would assume that your database administrator will have some procedures in place to prevent this from happening - this is probably why you have to submit "data movement" request to them. – Mael Feb 28 '18 at 15:12
  • @Mael Hmm... I don't know. How would db admin could tell data got messed up? I upload 100,000+ rows of data. What if I by accident remove 1 row (how exactly that happens is non important). db admin won't be able to tell that 1 row is missing. – whatever Feb 28 '18 at 15:18
  • Probably by some combination of constraints on data in the tables. Try asking the people who move the data at your company. – Mael Feb 28 '18 at 15:27
  • increment.com/development/… – Thomas Junk Apr 30 '18 at 15:12
2

Should staging be 100% identical to prod?

I believe that the answer to this question can vary significantly from company-to-company. You should discuss the specifics of your company's various environments with someone knowledgable at your job.

My concern is that while doing testing in test db I may corrupt correctness of data, and if I submit db move document and it gets approved messed up data will make it to production database.

If you are worried about messing up data in the "test" environment, I would suggest you develop some type of test(s) which can be executed in the development and/or test environments to ensure your changes are safe. While the form of these tests will vary based on the scope of your work, some suggestions could include:

  1. Direct tests against the code you wrote ("unit" or "small" tests)
  2. A script which iterates over the database table after you've dumped to it and ensures all data is correct
  3. Pull a representative sample of test cases to verify by hand (or by a script)

There may be other forms of verification that make sense but without context on your specific system, it is hard to point to a definitive test suite!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.