“I’m a DBA for a large healthcare firm here in the US. You’d have to put a gun to my head before I let my developers run automatic database deployments through to production without me checking the release first“.

I had just explained our ideas for running continuous integration, automated testing and automated release processes for SQL Server database modifications, and this wasn’t quite the reaction I’d hoped for. Was the idea of continuous delivery for the database really such a pipe dream? Since then, we’ve been working hard to try to understand this conflict.

That DBA was thinking about continuous deployment. But continuous delivery and continuous deployment are very different beasts. Continuous delivery is about always being ready, at any point in time, to release your software. Continuous deployment, on the other hand, is about having such confidence in your automated testing and deployment procedures, that you automatically release a change straight from development into production (via other test servers of course!) without human intervention.

For a healthcare DBA, continuous deployment for the database is a pipe dream, primarily for compliance and security reasons. However, Continuous Delivery practices can really help, in such environments, to ease the often-painful path to shipping software. It means that the development team implement extensive and automated integration testing, with early and regular deployments to production-like environments, with approval gates for DBAs and compliance staff to check prospective releases long before they need to go to production.

Still, even two years on from hearing the “put a gun to my head” declaration, we’re still seeing relatively few customers practise full continuous delivery for the database, a very small number practising continuous deployment, and a far higher number still not doing either.

So what’s the biggest stumbling block? Is it the available technology and tools, lack of time, no management buy-in, or something harder to pin down, such as team processes? Of course, it’s probably a tangled web of all of these things. The only way forward is to unpick one knot at a time.

From our experiences at Red Gate with continuous delivery, and from speaking to our customers, these are the knots to tackle first:

• Get buy-in from the whole team – make sure the business fully understands the benefits of being ready to deploy at all times, and the processes required to get there. Without this your change program will fall flat before it has even started
• Get the database, kicking and screaming, into source control – and your team regularly checking in changes
• Fully automate your testing and deployment processes – this will still require a lot of investigative work (and perseverance), but the tools are getting stronger all the time

There is no simple short-cut to implementing continuous delivery. For most of us, it is a long-term goal that requires many step-wise changes; however, it is no longer a pipe-dream. Is it worthwhile? I’d say so. Being able to ship database changes frequently and safely provides a number of benefits to any organisation, however complex its systems happen to be. That DBA won’t need a gun to his head since the checks, investigations, and tests that precede deployment will be made far easier to perform.