Keeping QA Up to Date
Introduction
All programmers test their code, right? Everyone I know writes code that works and the only
bugs that we find are due to differences in interpretations in the business rules. By the time
code is complete from the developer, it is ready for prime time. Ready for the real world, ready
for you to deploy in your production systems.
Well, you can skip this article and go back to your Pina Colada on the beach. Everyone else in the real world should have a QA environment setup where code can be tested. This environment should be setup to test for two different purposes. One, the code should be tested to see that it actually works. The second reason is to test the deployment of the changes to the production environment. It is this second purpose that is my subject today.
Change Management
Change management is crucial to a stable environment. The only real way to test these changes is to periodically make a copy of your production environment and test your deployment. This is one of those areas that always gets shortchanged, but I have found over the years is one of the most important tests you must perform.
How many of us complain when we upgrade our Windows OS from one version to another? How many of us
skip upgrading and just reinstall? We want the upgrades we receive to work, so shouldn't ours work
as well? I have worked in client/server environments, n-tier web based deployments, and now I am starting to work with Web Service deployments. In every case, the process of deploying the changes is an area that is often overlooked.
I have seen departments that apply their changes to a test system, start fixing the bugs, and eventually get the test system working. At that point, they assume that they are ready to deploy. Yikes!!!!!!!!!
At that point, they are just completing one phase of testing. It is at this time that you must now
start the test system from scratch and be sure that you can deploy all your changes at once. In some large deployments I have seen this process repeated over and over until it sometimes you have spent almost as much time practicing the deployment as you did in development!
To ensure that your development changes can be applied reliably to the production system, you must have a separate system to which you can apply your changes. In most of my positions, we have referred to this system as the QA or Quality Assurance system. This is the database which is copied from production and used to test our changes.
There are a few methods for doing this. You do not necessarily need another server, but you do need the disk space to duplicate the database. In SQL Server, DTS provides a copy database task, and there is always the detach database/copy files/attach database method that many DBAs favor. The best method I have found, however, is one I have been using since v4.2 on OS/2: Backup and Restore.
My Process
I used to script the process using a combination of batch files and T-SQL scripts and then run these from some scheduler. With the advent of SQL Server 7, I upgrade my process to utilize the capabilities of DTS. For those who have read my Push FTP article, this process will look familiar.
There are 3 basic steps that I developed to automate the rebuild of our QA environment. They are the following:
- Get the Latest Database Backup
- Restore the database
- Apply the business rule changes and synch the logins/users
I divided my process into these three areas because these different processes can be independently altered to suit the different needs I have in different environments. I like having things linked together, but not too tightly tied so that a failure in one place snowballs. I'd rather have the restore take place, even from last week, even though the latest backup wasn't restored. It allows me to deal with the failure in my own way.
That's the basics of my steps. I'll be following this up in the future with the details of how each process works. In the meantime, if you think I've missed something, let me know and I can include or answer the question in the forum or in future articles.
Steve Jones
©dkRanch.net October 2003
