Adventures of a wannabe geek!

Ranting within

Is SQL the Barrier to Continuous Deployment?

When it comes to the step between continuous delivery and continuous deployment (automated release of every good build), then the barrier I hear most often is automated deployments work fine until we have database changes.

Can we be confident in saying that database deployments are the only barrier to continuous deployment? Probably not the only barrier, but there are a large part of the puzzle. There will be other factors, e.g. audit regulations regarding sign off of releases etc., but I don’t think I would be frowned upon by agreeing with this statement.

I know there are many great tools out there will will help us overcome sql changes. Redgate’s Sql Compare can take 2 schemas and compare them to create a change script and a rollback script. This can be controlled by a CI tool. Others do a similar job, but Sql Compare is one I use regularly. Sql Server management studio can also be manipulated very easily via msbuild. So I can assure you it is very easy to automate sql deployments. But it scares a lot of people as they are worried they will kill their database. This is not a fear that is uncalled for if I am truthful.

Since there is the fear of damaging the database, some companies who are already doing continuous deployment will actively ‘skip’ a deployment when sql changes are involved. This involves using VCS hooks. A typical hook would be the presence of a commit message, e.g. #Skip Deployment. This would then let source control / CI server know to handle the commit without the need for a deployment.

Back in late 2010, I was introduced to the concept of NoSQL databases. This is essentially any type of store that doe not use a relational model. I have been looking at NoSQL more and more and have recently pondered ‘how easy would NoSQL based systems be to include in a continuous deployment system’?

I thought the answer was that NoSQL was indeed the missing piece of the continuous deployment puzzle. If companies were only ever deploying code then that’s easy right? Things are never that easy though. I looked further and then thought that if data was held in a store (of any kind) in a specific structure then how could we retrieve that data if the structure changed with the next system deployment.

I asked Rob Ashton, a well know presenter of Raven DB, this question. Rob said that it wouldn’t work unless you ran some sort of data migration against the data structures or versioned them in some way. So, in essence it was a no! I’m not disagreeing with Rob by any means but I still think NoSQL systems have got scope built in to allow us to handle automated deployments a little easier. As part of our development task, we could write the migration scripts for the data. We would have to do this anyway if we worked in a sql world. I’m a coder, not a sql developer. Therefore I would be a lot happier writing code migrations rather than sql migrations. This means I would also be a lot happier about deployments where only code changes were involved.

I have not had time to try this approach as I am not skilled by any means in using NoSQL. So in essence, this is a theory but I am confident it has some wheels. What do you think?………