Clones for database drift detection during database CI

Clones will help you detect and correct drift early, and avoid deployment delays

With Clones, you can set up an automated CI process that is a "dress rehearsal" for a real deployment

Database drift detection for standard SQL Change Automation deployment projects happens at deployment time, as described in Handling Schema Drift. However, of course, this can delay the deployment because it means you'll first then need to resolve the drift, manually, usually by importing the 'out-of-process' changes into version control.

However, if you are using SQL Clone, for example, and you have set up a deployment rehearsal as part of a CI process, you can find out on every CI build, which should be frequently enough for most.

  • Step 1: Refresh the SQL Clone image that SQL Change Automation project references as a baseline (see Using Clones to Automate Build and Deployment of Complex Databases)
  • Step 2: Deploy a clone of this image to the integration system.
  • Step 3: Create a release artifact from the latest build and deploy it, migrating it the current version. If the target has drifted, it will be detected at this stage, and resolved.
  • Step 4: Deploy latest application. The team can now run the complete suite of integration tests. 

 Verifying a deployment in this way is a very realistic "dry run" for the real thing and will give the team a high degree of confidence that the release to production will succeed.

See How to cope with Database Drift during Deployment using SQL Compare for an example of the sort of process you might use to incorporate the drift into version control

Didn't find what you were looking for?