In case of database development, in the same way as for the application development, there are always tasks such as developing a new feature, fixing bugs from the current release, experimenting with code in order to improve performance, usability in any way and so on. Because of all of this, it is essential that any changes that have to be committed, but not immediately, are segregated to an isolated environment, that does not affect the rest of the team or the main code. For instance, when developing a new feature, it may require a lot of changes to be committed, before the feature, or even a functional part of the feature becomes useful, so the rest of the team can apply it on their local copies of a database. Without having the isolation while developing, the team will lack the freedom to code, without having to worry about breaking the existing code base.

Having a SQL database being version controlled locally, by storing all changes in a repository on a local machine can be quite handy. In the context of team based database development, it is necessary to establish the environment where changes can be tested locally, specific revisions reverted from the commit history, and doing such things before pushing changes to the remote repository where the rest of the team will be able to review them, and apply against a local database copy.

The essence of each source control system is the ability to easily review the history of committed revisions. In addition, to comparing revisions, a user needs to get a specific revision and apply it against a database. Each revision should have a unique timestamp and should carry the information about the user who did the commit. Such system ensures that it is easy to determine who committed what and when, and in some way provide a complete auditing trail of committed revisions.

Having a team of developers working on the same (shared) database can be challenging for many reasons. It is critical to ensure that all changes are properly tracked and that each developer is informed about the status of objects currently used by the rest of the team. When using a shared database, all changes will be applied against the database before they are committed to the repository.

Having a SQL Server database under source control is rapidly becoming the norm vs the exception in many software development teams. Using any development model (dedicated or shared), requires the team to establish a workflow and a set of rules. The dedicated model, though, allows a developer to act as an independent part of the process mainly in case the central server/repository is down. In this case, the team can continue to work unhindered. This article will focus on using the dedicated development model for SQL Server source control

In a multi-user database-development environment, avoiding conflicts and overwrites with edits, and ensuring all changes are audited and recorded is important. Until recently however, effective tools for SQL development management have lagged well behind their client developer equivalents, like Visual Studio. In this article, we will look on specific database source control challenges and a way to address them use new SQL developer tools that make meeting these straightforward and easy

Once become familiar with the source control basics (SQL Server Source Control – Part I – understanding source control basics), development client can be connected to both SQL Server and the version control system. This article will review 3 options: native support in SQL Server Management Studio, Visual Studio, and the 3rd party ApexSQL Source Control tool.

The goal of database source control is to propagate changes from a development environment, to test and production without issues and to fulfill the need to restore a database at any point in time, maintaining an audit trail, and to allow successful team collaboration during the project.

Collaborating on database development introduces a series of challenges. For instance, having the development team change the tables, views, stored procedures and other objects in a single, shared database, although intuitive, can introduce severe issues down the road as valid changes can be lost or overwritten by an unsuspecting teammate. This issue might be mitigated by restoring a database backup – under the assumption a valid backup exists. Even if it does, overwriting the development database with a backup means losing all of the valid database changes that have occurred since the backup was taken; not to mention the fact that restoring a large backup can take time – during which none of the developers can work on the database being restored.