With Overarching Logic, Shouldn’t the Execution Follow Suit?

I’m a constant conference attendee and it gives me the opportunity to meet hundreds of CTOs, CIOs, VPs, Directors, managers, engineering, DBA, DevOps – you name it! When I meet these people, my first question is usually why they have continuous integration and CD processes in place for the application code and not the database. It’s a disarmingly straight-forward and difficult to answer question.

In addressing some of the most common rationales offered in response to that basic question, I’ve come up with these 5 major differences between application continuous delivery and database continuous delivery.

  1. Cost of fixing process errors: The cost of executing the wrong database script in production is measured in downtime or manpower hours needed by DBAs to fix the database and the data. The cost of copying the wrong version of the application binary to production, on the other hand, is measured in seconds or minutes that it takes to copy the correct version of the binary.
  2. Automation processes in place: Most organizations are using application release automation tools or home grown scripts already which means they have some level of automation to handle the deployment of the application binaries. When it comes to the database, however, they usually don’t have a similarly reliable infrastructure to automate the database delta scripts.
  3. The process of deploying changes: This is one of the main technical reasons why organizations do not implement continuous processes for the database. The process of application deployment is primarily comprised of copying new revisions from the binaries’ source control repository and overriding whatever else exists. The process of database deployment, on the other hand, is running sql script(s) to alter the database structure and data from a given state to the new state.
  4. Safety net validation: The application deployment process has a built-in safety mechanism based on source control for the binaries. There is no way to copy binaries into the production (or previous environments) from other sources (for example: a local developer PC). With the database however, there are people with permissions to login and perform changes directly in the database even in the production environment, and there is no notification or safety net mechanism to handle such changes.
  5. Single source vs multiple sources: Every application build process execution uses only code from the source control repository – the single source of truth. The binaries (output of the build) are deployed to the production, overriding what exists. In the database tier, there is no option to override what exists. The database deployment (discussed in #3) is executing the modification steps and the execution of these scripts assumes the state of the database was not changed out of the continuous process. The problem is (as mentioned above in #4) that this assumption is not guaranteed to be accurate.

Application & Database Continuous Delivery: Different But Alike

The benefits of having continuous processes include increased productivity, faster time to market, reduced risk and increased quality. In theory, everyone wants the continuous delivery processes to also cover the database tier but most organization don’t have a solution that addresses the technical and business challenges of database continuous delivery.

Without implementing continuous delivery processes to the database, the database remains the weak link, not following the same best practices and process of the application. Fortunately, there are solutions that resolve these challenges.