An Agile Introduction to DevOps, Part IV: Ship Ahoy!

this is the fourth part of a series on agile and devops.  part i  ,  part   ii  , and  part iii  should be read first!

yippee! we now have tested software...

...which means nothing if we don’t get it to actual customers. so, let’s talk about shipping to production. like everything we discussed until now, automation lowers the risk of manual errors and saves time.

even deploying to production has to have some kind of method to it. we’ve already discussed  version management  , but that was more internal, and therefore in our control. going out to the wild means we’re going to lose control, so we want to minimize the risk.

shipping along side-by-side

it used to be that “side-by-side” meant two versions running at the same time. things have become more complex since.

first of all, we need to define a version in deployment. it’s easier if we think in an “all or nothing,” binary way; as in, whatever i release, the version number was just incremented.

however, is that always true? what if i open a feature just for new zealand? which version am i running right now?

like with doctor strange, we’re now adding multiple dimensions to our situation. since we can deploy to multiple servers, what happens between starting the deployment on server 1 until it’s fully replicated and deployed to server  n  ?

the real issue is not identification but reproduction. if something happened during the process of deployment and we want to reproduce it, we need to know the conditions. it used to be that version numbers were all we needed. that is not so anymore, and devops methods need to answer both identification and reproduction numbers.

versions used to be helpful when something went wrong. if that happened, we would simply roll back to a previous version. well, if we don’t have a definition of what a version means, how can we roll back to one?

in fact, imagine 500 of your colleagues committing code all day, every day. now, it seems that yesterday’s deployment needed a revert. however, that means reverting everything else the guys have written. do you start separating wheat from chaff?

you don’t. organizations that understand this stopped rolling backward, and just push the fixes forward. that’s a devops understanding of how the systems work and how to manage them.

in order to do that, we need the ability to automate this kind of volume to production in a safe manner. enter continuous delivery, another method from the devops school. cd is ci’s big brother. it’s an extension of the early cycles of automation (build, developer tests, system tests) and builds on the capabilities of deployment and environment management.

continuous delivery is not just about automation. it’s about minimizing the risk of something bad going to production, and raising early warning flags before it does.

we may be “done,” but we're not “done-done.” software these days doesn’t just end when it’s in production. the devops methods reach beyond that. next time, we’ll talk about the afterlife of software.