TugaIT 2016 – Road to database automation

tugaitThe TugaIT 2016, May 21, was so far the biggest event that I participated was a speaker. The logistic challenge was characterized by 9 tracks, each track with 6 sessions, making a total of 64 sessions. At the end of the event two combined words remain in my mind: monstrously amazing.

My participation on the TugaIT event started on the day before, Friday May 20, with the workshop “Deep walkthrough of some of the most popular/innovative features in SQL server storage engine” by Sunil Agarwal (@S_u_n_e_e_l). In addition to get to know very interesting features in SQL server 2016 edition, Sunil Agarwal can explain how they work in a very simple and easy way to understand. In fact when you listen him talking everything in SQL server seems easy and simple. The day ended with the speaker’s dinner where I had the opportunity to know and socialize with other speakers.

Next day, Saturday May 21, I made my session “Road to database automation”. This session addressed the challenges of the first step of the database automation process: database source control. Despite being part of the last sessions of the day, I had a good assistance and very interactive. I was glad to know the more people is doing database source control.


PortoData 20 April 2016 – Database source control: Migrations vs State

My second presentation at Porto.Data (April 20) was about the two approaches, migrations and state, for database source control. During the presentation I explored the advantages and disadvantages of each approach. For migrations approach I used the tool Flyway and for state approach I used Redgate SQL Source Control.

Besides presenting the pros and cons of each approach my goal was also to show that two approaches can be needed in different parts of the system, or at different times in the development process. Size and complexity of the databases, team’s capabilities or preferences and development processes will be factors that will influence the adoption or the variation between the two approaches.

Here’s some “sensations” collected from the audience:

  • This presentation is especially useful for those who’s starting to implement database source control and want to know the available options/approaches;
  • The meaning of “introduction changes in the database” or his effects/implications are not very familiar concepts to the audience;
  • The management/articulation of changes between databases and applications is not a clear process or necessity for the audience. There remains different/separated views for databases and applications (next presentation/challenge: show how to deploy an application and a database together). 


  

 

 

SQLSaturday #485 Lisbon 2016

SQLSaturday #485 Lisbon 2016, held on February 20, was my third SQLSaturday event and my first as speaker. When  I received the email saying that my session had been accepted in schedule’s event I felt happy and honored.    sqlsatuardaylisbon2016

My session, Road to database automation, was accepted as lightning talk. So I had 10 minutes to address the first stage of the database automation: database source control and it´s benefits. During that time I presented the reasons that lead me to invest on database source control and what tools I used to achieve it. You can find my presentation in the end of this post.

The presentation went well and fast. But the best happened after the presentation: the attendees feedback and curiosity. The possibility of discuss my favorite topics with other people with similar challenges was amazing.

This post is also the opportunity to give my congratulations to the event organization, headed by André Batista @klunkySQL, who provided great moments of conviviality, and to say thank you to the portuguese sql family for welcoming me so well.

IMG_20160221_111027

I hope to see you all soon.


 

 

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.

Database automation motivation

The first question I thought was: if applications development includes “by default” concepts as source control, continuous integration and continuous delivery, why not database development?

As Len Bass said in a conference: “A script is just a program”. All database changes can be scripted, so what is so special about databases? The answer is simple: data, specifically data persistence. One of my favorite answers was given by Grant Fritchey: “Deploying databases has the inherent problem of retaining the data after the deployment”.

Faced with this challenge the second question that I made was: why should I invest my time and effort in automating the database development process? I found the following  answers/reasons in literature and in my day to day job:

  •   Database are out of pace with application development
    • The database changes usually come from the development teams, however in most cases the DBA is responsible for applying this changes. This means that development teams and the DBA need to be synchronized, in the best case scenario this is a communication challenge;
  • No traceability of database changes (changes history)
    •  There will always be a moment where you need to answer the following questions: What was changed? Who changed it? When it was changed? Why it was changed?
    • In the ideal world the source control system should be able to answer this questions;
  • Manual database processes prevent the Continuous Integration (CI) and Continuous Delivery (CD) in their full extent
    • The strength of your process is equal to the strength of your weakest step of the process;
    •  Is acceptable to say that if the process contains a manual step, you can not say that you have a automated process? (Almost automated is not automated)
  • Manual database release process
    • This process is time consuming and error prone;
    • This make the release process less frequent and risky;
  • Tests are manual or do not exists
    • This have a serious impact in the application quality;
  • Bugs in production environment
    • Database related bugs are only discovered after deployment to production;
    • Fixes and hot-fixes have time cost, what can lead to delay a release;
  • Inability to roll back to the previous version of the database
  • Database setup in a new environment is time consuming
  • Databases become a bottleneck in agile delivery processes
    • Databases can be the most expensive component and the bigger troublemaker (part of it is because it’s “easy to blame” the database for the application problems).

The adoption of the database automation allows to:

  • Enable control over database development
    • If you have control, you have better conditions to improve;
  • Keep a versioned “history” of database states;
  • Increase release frequency through repeatability of processes
    •  Greater predictability over releases;
    • Efficiency by eliminating the repetition of a range of manual activities
  • Reduce time spent fixing bugs
    • With more control you are less expose to error;
  • Speed up response to change
    • Automated deployment of smaller units of change;
  • Remove/reduce human intervention in the release process
    • The build step is automatic triggered by a “push” into source control repository;
    • The deploy step is automatic triggered by a successfully build process;
  • Have greater reliability of the release process
    • Providing a series of automated test stages prior to deployment;
  • Maintain an agile development environment

PortoData 15 December 2015 – Road to database automation

Last Tuesday (15 December 2015) I made my first presentation in Porto.Data community. “Road to database automation” was the title and the this session had two main goals: discuss the challenges of database inclusion in the Application Lifecycle Management (ALM) and present a set of strategies and tools to achieve this inclusion.

The effort of database inclusion in the “agile context” is designated as Database Lifecycle Management (DLM) and is composed by 3 main parts: database source control, database continuous integration and database continuous delivery.

In the first approach to database automation are presented some strategies/techniques and tools, such as Mercurial (TortoiseHg) and Git (SourceTree) for source control and Flyway for database migrations management,  to deal with the challenges that a database version control system implies.