Using clones for testing migration scripts

Ensure your migration scripts work exactly as intended, long before deployment

By automating the provision of clones of your current release and the latest release candidate, you have a very effective way to test, repeatedly, that schema migrations, such as a table split or column renaming, or datatype change, correctly preserve the existing data.

When you have a release candidate, you'll want to test any migration scripts that refactor existing tables, and therefore affect existing data, very thoroughly,  To run these tests, you'll need access to the current build of the release candidate, and to a development copy of the current production release, with data matching as closely as possible to what's in the real production database, so that you can check for potential data migration issues.

The test will need to apply the migration script to the current release, check that its metadata now matches that of the release candidate, and then check that all the data is preserved, after the schema refactoring.

With SQL Clone, these sort of tests are easier to set up, faster and more effective. You need two clones of the current release. You apply the migration script to one of the clones, leaving the other as a reference to check that the migration worked properly. Then, first, you compare the metadata of the resulting database with that of release candidate to make sure they are the same. Next, to ensure that the data is preserved after the schema refactoring, you run queries on each of the clones. The queries will be different (due to the refactoring) but they should still produce an identical result.

After testing the migration script, with SQL Clone it is very simple and fast to recreate a fresh clone, as part of the tear-down of the test after every test run. 

Using Clones as baselines in SQL Change Automation Projects

If, alongside SQL Clone, you are using SQL Change Automation as your automation tool for builds, deployments and releases, then you can use a clone of the production database, masked as required, as the 'baseline', for the project. This means that you can verify migration scripts on a copy of the currently released database, fully stocked with data. It will also mean you can detect, and correct, 'database drift' before you run a deployment. See: Clones for database drift detection during database CI

Didn't find what you were looking for?