If you ask 20 people the definition of DevOps you will get 12 definitions and 10 people that don’t know the term DevOps. I know, I asked, and yes I am aware that the numbers don’t add up (I got a couple it is either this or that). The definitions I heard generally were a mixture of concepts, activities and how those concepts and activities were implemented. More specifically, the definitions I received included a description of a technical operations group, an automation framework for delivery and an overview of a collaborative organizational structure. All interesting and all part of DevOps to a greater or lesser extent, but in general, the definitions were complicated. I am not a fan of complicated definitions. The simplest and most complete definition I have been able to mold from all of the conversations and personal experiences is:
DevOps is the exercise of combining operations and development personnel who participate together across the entire life cycle, from analysis to production support, leveraging Agile principles and techniques.
The problem DevOps is trying to solve is not a new problem. The development, delivery, support and maintenance of software (substitute product, service or application as you will) is time-consuming, costly and error-prone. Much of the impetus for embracing Agile and lean methods was to become more responsive to development’s customers. DevOps is a representation of the spreading implementation of Agile and lean techniques and principles across the entire organization. The basic goal of DevOps is to deliver functionality faster and with higher quality. The Agile principle of being able to deliver functionality quickly either continuously or once per sprint requires that the processes needed to build, test and implement functionality need to be automated. You can envision DevOps as the intersection of three macro sets of roles: development, technical operations and quality assurance (testing). All three of the macro categories are needed to develop, deliver and maintain a product. In many IT organizations, these three categories are independent silos with different goals. The implementation of DevOps seeks to break down the silos through collaboration to deliver a single goal. Dominque Bourget of RSA said,“It seems that the DevOps groups are more oriented toward solving the problems of delivering more functionality and stability which is very positive.” Generating that benefit requires a change in how IT organizations both operate and manage themselves.
At a high operational level, DevOps requires the interaction of personnel and processes from technical operations, testing and development across the product life cycle. This interaction is more than having TechOps or testing personnel review and provide sign-off on deliverables that development personnel create. Increasing the delivery cadence requires automation build, testing and promotion processes. In the simplest terms, involvement and automation typically require a reassessment of how work progresses across the entire product lifecycle (including development, enhancement maintenance, support, and retirement).
Implementing DevOps requires synchronizing the tactical goals of organizations that often have different vested interests. Conflicting goals can include: development – speed to delivery, technical operations – environmental stability, and QA – quality. Increasing collaboration by including all parties in team membership and then using Agile techniques such as self-organization are tools to break down walls. However, to make any of these techniques work at the team level requires empowering individuals and changing some of the time-honored hierarchal management structures to reduce the conflicting forces between groups.
David Herron, a colleague, provided a simple definition, “(DevOps is)…an integrated approach to software delivery that include process, tools, technology, resources.” As Paul Laberge of Wolters Kluwer pointed out when defining DevOps, “delivery includes development.” A simple definition might not be truly possible for DevOps without a lot of clarifications. What can be said is that DevOps forces any discussion of development into a broader discussion of how products are developed, delivered and supported in an effective and efficient manner.
Special Note: For just a little over two years I have been publishing content daily. In 2015. I have decided to post new content on Tuesday, Thursday and Saturday. On Sunday, I will continue to post the podcast announcement. I may, however, go back to posting daily at a moments notice!