DBAs: the world is out to get you.
I know that those pesky devs are actively trying to make your life difficult by constantly devising ever more insane ways to trample all over your precious database. I know they don’t care enough about the hallowed data.
Some go as far as calling you paranoid – and I say “let them!” If I had a database I cared about I would want a paranoid control freak looking after it who stopped at nothing to keep every bit of my data safe and I would arm my chosen guardian appropriately for their task (more on that in DBAs: Relax! (Part 2) where I’ll be discussing the mechanics of automatic machine guns).
But…
When something new comes along – even if it sounds scary – it isn’t always so terrible once you understand it. Please just give me a few minutes of your time and let me tell you a little bit about what Continuous Integration (CI) actually is, who it is for, and why CI is an uncompromising and paranoid, control freak that is hell bent on keeping bad code away from your database.
DBAs, meet CI… I really think you two would be good friends if you gave each other a chance. It might also offer an opportunity for you (DBA) to work closer with the developers. You could help them set it up? Afterall, the best way to protect yourself from the code those pesky developers are throwing your way is to work with them – not against them.
Continuous Integration
I was inspired to write this post at the first SQL in the City workshop. A colleague of mine (Tom Austin) and I ran a training program to teach a dozen or so database professionals how to set up automated builds for their database. (Automated Builds being the first step on the ladder towards Continuous Integration.) One of the guys in the front row was a charming American DBA who had sacrificed a day out of his UK vacation with his family in order to attend the training. When we told him we were going to build a brand new database from source control every time one of his five developers committed a change (several times a day per developer) he scowled:
“You can’t do that. I have a terrabyte sized database. I can’t go building that every 10 minutes. You are crazy!”
When I explained that we were only talking about the schema and lookup data he took a breath and said:
“OK, but now I still have to manage a huge number of databases. That’s simply impossible”
No – we told him. We destroy the database immediately.
“But you can’t deploy and destroy databases like that… You just can’t…”
We are only building it to check that our source code has accurate syntax and that there are no invalid references that would cause a problem down the line. Once the database is built we do not need it any more. This is different from deploying a change to a persistent database – very different.
Oh… and yes, this does mean that you do need to allow your developers to build and delete databases… but this could be on an isolated server that can burn to the ground for all you care. In fact, that’s kind of exactly what it’s for. This is your canary. If it burns to the ground that’s a good thing – you just found a potential problem fast, before it touched any important servers. Would you prefer to discover that problem on production?
In fact, the line that really made our friendly DBA understand the point of CI, and the thing that put his mind truly at ease was this:
CI is not even intended for DBAs… It’s a tool for developers. It should be managed by developers and you should give them the freedom to do this. Yes – they are building and tearing down databases fast, on an automated basis, but these are worthless databases on an isolated server that you do not need to concern yourself with from an administration point of view.
The whole point is that developers will learn immediately when they make a breaking change. The CI server is helping you because it is teaching the developers not to do stupid stuff that breaks databases. In fact, as soon as they make a mistake it publicly humiliates them by sending error reports around the team with all the details about what dumb thing they just did. As it happens, developers actually love this as it helps them to write clean code. You should be embracing this and encouraging it – not getting hung up on the fact that your developers are building and tearing down databases so frequently.
The real benefit, however, is that CI provides the framework for your developers to build up an automated testing process. Perhaps you would like to get involved in this? Help the developers to learn what they should and should not be doing. Help them write some tests to keep them on the clean and narrow – and to hit them with a giant and public clue bat every time they fail one of the tests you wrote together? If you want ideas about the sort of tests you could write check out SQL Cop. Although this stuff gets really valuable when you start writing tests specifically for the functionality that you expect from your own database.
And what is even better is that we can start to automate the creation of deployment artifacts. These could be whatever you like, but the point is that they will contain all the information that you or anyone else will need to deploy the code in a reliable, repeatable and consistent format. Sounds like a dream? Well it is only possible in two ways… Either you can persuade humans to follow a drawn out, boring and repetitive process – or you can ask computers to do it.
Guess which works more often?
EDIT: Don’t take it from me… Meet James Dorame
Given that he has now publicly written about this event, I don’t think our American friend will mind me dropping his name into the post. If you would like to read about Jim’s reactions to the same workshop directly from him, go ahead:
Continuous Integration (for the database) is really not that scary. By Jim Dorame.
In my next post…
… I’m going to tell you why automated deployment isn’t actually scary either.
Now I know what you are thinking:
“Who is this guy? He just lost all credibility with me because automating the deployment to my production server truly is terrifying!”
Well this comes down to what we mean by “Automated Deployment” and the very important difference between “Continuous Delivery” (which is entirely un-scary if done right) and “Continuous Deployment” (which even terrifies me).