Over a million developers have joined DZone.

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?

· Database Zone

Sign up for the Couchbase Community Newsletter to stay ahead of the curve on the latest NoSQL news, events, and webinars. Brought to you in partnership with Coucbase.

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.

The Getting Started with NoSQL Guide will get you hands-on with NoSQL in minutes with no coding needed. Brought to you in partnership with Couchbase.

database ,automation ,development ,devops

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}