This post leads on from DBAs: Relax! (Part 1) where I discussed Continuous Integration (CI).

In this post I’m going to discuss Automated Deployment, Continuous Delivery and Continuous Deployment and the very important, and often overlooked, differences between what these terms actually mean.

Let’s re-vist the workshop where Tom and I were teaching about a dozen SQL Server professionals how to set up the foundations of a CI process for their databases.

***

After a break Tom asked the group: “Can anyone tell me in your own words what Continuous Integration is?” An answer came back:

“Continuous Deployment.”

I can understand the reasoning. One of the important ingredients of Continuous Integration is the automated build, which could arguably be described as an automated or continuous deployment. However, Continuous Deployment actually has a very specific meaning.

Continuous Deployment

Continuous Deployment is actually quite scary. It even terrifies me. It is the idea that every commit should be automatically deployed to production… Yes – production. As soon as a line of code is committed to source control some automated tests are run and the code goes live.

Yeah – scary.

This is what Facebook, Etsy and Amazon do. The idea being that it forces developers to think hard about the production quality of their code and the necessary automated testing procedures and there is plenty of evidence that this works…

But yeah – pretty scary.

I don’t know if Amazon or Facebook actually do this for their databases. Ross Snyder, software engineer at Etsy, acknowledges that the database tier causes legal and technical problems on slide 42 here:

Maybe the day will come when Continuous Deployment is considered acceptable or normal or even best practice for the database? Maybe. In the meantime, let’s use the phrase “Continuous Deployment” very carefully.

So what is “Continuous Delivery”?

“Continuous Delivery” is not as scary as Continuous Deployment. In actual fact, I would go so far as to say that, while tough to achieve, it is basically common sense.

Continuous Delivery is the concept that you should always be able to deploy to production at the press of a button – whether or not you actually decide to do so. If you needed to you could make a one-line change in source control, trigger a CI build, run some automated tests, and get it into production, all within a few minutes. (Heads up, this means you are going to need to think about branching strategies. But I don’t want to open that can of worms right now!)

Wouldn’t that be better than making that hot-fix directly on production? The change is logged propoerly in source control and you have run at least some tests on it – rather than making an unlogged change on the live system and crossing your fingers.

If you wanted to you should be able to deploy 10 times a day, each time at the click of a button. In order that you have this ability you need to automate your deployment process because manually copying and pasting scripts from email attachments on remote servers through VPN and remembering to tweak that config setting as well as following the list of things on that excel spreadsheet while you wait for another person to do the doohickey with the widget simply won’t do.

Continuous Delivery is the natural extension of Continuous Integration: an approach in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button. 

http://www.thoughtworks.com/continuous-delivery (17th August 2014)

But let’s think about this for a second – I just dropped in the words “automate your deployment”. Let’s think about that a bit more. In the workshop our cheerful American tourist told us that automated deployment to production sounded super scary. I think we need to dig in to what we actually mean. And what better way to do this than by using a metaphor. I’m going to talk about guns. Specifically automatic and semi-automatic weapons – but let’s start with old fashioned gunpowder and flint-lock pistols.

If automated deployment was a gun…

Little known fact – the earliest battle where archaeologists have evidence of the use of hand-held guns is the battle of Agincourt in 1415, after a very early pistol was dug up on the battlefield. But this battle is not famous for the birth of the gun in combat, it is famous for the awesome power of the long bow. Why was the long bow so much more effective than a gun in 1415?

Simple: how long does it take to re-load?

Let’s think about how the owner of that pistol had to re-load it to take another shot. According to How Stuff Works it takes about seven steps, including delicately pouring gunpowder down the barrel and wrapping up the shot (bullet) in cloth. It may have taken more than a minute. At the end of which you have to hope that you have completed each part correctly (whilst under a fair amount of pressure) or the shot won’t even fire correctly.

Can you image any sane person standing in the middle of a bloody battlefield going through this process? Of course not – it is likely the owner of the gun had pre-loaded it with a single bullet that they could use once during the whole battle at short range, should the need arise. Loading a second shot would take too long and be too risky.

Beginning to sound familiar? How many careful steps do you need to follow in order to put your code into production? And are you doing this under any time pressure, such as a deployment window in the middle of the night?

Now let’s talk about automatic and semi-automatic weapons. The gunpowder actually is incorporated into the bullet casing so that the precise amount of powder needed for a perfect shot is included automatically. The weapon is built so that as soon as the first bullet is fired the second one is mechanically loaded into place far faster than a human could and with significantly more precision. The gun is ready to fire again almost instantly after the first shot is fired. And with fully automatic weapons all the soldier needs to do is hold down the trigger and the next shot is fired instantly. It no longer takes a full minute to reload – dozens of bullets can be fired in seconds.

Fast-forward to World War I, the fully automatic machine gun has totally revolutionised warfare. The strategy books need to be re-written. No-one would dream of going to the trenches armed with an antiquated long bow.

Let’s compare the tasks needed to reload a gun with the tasks needed to deploy code. The reason automatic weapons are so effective is that machinery is really good at completing those tasks in a reliable, repetitive and fast manner. So let’s think about whether a computer script or a human is better at copy paste, file transfer, editing connection strings and executing a script in a fast and consistent manner?

OK, so computers are better at the processes of deployment, in the same way that machinery is better at the mechanics of firing a weapon. In both cases, however, a human is required:

A human is often needed to pull the trigger of a weapon. An infantry soldier is capable of making moral and strategic decisions on a battlefield. Hold fire or shoot? Kill or take prisoner?

A human is often needed to press the deployment button. Is the risk of the deployment worth the value it promises? Let me review the changes the developer made. Afterall, as a DBA I understand SQL Server better than the developer.

And this gets to the crux of the issue, in the same way that a soldier pulls a trigger, a DBA should simply push a button. No complicated, risky, drawn out processes – a single click. Let the human decide when and what to deploy. Let the computer do the work.

As it happens, I often like to compare Continuous Delivery to a semi-automatic shotgun and Continuous Deployment to a fully automatic assault rifle. The simile isn’t perfect but hopefully it is close enough. The idea is that in Continuous Delivery our production deployment is a measured decision to deploy a specific release (or bullet) at a specific time by pulling a single trigger. With Continuous Deployment we are holding down the trigger on a fully automatic assault rifle and firing every bullet that is fed our way.

So what does Automated Deployment mean? In my opinion, it means the processes are automated – but the trigger is still up to you. Do you fancy a Continuous Delivery approach or a Continuous Deployment approach? When and how and who do you want to pull the trigger? That is your call, but hopefully you’ll agree that the days of going through the deployment process manually are numbered.

Perhaps one day technology and processes will develop to a point where fully automatic assault rifles are the standard weapon of choice for any scary DBA? In the meantime, the dev teams I work with at red gate each have a semi-automatic nerf gun by our sides at all times, ready to unleash our rubber tipped bullets on any developer who ‘breaks the build’, causing our CI server to fill our inboxes with error reports.

Oh – and we try to deploy an update to our customers once a week – on a Wednesday. Anyone in our team can do it. It’s a pretty simple process. My colleague, Chris, wrote a nice post about that last year.

P.S. Sorry @miss_embe for not asking you before using that awesome picture!