Ten Years of Continuous Integration: Where’s My Continuous Integration Database?

In 2006, Martin Fowler posted his now famous essay on Continuous Integration. Looking back, what seemed revolutionary, radical or just plain crazy is now common, pedestrian and “just what you do.” I love it.

Back then, building and releasing software was a real pain. Integration was something you did at the end, after code complete, and we didn’t know how long it would take. Some people may recall how we, as an industry, spent a massive amount of time integrating code from one team with another, or even just between developers that sat next to each other. The arguments against it at the time seemed valid and impactful. Now they seem weak and silly.

Fowler proposed Continuous Integration, an idea that was simple, elegant and had far-reaching repercussions. By producing constant, automated, self-testing builds in development, a huge amount of resource overhead typically incurred down the line was eliminated.

Fowler calls out two arguments against Continuous Integration: “It can’t work (here)” and “Doing it won’t make much difference.” Now that we see that Continuous Integration can work here and that it will make a huge difference, let’s make the database a top-tier software citizen and recognize its importance in our software development lifecycle. It is time for Database Continuous Integration.

The database is just as important as the application because it is part of the application. For far too long, we have heard from DBAs about the special import the database has. Or we have seen software developers denigrate the database as a consistent dumping ground. Both sides are wrong. We need continuous Integration to include database changes.

Now, I would argue that the data itself is the most important asset here. After all, the data will live far longer than the application or the database that contains it, as the application morphs from one platform to the next or structured databases are exchanged for semi-structured. But the database is not any more or less important than the application. Separately they are worthless; together they become valuable.

Thus, if our database structure and stored logic depends so much on the application (and vice versa), it is time that we give the database its due as a software asset. We must include DDL in our single source code repository and Continuous Integration. We also must include, alongside the DDL, mechanisms to gracefully upgrade and downgrade database schema to align with the application.

If the database is just as important as the application, then the database infrastructure is also just as important as the application infrastructure. The fact that we can fire up a server in the cloud to host an app but must wait weeks to get a database set up is embarrassing. Unacceptable. Bizarre. Negligent.

Once application code and DDL are linked in the source code repository and a new release is in place that will update any older copy of database schema, it should be simple to quickly provision an independent development and testing environment.

Just as Continuous Integration eliminated the dreaded, “never-ending” integration stage of software development, when we adopt Database Continuous Integration, we can expect mountains of wasted effort to simply evaporate.

No longer do we have to meet to discuss which version of the database works with which version of the application. After all, every bit of friction between DBAs and application developers is a thinly-veiled integration exercise. And in today’s Continuous Integration environment, that’s just unnecessary.

Find out how Datical delivers Database Continuous Integration.