Won't somebody please think of the systems?
What is the goal of DevOps? If you ask a lot of people, they say “Continuous integration! Pushing functionality out faster!” The first cut at a DevOps Wikipedia article pretty much only considered this goal. Unfortunately, this is a naive view largely popular among developers who don’t fully understand the problems of service management. More rapid delivery and the practice of continuous integration/deployment is cool and it’s part of the DevOps umbrella of concerns, but it is not the largest part.
Let us review the concepts behind IT Service Management. I don’t like ITIL in terms of a prescriptive thing to implement, but as a cognitive framework to understand IT work, it’s great. Anyway, depending on what version you are looking at, there are a lot of parts of delivering a service to end users/customers.
- 1. Service Strategy (tie-guy stuff)
- 2. Service Design (including capacity, availability, risk management)
- 3. Service Transition (release and change management)
- 4. Service Operation (operations)
- 5. Continual Service Improvement (metrics)
Let’s concentrate on the middle three. Service transition (release) is where CI fits in. And that’s great. But most of the point of DevOps is the need for ops to be involved in Service Design and for the developers to be involved in Service Operation!
Service Transition
Sure, in the old waterfall mindset, service transition is where “the work moves from dev to ops.” Dev guys do everything before that, ops guys do everything after that, we just need a more graceful handoff. DevOps is not about trying to file some of the rough bits off the old way of doing things. It’s about improving service quality by more profoundly integrating the teams through the whole pipeline.
Here at NI, continuous integration was our lowest ranked DevOps priority. It’s a nice to have, while improving service design and operation was way, way more important to us. We’re starting work on it now, but consider our DevOps implementation to be successful without it. If you don’t have service design and operation nailed, then focusing on service transition risks “delivering garbage more quickly to users, and having it be unsupportable.”
Service Design
Services will not be designed correctly without embedded operational experience in their design and creation. You can call this “systems engineering” and say it’s not ops… But it’s ops. Look at the career paths if that confuses you. Our #1 priority in our DevOps implementation was to avoid the pain and problems of developing services with only input from functional developers. A working service is, more than ever, a synthesis of systems and applications and need to be designed as such. We required our systems architect and applications architect to work hand in hand, mutually design the team and tools and products, review changes from both devs and ops…
Service Operation
Services can not be operated correctly if thrown over the wall to an ops team, and they will not be improved at the appropriate rate. Developers need to be on hand to help handle problems and need to be following extremely closely what their application does in the users’ hands to make a better product. This was our #2 priority when implementing DevOps, and self service is a high implementation priority. Developers should be able to see their logs and production metrics in realtime so we put things like Splunk and Cloudkick in place and made their goal to not be operations facing, but developer facing, tools.
The Bottom Line
DevOps is not about just making the wall you throw stuff over shorter. With apologies to Dev2Ops,
 |
 |
Improvement? I think not!
To me the point of DevOps is to not have a wall – to have both development and operations involved in the service design, the transition, and the operation. Just implementing CI without doing that isn’t DevOps – it’s automating waterfall. Which is fine and all, but you’re missing a lot of the point and are not going to get all the benefits you could.
the agile admin 
Pingback: A Smattering of Selenium #60 « Official Selenium Blog
I thought devops was those operations supporting development. Which would put CI pretty high on the list. But it sounds like your definition of devops is as a barrier (gateway) between developers and the production system.
Two problems. One, DevOps is not Ops “supporting” development. It is development and operations jointly creating a service, jointly delivering it, and jointly supporting it to end users. There are a host of mutual responsibilities there, and the viewpoint that ops is just there to carry water for devs is a significant part of the problem as a barrier to true collaboration. And like I say several times in the article, CI is a part of devops, and might be one of the top concerns in some shops, but a) DevOps is not just CI, b) CI may be more or less important of a part in some environments, and c) CI without the other parts of DevOps can set you up for failure
Two, I’m a little confused by your last comment, I think you misunderstand the diagrams, I cribbed them from dev2ops to illustrate that just adding CI to an otherwise firewalled process doesn’t help much. A real picture should have both people on both sides of the wall. But yes, in many places ops is the gatekeeper of production in one way or another; there are a variety of legal requirements making this necessary in many large shops (separation of duties). This division can be fulfilled by a CI system that has the correct approvals and logging in it. No one’s saying CI is bad, you don’t need a person in the middle – but moving to CI is not necessarily the most value, is not necessarily going to reduce your production defects, make your apps scalable, etc. It’s the same naive view that says that if you have continuous build and work in 4 week chunks, you must be doing agile. Without sufficient testing discipline, for example, you’ll end up worse off in many cases.