BT

7 DevOps Habits

by Matthias Marschall on Sep 27, 2013 |

Glenn O'Donnell and Kurt Bittner, Forrester Research analysts, have published a report that describes how developers and operations see each other when working in isolation and offers seven habits of collaboration between the two. Their "The Seven Habits Of Highly Effective DevOps" are:

  1. Getting the two sides to talk to each other
  2. Taking an outside-in approach to everything
  3. Automating the build, test and release processes so they contain less human error
  4. Simplifying and standardizing the development and production environments
  5. Instilling a culture of systems engineering across both development and operations
  6. Implementing feedback and feed-forward loops
  7. Putting developers on the front line of support

They go into detail for each of them:

Getting the two sides to talk to each other

Talking face to face is a good way to learn about each other's daily challenges and struggles. This knowledge lets developers and operations put each other's actions into context and help each to understand the other better. While this should be pretty obvious, you can't get started with DevOps without this as a prerequisite.

Taking an outside-in approach to everything

It's pretty common for IT to see what's available and try to do the best with it. DevOps requires a different view: both developers and operations need to understand the needs of the business customers first. Based on those needs they should define what's necessary to satisfy them. This outside-in approach can lead to a fundamental shift in how developers and operations prioritize their work.

Automating the build, test and release processes so they contain less human error

It's important that both, developers and operations work together to automate the delivery process. Things like scalabilitiy-testing is the area of expertise of operations while testing business functions is what developers are used to test. On top of test automation they should use readily available tools for automating the infrastructure.

Simplifying and standardizing the development and production environments

The important point here is that you should enforce simplification on new systems, but only do as much as reasonably possible with your existing systems. James Governor recently held a DevOps expert panel where he asked whether it is necessary to simplify your infrastructure in order to be able to introduce DevOps.

Instilling a culture of systems engineering across both development and operations

Break down monolithic software into easier to handle modules - no matter whether you're automating your infrastructure or writing application code.

Implementing feedback and feed-forward loops

To ensure that your applications run smoothly, developers need feedback on how the applications are doing in production. And operations needs information on the required runtime environment as early as possible in the process.

Putting developers on the front line of support

Even though support task will take developers away of the more creative work it's important that they deal with the issues their code creating in production. Not only are they the ones who can fix glitches the fastest but also do they learn a lot about how their applications behave in production.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

DevOps by Derick Winkworth

This is a great list, but I'd like to add something to the conversation. Adopting a DevOps mindset even for the deployment of COTS software is still of great value to an organization. Another way to say that is, even you don't have a development team, you can automate deployment of purchased software using a subset of the tools/methods.

Getting two sides to talking by Dee Baig

Getting two sides to talk to each other is really important. It will give them a chance to talk about issues they face and they will both have a good understanding of what is feasible and what is needed. Talking will clarify the aims of the assignment and so the developer will be able to think of better ways to design the application.

DbaiG
Bolee.com

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT