Submitted
By Dipankar Ganguly
New to some, old hat to many, and a source of puzzlement to more than a few, there is no doubt that DevOps is a multi-layered term meaning different things to different people.
Puppet Labs’ 2015 State of DevOps report highlights this point and addresses how different folks interpret the term based on their areas of expertise, comfort, or skepticism for the approach. For example, many describe it as “interaction between development and operations,” while others think of it as “cultural change in IT.”
Here we discuss the inspiration and culture of DevOps today.
The Inspiration Behind DevOps
The DevOps movement, which started around 2008, took its inspiration from agile practices, but it’s critical to understand that it’s not the same as agile or another advanced form of agile practices.The key philosophy behind the movement was to reduce the gap between developers and operations, which are the two fundamentals of building and deploying software that traditionally have been looked at as two separate teams tasked with the same job of building one piece of software.
Over the years, the scope of DevOps has expanded into a set of advanced and evolving engineering practices, team reorganization and attitude, and agile processes that allow organizations to build and deliver resilient and rapidly changing software without compromising quality. From tasks such as software deployment and troubleshooting to quality assurance and security management, operating in a DevOps way is emerging as the new way to do business in IT.
DevOps is for everyone—large and small, startups, and well-established enterprises. Apart from a measured and continuously improving set of engineering and agile processes, DevOps enables continuous delivery, which focuses on what is ultimately most important, shorter cycles for putting high-quality software into the hands of end users. Continuous delivery relies on better collaboration, integrated processes, and the comprehensive automation of builds.
DevOps Is a Marathon, Not a Sprint
The real value of DevOps can be only realized when the different parts of the movement are understood and implanted in a planned fashion. Extending and improving agile and engineering practices fueled by fundamental changes in people culture is essential. Some of the basic steps in starting the DevOps roadmap revolve around the following.
Eliminate silos across your organization and build a self-contained team embracing dev, test, build, and ops focusing on a one team/multiple role paradigm.
Enable cross-team collaboration leading to shorter feedback loops and encouraging experimentation and innovation.
Automate build, test, and deployment processes.
Integrate and optimize the engineering delivery pipeline via correct selection and integration of tools, relevant metrics, and point-to-point traceability.
Accelerate release cycles via better sprint release planning and improving push-automated and gate-centric release promotion processes.
Use continuous testing to test and monitor earlier in the development process and test in production.
Adopting DevOps has not been easy, or for that matter cheap—not in terms of the cost of tools or people per se, but in terms of the effort, rigor, and clarity of organizational vision that is required to embrace this change fearlessly. The key reasons organizations struggle in adopting a DevOps path is because of the transformational change an organization will need to undergo to embark on the journey. It can’t happen overnight, and certain pieces of the puzzle need to be in place before organizations should even begin the journey, particularly eliminating silos and encouraging cross-team collaboration and use of continuous testing.
How do you know when your environment is optimized for DevOps? The maturity model below can help measure the path of development from three key perspectives—process, automation, and collaboration.
Assessing DevOps Maturity
The table below illustrates five levels of DevOps maturity commonly referenced in the industry and a suggested three-pronged approach—based on experience, for benchmarking maturity at each stage. For example, if the project is heavy on using manual processes for development and deployment, and releases are infrequent and monolithic, then DevOps transformation will necessarily include a lot of steps and the journey will be longer. If the team(s) are currently practicing agile methodologies and the culture is one that embraces automation and collaboration, then the starting point in the journey is much further down the road and the transformation will be less complex.
The path to DevOps maturity consists of a number of steps or smaller transformations, each of which will serve to improve the flow of value through all the development/test/deploy processes and bring benefits to the business at each successive stage. Realize, however, that the people part of the equation can often take more effort than the process or tools.
Leaders need to understand the types of skillsets and talents required to build an ideal DevOps team, which can be another major challenge.
Change Happens
Ultimately, change has to happen across the board—from the top down and sideways and forward. DevOps involves creating slow and steady cultural shifts within the team and organization as a whole. It takes time and will continue to evolve and change over the years. In fact, no organization may ever be in a position to truly say, “we are DevOps now!”
Dipankar Ganguly is the chief engineer at Ness.
Source: Puppet Labs’ 2015 State of DevOps Report
