What Does DevOps Look Like?

If we're going to concentrate on IT Operations' role in a DevOps organization, it's useful to think about what a DevOps project actually looks like. What, exactly, is IT Operations providing? What capabilities does the organization need? So let's take a super high-level look at a DevOps-style project, and what it involves. We'll dig deeper into various pieces of this in the remainder of this book.

HOWEVER, I want to emphasize that you can't achieve DevOps entirely within the Operations team. DevOps is about thinking of your entire system (a very Deming phrase), from the people who write the code to the people who use the code, and everything in between. The Operations team has a contribution, as do many other teams and roles.

There are a lot of people talking about DevOps these days, and so there are a lot of different opinions on how a "DevOps project" should work. In looking for a concise, high-level explanation, I was most taken by a description of how Spotify organizes their IT efforts. While a lot of that description focuses on how the software developers are organized, the interesting bit for me was that their IT Operations' team main job was to create units of automation so that the developers could deploy code to test, QA, and production on their own. Operations, in other words, facilitated a safe and managed connection between developers and application (service) users. Ops more or less arranged things so that Ops itself "got out of the way," within a managed and controlled framework of activity.

This is the heart of DevOps, and if it makes your heart skip a beat, then you have to remember that DevOps is a very different philosophy than what you've done before. In the past, QA and Operations were usually separate teams within IT. Code went from developers to QA and back again, until QA passed it, and then Operations worked on deploying the code. The intent of having these "gates" between roles was to make sure nobody did anything they weren't supposed to, like deploy unapproved code to production. This created several distinct problems:

• Developers became lazy. They knew QA was checking their work, and so they concentrated less on producing quality code. QA, in turn, had to take their job more seriously, and so organizations started investing heavily in QA automation. As a result, the organization spent a ton of time and money enabling developers to do their jobs less well. This was good for nobody. Nobody's saying that testing isn't important, just that the dev-versus-QA approach hasn't been massively beneficial or efficient.

• The organization developed a natural us-versus-them attitude, which is probably how your organization behaves right now. At the very least, it's no fun. After all, we're all supposed to have the same goal - delivering software and services to users - so we're supposed to be in it together. In the worst cases, the inter-departmental rivalry becomes truly toxic, making for an unpleasant and unproductive workplace.

• Operations made mistakes simply because they didn't write the code, and developers had little incentive to write code that was easy to deploy, manage, or monitor. Developers threw the code "over the wall" and Operations just had to deal with it - increasing the tension between the departments.

All of this conspired to create something that is essentially the antithesis of DevOps. Software releases are slower, because of the implacable march of code from development through to QA, through to production. Operations basically lives in fear of new code, because they know little about it, and it wasn't necessarily designed with ease-of-operating in mind. Slower releases meant more pressure to pack more features into those releases, so each release became a "win," which simply made the process even worse.

DevOps, by contrast, envisions application and service delivery than constantly pushes small, incremental updates to users, with a minimum of operational overhead. Smaller releases are easier to code and test, and with the right approach, safer to push into production on an ongoing basis. But in order for all that to happen, everyone has to work together. The hard line between developer and operations has to become fuzzy.

In a DevOps environment, things work differently. Here's a super-simplified look: 1. Developers code, and check their code into a repository. 2. At some point, the repository's current code is pulled and built into an application. 3. Tests - usually automated, and created by developers - are run, including individual models, integration tests, and even user acceptance tests. 4. If the tests succeed, the build is deployed automatically into production (or at least into some deployment cycle). 5. User feedback is collected, feeding the next iteration of the cycle. Return to step 1.

Parts of this can be extremely automated, and parts - like user acceptance - may still be done manually by human beings. The point is that you create as few barriers as possible between coder and user. That does not mean there are no checkpoints along the way - that's what testing is all about, after all - but you don't put one part of the IT team in charge of "stopping" another part "from doing something stupid." DevOps, as a philosophy, implicitly means that you trust your team. If you don't trust someone on your team, you have an HR problem, and you should educate them so that you do trust them, or fire them and replace them with someone you do trust. If your company "would never let a developer's code get into production without thirty other people approving it first," then you can't do DevOps. That's what I was writing earlier about management buy-in being the first step.

The idea behind DevOps is, as I've noted, to smooth the path between coder and user, so that small, incremental application updates can be pushed more or less all the time. As user feedback is received, coders respond and updates are pushed.

Incidentally, here's a really great explanation of what DevOps is - and what it isn't. It's a long article, but it's worth reading, and you'll notice how much management buy-in is needed for all of those things to work.

So, for the purposes of this book, we need to look at some of the things needed to make step 4 happen, and a little bit about what's needed in step 3 as well. Again, we're going to focus mainly on processes and practices; you'll definitely need some technology to implement those in real life, but the exact technologies you choose will depend on your specific environment, so we'll keep this a little more abstract for right now.