SQLPort 22 September 2016 @ Aveiro – Database source control: Migrations vs State

This was the first SQLPort event held in Aveiro. I was invited by Niko Neugebauer to deliver a session and I chose to explore the topic migrations-based approach vs state-based approach for database source control.

The purpose of my talk was to let audience know about the two existing approaches to start with source control at database level. After presenting the advantages and disadvantages of each approach I promoted a discussion with the participants so they could understand how, where and when they should apply each one of the approaches.

I would like to thanking Niko for inviting me and Ricardo Peres for the support in making this event possible.

Hope to repeat the visit to the beautiful city of Aveiro for more events.

Database Source Control – How?

In this post I describe some decision that you need to make when putting your database development under source control.

“Commit a SQL script to a local repository and the push to a central repository” sounds easy. In fact the all process should be easy.sqlscript

The SQL script is the fundamental resource of the database source control process.

The script can represent two perspectives:

  • The desired definition of the database object (table, view, stored procedure, function…), a.k.a state-based approach;
  • The desired modification to be applied on the database object, a.k.a the migrations-based approach;

About this two approaches I like the definition presented by Alex Yates:

  • State: Your source of truth is how the database should be.
  • Migrations: Your source of truth is how the database should change.

So, this is your first big decision: state-based approach or migrations-based approach? Can I use both approaches? (The discussion of which one it’s the better approach will be explored on a future post).

The correct answer it’s directly related to… your budget. Each one of the solutions (state, migrations or even the combination of the two) will do the work and will cost time and money.

In your budget you should consider the following tools:

  • For state-based approach
    • Redgate SQL Source Control (+info)
    • SQL Server Data Tools (SSDT) (+info)
    • DBSourceTools (+info)
  • For migrations-based approach

The next decision is to choose the source control system. All the tools above identified support or can be used with the following source control systems:

  • Mercurial
    • Is a distributed source control management tool (+info)
  • Git
    • Distributed version control system designed to handle everything from small to very large projects with speed and efficiency (+info)
  • TFVC
    • Team Foundation Version Control (TFVC) is a centralized version control that lets you apply granular permission and restrict access down to a file level (+info)

As “normal” user, meaning that I do not use APIs to work with this systems, my preference was built through the use of GUIs:sourcecontrolsystems

  1. Mercurial ->  TortoiseHg (+info)
  2. Git -> SourceTree (+info)
  3. TFVC -> Visual Studio (+info)

 

Currently my database repositories are Mercurial or Git because I prefer distribute systems. Then, once I use the migrations-based approach my first choice is Mercurial/TortoiseHg because in my opinion have a better branch representation. It´s less powerful than Git making it easier to use and teach (I taught a telecommunications team use TortoiseHg with great success).

Summing up: to answer the question “How to put database under source control?” you need to make two main decisions:

  1. SQL scripting strategy
    • State-based or migrations-based approach
  2. Source Control System
    • Centralized or distributed system

 

Database Source Control – Why?

Nowadays the question “Why put database under source control?” no longer makes sense. Probably “How to put database under source control?” is now the correct question.

But before answering the second question let me answer the first identifying the reasons that led me/us team to invest on database source control:

  •   Is the first step of database automation
    • In other words, if you want to assemble a database deployment pipeline you should put your database changes into a source control system;
  • Keep history of each change
    • Allows traceability:
      • Everything went well: just do it and forget it;
      • Something was broken: you will need to know what changed, when was changed, why it was changed and who changed it;
  • Your best communication system
    • Allows to share code (SQL scripts);
    • In team context a source control system helps to manage possible conflict of interest;
  • Enforce standards (my reference was Sjors Takes)
    • Standards, preferably combined with automation, help to reduce/eliminate conflicts.

database

How to put database under source control? is the question that follows.