So we now have tested software, yippee! 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.
But 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, and 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.
But 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 server, 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 rather 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, everyday. Now, it seems that yesterday’s deployment needed a revert. But 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 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 not “done-done”. Software these days don’t just end when it’s in production. The DevOps methods reach beyond that. Next time we’ll talk about the afterlife of software.
| Reference: | Agile introduction to DevOps – Ship ahoy! from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
