dbForge Source Control For SQL Server

I was always enthusiastic about database development. However, we must distinguish between enthusiasm and professionalism. For this reason, when working with database I try to adhere to a certain set of rules. One of these rules – version controlling database changes.

You may ask why do I need this?

The answer is quite simple. Version control allows you to track changes and verify their quality. At any time, you can roll back the changes. If you work in a team, then the use of version control brings clarity and order in the development process.

I've recently discovered a new plug-in for SSMS – dbForge Source Control, which allows you to track changes and implement version controlling of database development.

Which version control systems it uses? Essentially, this question does not make sense, since dbForge Source Control supports all major version control systems, such as TFS, SVN, Git, Mercurial, Perforce. Another advantage of dbForge Source Control is that it does not require any additional components.

Well ... Let's put words into deeds.

First, we need to link a database to a version control system.



dbForge Source Control supports two developer modes: Shared and Dedicated.



In Dedicated mode, each developer works with a dedicated or local instance of a database. On the one hand, the developer can work independently and test changes apart from the rest of the team. On the other hand, the number of databases under development increases. Such development model can lead to conflicts when changes are committed.

In Shared mode, all developers work with a single database instance. In this case, no conflicts occur. However, one developer can erase changes of other team members.

After selecting the development model, we need to choose a version control system:

 

As an example, I've chosen SVN and specified the local path to my repository:



After that, you need to add custom database objects into the repository. For this purpose, you need to select the required objects, specify the commit description and click Commit.



Change schema, open Source Control and see the changes:



However, reviewing changes is just one of the advantages of using version control in database development.

In team development, you should always get the latest version before committing changes:



It is also important to see a retrospect of the changes. You can see the entire history of commits in a separate window and compare changes in revisions in a few clicks:



I should also mention a simple mechanism for conflict resolution.

dbForge Source Control does not allow taking any action before all conflicts are resolved. To resolve them, you can accept either local changes (Get local) or recent changes, which are stored in the repository (Get remote):



As you can see, little effort is required to keep database changes under control.