Three Proven Ways To Enable a DevOps Culture
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
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.
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!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)