SQL Server Source Control Basics

For efficient team-based database development, and reliable and repeatable database deployments, source control is not optional. This book provides just the right combination of theory and practical example to get you started quickly.

DevOps, Continuous Delivery & Database Lifecycle Management
Version Control


1981-SQL-Source-Control-Basics-Bookshot_

Download the free PDF: from Redgate

The job of a source control system is to maintain a change history of all the files in a project. As soon as we enter a new file into source control, the system assigns it a version. Each time we commit a change to that file, the version increments, and we have access to the current version and all previous versions of the file. For good reason, we often refer to a source control system as a version control system, or VCS.

Few software developers would consider building an application without the benefits that a VCS offers, but its adoption for databases has been slower, partly because of the added complication of the need to preserve data during database upgrades. However, unless we have in the VCS the correct versions of all the scripts necessary to create our database objects, load lookup data, add security accounts, and take any other necessary actions, we have no hope of a reliable and repeatable database deployment process, let alone of coordinating database upgrades with changes to the associated application. We also run a very real risk that our “ad hoc” database patching will cause inconsistencies and data loss.

Version control can and should play a key role in the database development and deployment process, and this book will show you exactly how to get started. It provides ‘just enough’ detail about the core components of a source control system, and the functions that allow us to commit our database changes and retrieve others’ changes. It then focuses on getting a database into source control and working with it, covering:

  • Database Source Control architecture – what needs to be in there, how to structure it all
  • Collaborative editing – team work on a database project, while minimizing the potential for conflicting changes and data loss.
  • Change auditing – what changed between one version and another, and who changed it?
  • Branching – allows teams to work independently on separate features, and control what we deploy and when
  • Merging – what happens if one user changes the name of a column while another updates its data type? A merge operation lets the team to decide the correct outcome
  • Building and Deploying databases – building new database and upgrading existing database from source control

Every chapter follows the same “half-theory, half practice” template, so you learn the concepts and then immediately see how they work in a particular source control system, in this case Subversion (SVN).

DevOps, Continuous Delivery & Database Lifecycle Management
Go to the Simple Talk library to find more articles, or visit www.red-gate.com/solutions for more information on the benefits of extending DevOps practices to SQL Server databases.

How you log in to Simple Talk has changed

We now use Redgate ID (RGID). If you already have an RGID, we’ll try to match it to your account. If not, we’ll create one for you and connect it.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.

Continue

Simple Talk now uses Redgate ID

If you already have a Redgate ID (RGID), sign in using your existing RGID credentials. If not, you can create one on the next screen.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.

Continue