How to deal with the code stability issue

I was worrying Monday about the problems with testing code under the "continuous integration" regime - if we're testing one item, and we think we're done, then it gets changed again (I imagine it being affected by another area of code), how does QA know it's "done done?" Under the version of the build process I saw on Monday, this was a real possibility: QA was basically expected to test in what I saw as a dev "sandbox," which is extremely unstable and only a step up from testing against a developer's own box - no control on changes and data. However, the version of the deployment workflow I saw yesterday had a new "optional deploy to second stable INT server for QA" bubble on it next to the "automated daily build on team branch" bubble, which makes me think that someone is actually taking into account our concerns. This is cheering.

I've also realized this week that it's time to get QA access to the databases again. I think this was taken away as part of an over-enthusiastic rollout of Sarbanes-Oxley - we can't possibly see any confidential data if we don't have access to the DB, right? However, every professional QA shop I've worked at has expected the test team to be doing verifications in the DB, and the fact that we are not here to me has long shown a hole in our processes. Apparently we had it at some point before I showed up; it's time to get it back. I'll be bringing this up at the Agile Implementation review meeting on Friday and see if I can get traction. The Developers want to be able to control what's on the boxes so they can do their work better - it's time for us to be able to do this, too, at least for the data. Just read access would be sufficient! (I wonder if there's an SQL licensing problem associated with this? If there wasn't before, there might be now ...)