Database as Code: a Novel Concept
Database as Code: a Novel Concept
We talk a lot about treating the database as a first-class software citizen. We talk a lot about treating it like an enterprise’s most valuable asset. But, what about treating the database as code?
Join the DZone community and get the full member experience.Join For Free
RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.
We talk a lot about treating the database as a first-class software citizen. We talk a lot about treating it like an enterprise’s most valuable asset. But, what about the concept introduced by Dan North on the third slide of this presentation? What about treating the database as code?
That’s a brilliant way to put it, to be honest. We handle code for web releases and app releases like it’s a Fabergé egg. And, we absolutely should—code is the lifeblood of development. But, shouldn’t database changes enjoy the same version control/source code control, automation, speedy, and on-demand release capability, and DevOps inclusion that more traditional incarnations of code enjoy? Those are essentially the four key tenets that North argues serve as the underpinning for treating the database as code.
We’ve written a slew of other articles in which we describe exactly how and why (and even more about why) the database should be treated in a code-like manner and afforded the DevOps and Agile accelerators that have applied to the application layer for some time. In fact, GE Transportation data architect Chris Lawther spoke to the practice during a DevOps.com webinar we hosted. Lawther said:
“What we needed to do was to change our mindset of how we treated our database. We had to stop treating it like some special artifact or some unique scenario, and we started looking at it through the same perspective that we were treating our web code.”
We’ve been exploring the concept by saying we need to apply controls, automation, continuous delivery, and DevOps to the database, but we haven’t ever explicitly compared the database to code. North beat us to the punch. Well done, sir. Way to call it
like it is
like it should be.
Now that we’ve jumped on North’s metaphoric bandwagon, our VP of product and my co-founder Pete Pickerill has coined the phrase, "Commit it and forget it." (© 2016, for the record.) I love that phrasing too. Why shouldn’t we be able to check in SQL scripts, just like code, and ensure that they will automatically get tested and deployed? That’s the purest form of the automation that North posits is a necessity for treating the database as code. The portal and process for checking scripts and database changes into source code control should be easy enough for a developer to handle, not just a DBA. We’re talking about giving DBAs some serious relief here, as well as the ability to actually share and delegate responsibility for the first time in decades.
That’s where our Datical DB Rules Engine excels–see it in action here. Once developer SQL scripts are pulled into the data model for automated validation, as long as the Rules Engine doesn’t raise a flag, a DBA doesn’t even have to touch it again. Period. Stop. End of conversation.
North (combined with Pickerill) is on to something here, and IT organizations should take note. It’s simple but eloquent: Treat the database as code, commit it and forget it.
Opinions expressed by DZone contributors are their own.