Keeping QA Up To Date
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/qauptodate.asp<
-
Great topic.
I look forward to seeing the details of how you implement your changes. We've been working with a change management process, that takes into account the issues you raised, for a couple of years now. We're finding some shortcomings in the automation of the process and, I for one, would sure love to see how you're automating your process.
BTW, I wrote up an article on our process here: http://www.sswug.org/see/14782. Let me know what you think.
Grant
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
After a lot of tweaking we came up with a very similar solution. We restore backups of our data warehouse nightly into our QA environment. This allows for a lot of testing on "very close to live" data. When changes get implemented from development into QA a simply set a value from 1 to 0 in a table and the changes won't get written over. When changes are approved and moved into production I flip the value back and restores begin occuring again. It took a while to set it all up, but it very nice and has saved us many times.
- Vega -
We have just had our first contract tester and I have to say that it has been a very positive experience.
Our QA environment highlighted the need for a change in design.
We work with Web content management systems so we can't simply add tables into the application database, there has to be a 2nd, and sometimes 3rd database supporting bespoke functionality.
The problem comes when a query in the main app database references an external database.
This means that we have to change all the queries that reference database.dbo.table. Makes setting up a QA environment a bit difficult.
-
My process isn't without flaws and I'm sure I can learn a few things from you guys. It worked well and 90% of the time, so I just dealt with the 10%.
Grant, love to read yours, but not a SSWUG member and personally not interested in being one
. If you want to send a copy, please feel free. sjones@sqlservercentral.com. -
One thing that I've found especially useful for moving db's back to QA is to keep the logins the same. You don't mention it in the article, but there might be a lot of dba's who find that they have to drop and re-add the users after moving the db back to QA. By creating logins on the QA server that match the logins on the production server (just with different passwords) and ensuring that the sids match this negates you having to do this.
At my previous company we used to do this on a weekly basis and it worked with great success.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply