With Redgate Change Control it is possible to capture database changes into a schema model on the Changes tab, which provides convenient object-level history in your version control system.

If you make changes to your development database and refresh the page, these changes should show up on the page.

If you select any changes you want to capture, and then click Save, each change will be saved as its own script within the schema-model folder under your project.

Following the Commit changes button or clicking on the Version control tab allows you to then commit these changes to Git if your project is in a Git working folder.

Why should I version control my database schemas?

Version control is a good idea for a number of reasons:

• You can keep track of changes to your database schemas
  • Find out the exact details of the change
  • Find out when the change happened
  • Find out who made the change
  • Find out why the change was made (using a commit message, which could be tied back to a user story or bug id)
• You can share database schema changes
  • Share changes between team members on different development databases
  • Kick-off Continuous Integration (CI) and automated releases (e.g., to Test environments or more)
• Get back to previous versions of an object

How does Redgate Change Control do it?

Normally, it's hard to version control database schemas because they're not text files. Version control only really works well for text files, because it's easy to tell what's changed in a text file. It's much harder to tell what's changed between two versions of other files, eg binary files.

Databases are just large binary files, so if you tried to version control one, your version control system wouldn't be able to tell what's happened when you make changes. This means you don't get most of the benefits of version control.

Redgate Change Control lets you version control the schemas of your SQL Server databases. 

It generates a version of your database schemas as text files, which you can link to your version control system. This means that, when you make a schema change and commit it to version control, it's easy to see what the change was. Redgate Change Control figures out how to turn that change into text files, including any dependencies. 

How is the schema model different from migration scripts?

Migration scripts capture the steps needed to deploy a schema to a clean database.

The schema model represents each object in its own script.

The migration scripts are safer to use for deployment as they are customizable and allow for the migration of transactional data while making changes to the schema.

The schema model is a representation of the schema information which allows for a richer version control history. It also allows for rapid iteration in development without generating a new script for every change.

Redgate Change Control does not yet support both a schema model and migrations for any database type, but this will be forthcoming.  Get in touch with the development team if you want to learn more about our plans and try out early versions.