Ideas for creating QA and Test environments with very limited DBA support.

  • I’m looking for some ideas to try in order to provide our small department (about 35 to 40 people) with a quality test and training environment. This small department is within a very large company (about 210,000 employees). As I understand we are the only department within this large company that has its own IT people. We have a web developer, two MS Access developers, and a supervisor. We have two large Access databases and both are using SQL Server as the data source for all the tables. Because we are so unique within the business, we have very limited access to the production server. And, we (the Access DB developers) are somewhat novices to SQL Server so this is not something we can attack as a real SQL DBA.

    After reading several articles about SQL Server production and test environments supplied by Google searches, I’m hoping for some more specific suggestions from this forum that would be useful considering my work environment limitations.

    It seems that using a backup copy of the production database would be the best way to create a Test and a QA environment. I’m not sure I can get a copy of the Production backup, but I will be trying to obtain that after I hear back from members of the forum and see what ideas come from here.

    Thanks!

    [font="Comic Sans MS"]Vic[/font]
    www.vicrauch.com

  • What exactly is the goal of your test and QA environment? Do you need just the database structure or do you actually need the production data in that environment? There are reasons why you wouldn't want to just take a full copy of your production database, from a technical perspective size might be an issue and from another perspective there might be sensitive data in your database you don't necessarily want to copy over.

  • I echo the previous post!

    Also, where are the test and QA databases going to reside? If you plan on having them on the same instance, then that's not a great idea. Security, sensitive data, and performance are the main reasons.

    How do you roll out new code? Is the process well documented, and followed? As a simplified example, the developers write code against test, and assign the "ticket" to the DBA's for promotion to QA. Once QA signs off, the code is put into the queue to deploy to production. Updating production should be done on a regular schedule. Once production is updated, QA should be refreshed.

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:
    http://www.sqlservercentral.com/articles/61537/

  • The Test environment is for the development of new applications and enhancements of existing applications.

    The QA environment is used to test the items that developers say are ready for production, but need through testing first.

    Out two databases are each very small by SQL Server standards. Approximately 50 tables, and about 3 or 4 tables with about 30,000 records, and the rest of the tables would have an average record count of less than 500. No customer data in any of the tables, we are dealing mainly with construction contractors. The total population of people that would have access to Test or QA is 6 people.

    All three databases are on their own "personal" server. My understanding is that each server is on its own virtual machine. Because we are developing in MS Access, we do the enhancement or fix, test it, then roll out the whole new database. Yes, the procedure is documented and followed closely. Careful planning and development is paramount for this small department because so many high level eyes in the company are watching closely

    [font="Comic Sans MS"]Vic[/font]
    www.vicrauch.com

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply