Projects are the primary artifact used when developing and deploying databases using SQL Change Automation. They contain a database's state, and a set of scripts that describe how to get to that state. Projects are a 'single source of truth' as they represent the state a database ought to be in.

Most work with projects is done using Visual Studio, using the Visual Studio Extension. Consult the Microsoft documentation about solutions and projects in Visual Studio.

Since projects only contain SQL scripts and Visual Studio configuration files, they can be committed to source control without any extra configuration.

SQL Change Automation represents a database as a set of SQL scripts that describe how to take a database from one state to another, known as migration scripts. SQL Change Automation primarily takes a migrations-based approach to database development. See Migrations.

Should your SQL Change Automation project be in its own Visual Studio solution?

SQL Change Automation projects may coexist in a Visual Studio solution with other projects, including projects that are used for application code.

If you are developing code for a database which is used by multiple applications that are managed in different Visual Studio solutions, we recommend that you maintain the SQL Change Automation project in a separate Visual Studio solution.

Deploying a SQL Change Automation project

SQL Change Automation projects can be deployed to databases using the SQL Change Automation build and release components. The build and release components understand how to apply the scripts contained in the project to a database, in order to change the database so it matches the state of the project. See Automating database changes.

SQL Source Control projects

SQL Change Automation also allows you to deploy SQL Source Control projects. However with this approach you'll have less control over how the scripts are deployed.

For more information see SQL Source Control's documentation.