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.