The Definitive Guide to Database Version Control – Part 1

this is part one of a seven-part series on database version control. we will discuss why version control for the database is a key component of devops. we will go through the most popular methods being used and the shortfalls of each. we will then reveal the correct way to practice database version control in order to maximize value and eliminate risk to the organization.

business needs are the most significant driver of change. the ability to do more with less and offer accelerated delivery is what differentiates successful, world-class companies from the rest.

if your competitor can deliver relevant features, faster and with better quality, you are eventually going to lose market share. agile development was born from the need to move more rapidly and deal with ever-changing requirements, while ensuring optimum quality in spite of resource constraints.

the waterfall methodology’s big release concept doesn’t cut it anymore – you just can’t wait six months until the next roll-out or release. agile development solves this by reducing the scope of the releases, allowing the development team to complete them faster. additionally, the impact of changes is far less than with a big release. agility is what is expected from technology companies and it divisions to support the business needs.

the next natural step is to link development with operations. this has given rise to devops.

to effectively master agile sprint deployments and to practice devops, you need to be able to implement deployment and process automation internally within development and qa, or to production. otherwise, deployments and releases will require manual steps and processes, which lack repeatability, are prone to human error, and cannot be executed with high frequency.

the automation required is based on a version control repository that manages all software assets ready to be built (compiled) and then deployed (executed) to the next environment.

the build process starts by cleaning the working space and getting the relevant files from the version control repository. this is a critical phase that prevents out-of-process changes, which can happen even though they can be avoided if developers save their changes directly in the build server working space, instead of checking-in the changes to the version control repository. this example may sound absurd because – of course – developers know that if they do so, their changes will be lost, as the technology enforces the process. but, sometimes it happens. this phase also prevents the build phase from taking work-in-progress changes by referring to only those changes that were submitted to the version control repository in a check-in process. the version control repository acts as the single source of truth.

in part two of the series, we’ll look at what separates the database from application code and the challenges that must be addressed when managing database changes.