June 11, 2009

Being more efficient with Continuous Integration Testing

In my last blog entry, I wrote a sample letter to the marketing director of a fictional organization showcasing the benefits of why they should ‘virtualize’ their database marketing environment. Continuing the idea of how to build a better database marketing environment I wanted to follow up by talking about a process that can be used in nearly all database marketing environment, Continuous Integration Testing.

Continuous Integration Testing (CIT) is a term borrowed from the software development lifecycle (a.k.a SDLC). CIT is a practice where members of a development team integrate their work (i.e. coding) frequently and each integration is verified by an automated build and test cycle to detect integration errors as quickly as possible. This methodology can be easily adopted into a database marketing environment helping to transform major upgrades and simple patches alike into fast and painless processes.

As I mentioned in my last blog, one of the advantages of a virtualized database environment is the ability to clone a production environment with just a few clicks. Once this copy of the production environment has been made, updates to any components of the marketing application, the database, web server or any other applications integrated within the marketing environment can be tested as a whole. By following these steps borrowed from the CIT process, upgrades can be one less headache to worry about (not to mention being more efficient about them):

1. Automate the Upgrade Process
Upgrading a component in any system can be a complex process involving compiling, extracting and moving files around. Therefore, implementation of these upgrades should be made as simple as possible; no one should be made to baby-sit the process by constantly typing at the command prompt or clicking through dialog boxes for every test iteration. Automated scripting of upgrade installs should be made the standard operating procedure (e.g. best practice) since it not only speeds up the testing of patches and upgrades, but also simplifies the install process when the time comes to apply the upgrade/patch to the actual production environment.

2. Create a Cloned Production Environment for Testing
Development environments and production environments are often out of sync and testing on one does not necessarily mean that the upgrade/patch will function on the production environment. A virtualized marketing environment however can be easily cloned and upgrades/patches can be applied without fear of disrupting current marketing campaigns. And in the end, this will allow for a more accurate testing of the install.

3. Automate the Environment Tests
After the production marketing environment is cloned, a series of tests need to be run on the upgraded environment to confirm that the upgrade is compatible with existing campaigns and processes interfacing with the marketing application. These tests can range from a few test queries against the database, to running a set of campaigns as a benchmark for comparison against the current production environment. Whatever the tests may be, these also need to be automated with clearly defined expected results that will indicate a successful or failed outcome.
The automation of these tests will also allow for re-usability for future upgrade testing.

If the upgrade test fails, then delete the failed environment, and repeat the process with the necessary configuration changes on a new clone environment of the production environment until the upgrade/patch is successfully applied.

4. Automate Deployment
If the results of the upgrade tests are immediately successful, then the automated scripts from step 1 can be run on the existing production environment to install the upgrade/patch. If additional configuration is needed in step 3 for a successful upgrade, then these configuration parameters need to be incorporated into the automated upgrade process/scripts to fully automate deployment. Therefore, when the time comes to upgrade the production marketing environment, the upgrade process is a simple, no risk deployment since it has been thoroughly tested on the cloned marketing environment.

The Continuous Integration Testing methodology is a highly useful process in the software defined lifecycle. By adapting its core features of automated installation, build, testing and integration, we can significantly bolster the stability of a database marketing environment. Not only does the administering of the environment become simpler, it can be kept up-to-date on a consistent basis while reducing the risk of disruption to production marketing campaigns.