When I posted my original article on this topic, in 2013, it used SVN and Jenkins, and proved very popular. This article is all about setting up the plumbing that will allow you to put CI theory into practice, for databases. The theory behind CI is that if we integrate code into a shared repository several times a day, and then verify each commit by running an automated build, and subsequent tests, then we detect and eradicate problems early, and improve the quality of our software. Over time, database changes become easier, and the database build and deployment processes get more predictable, and far less likely to introduce problems into the production systems. Bugs, introduced by coding errors or by new versions of third-party components, become much easier to find and remove because we know that the problem was caused by a change made since the last successful integration. In a Database Continuous Integration (CI) process, we establish a working version of the database quickly, integrate subsequent changes as frequently as possible, and run tests each time to prove that the database still works. Step 3: Automating your build using Azure DevOps.Step 2.1 (optional): Writing a build script using SCA and PowerShell.Step 2: Linking a database to source control.Step 1: Create a new Azure DevOps project and clone the repository.This article explains how to set up a SQL Server source control and database continuous integration (CI) process from scratch - using Azure DevOps, Git, PowerShell, and Redgate tools - in three steps:

Redgate sql toolbelt comparing database