DevOps Zone is brought to you in partnership with:

Matthias Marschall is a software engineer "Made in Germany". His four children make sure that he feels comfortable in lively environments, and stays in control of chaotic situations. A lean and agile engineering lead, he's passionate about continuous delivery, infrastructure automation, and all things DevOps. Matthias is a DZone MVB and is not an employee of DZone and has posted 38 posts at DZone. You can read more from them at their website. View Full User Profile

Three Proven Ways To Enable a DevOps Culture

05.27.2011
| 6188 views |
  • submit to reddit

To deliver customer value rapidly, it’s important that developers and operations work together closely. There are certain traits of organizations which make it either harder or simpler for both to collaborate. In this post, I want to show you three examples which make DevOps simpler.

Shared Infrastructure

Awareness is one of the key factors to drive collaboration. Only if I know what’s going on am I able to identify possibilties for working together. It’s mandatory that developers and operations both have a common set of tools e.g. for monitoring, version control, or ticket management. Only by sharing information about “What’s going on?” can collaboration emerge. You could start by giving developers access to operation’s monitoring tools and give them read-only access to the production servers to enable them to debug problems on the live systems. And, you could give sys admins read-only access to the source code repository to enable them to find clues about what might cause issues in production.

Frequent, Small Releases

If you ship small increments, you contain problems within a very small change set and reduce risk of failure. Small changes are more easily communicated, understood, and evaluated by all parties involved in web operations. If your goal is pushing out features most appropriate to the business (and not being dependent on release cycles), you force your developers and operations to work more closely together.

Shared Responsibilities

Stop the blaming game. Don’t introduce audits and SLAs just to be able to blame someone if something fails. Instead, use them to communicate expectations and results of discussions. Only if you share responsibilities for code quality as well as operations metrics like speed or availability, can you work more productively.

By concentrating on these three areas you’ll be able to improve the frequency and quality with which you deliver value to your customers. Has it worked for you? Or have you had bad experiences with one of those topics? Share with us in the comments below!

References
Published at DZone with permission of Matthias Marschall, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Muhammad Faiz replied on Fri, 2012/04/13 - 8:18am

I have found that frequent releases are a key component to keeping our operations team happy. Small changes can be easily verified, easily tested, easily fixed, and easily reverted if necessary. Our operations team is always concerned when we get a larger set of fixes going out at the same time.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.