Devops Protocol Definition
Wikipedia has an elaborate definition of protocol. We could re-write it for Devops like this:
The term [protocol] refers to the set of rules, procedures, conventions and ceremonies that relate to relations between discrete departments. In general, [a] protocol represents the recognized and generally accepted system of international, inter-departmental courtesy.
I see a lot of value in collecting such a set of rules, procedures, conventions and ceremonies to convey the fundamental ideas of Devops.
Devops Protocol Examples
- Developers carry pagers after releases: to ensure that developers get unfiltered and timely feedback about the quality of their work, it’s a good idea to have them carry pagers after releases containing their code. If it’s only the admins who need to get up in the middle of the night and sweat the outages produced by a new feature, it will lead to blaming games instead of cooperation. Instead, feeling the same pain and solving problems together will grow a strong bond between everyone involved.
- Log files are accessible to everyone: a developer can only debug a problem if he knows what’s going on. He needs to see how the code behaves in production. If you want to foster collaborative troubleshooting instead of finger pointing, giving everyone access to the production logs is a good idea.
- Everything is under version control: this is most likely already true for all the source code. But it should also be true for server scripts and configuration files. Whatever you run or put on a production box should have a history and a well defined place where anyone can have a look at it.
Building a Devops culture is a challenge, but if we start sharing Devops protocols, maybe we get more dudes who understand what Devops is really about: Collaboration.
Which Devops protocols work for you? Please share them 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.)