The basic idea and principles about DevOps – adapted with the friendly permission of Udo Pracht. Udo has a lot of German material on devOps and mediation in IT. Check it out at menschenundit.wordpress.com. There you can also find the original article.Get PDF
|This 1-pager is part of “Skills for successful Product Owners”|
Content of the 1-Pager:
In modern IT companies there are often two sides: agile software developers, using processes like Scrum with a high flexibility on the one hand, and system administrators responsible for the stable operation of the IT, using techniques focusing on stability of operations like ITIL.
Or, set in phrases, you have “release early, release often” vs “never change a running
Building bridges between these two worlds, between developers and administrators, helps solving this problem. By establishing devOps (from DEVelopment + OPerationS) principles a company can bridge these gaps.
Developers + Operations = DevOps
Release often. Releasing often is a core requirement of agile development, and thus is a must for processes or products relying on software development. Also, frequent releases lead to smaller changes in each iteration which makes deployment easier for operations.
Developers and administrators respect each other. They both work towards the same goal: running a successful business. Developers and administrators cooperate and exchange within teams and meetings. Developers understand the operating
requirements, and administrators understand the basics of the code. This broad perspective goes hand in hand with an open mind towards communicating with “the others”.
devOps oriented team members are interested in new technologies, methods, languages, tools – and willing to learn them, to adopt those. This strongly implies the willingness to learn from “the others”. And it also means that new technologies (Cloud, Virtualization,…) are integrated where it makes sense and where it helps the processes.
Developers and administrators automate as much as possible of their daily work – using the same tools in their processes. For example, both deploy via the same Foreman, both manage configuration with shared Puppet recipes, the source code is managed in the same Git, and errors and bugs are tracked in the same ticket system.