The Crucial Role DevOps Plays in Change and Configuration Management


Agile's core principles may have been originally intended at the software development, but the concept of DevOps has shown that agile's benefits can be experienced by a much larger audience. Collaboration between these two departments benefits just as much as anyone.

Today’s competitive landscape has pushed the need to be agile, and accelerated the pace of business system changes, while making the need for control in IT greater than ever. Today’s IT Operations organizations are experiencing anxiety, as they deal with an overwhelming amount of changes being “thrown over the wall” to their counterparts in Development . These changes need to be accepted and deployed, while frequently IT is  unaware of the background, content and impact. At the same time Operations introduces changes from their side – on the infrastructure - that can impact the application layer, leaving  developers both unaware and not cognizant of the  impact these changes have on further development and testing. So, while IT Operations is actually charged with maintaining stability of the working environment, the introduction of any these types of changes creates risk. The emerging DevOps discipline can show its real value in this arena, bringing these two parts of the organization together.

Change Drives DevOps
One of the main drivers for DevOps is change. Some years back, for application updates you may of had one change a month, then you spent a few weeks stabilizing the application in production, Going back and forth from operations to development and back. This was considered a necessary evil.  But if you have 10 changes per day, it becomes difficult. If you have hundreds per day it is impossible. Organizations feel the need to increase speed and be able to react instantly to changing business requirements.

Today, we are talking about continuous integration and agile development practices leading to daily changes. Systems are growing, and are moving out of the traditional datacenter environment, going into cloud and so on. Disconnect between Development and Operations becomes intolerable. How can the operations manager face daily changes, and then also expect to support a working system? With this level of dynamics taking place, the system isn't stable and no one has time to deal with this type of issue. Naturally, as agile change becomes a regular part of the life of IT, this situation requires special treatment, and the changes need special care.  The best way to handle these changes is by having its own team, DevOps. They canescort the change throughout its lifecycle - from inception to deployment as well as follow the changes that Operations makes to the infrastructure communicating the impact to Development.

IT Without DevOps is a Disconnected Organization
Changes turn into hot potatoes passed between the arms of the organization. Of course, with a hot potato the risk is always that someone will drop it. For the Operations side, there might be other priorities, that come before requests from the Development organization, service managers, release managers or others who decide to deploy. First of all, who then determines the priorities of changes and related actions?

  1. Operations doesn’t know anything about a change, never participated in the definition of the change, and doesn't really know what it is, except for a set of instructions. It can be implemented. It could fail,without an understanding about the change and its implications. If it fails, the reasons won’t be apparent to Operations , and this is a problem.
  2. At the same time, Operations sends their feedback over to Development and to QA, saying which changes didn't deploy properly, and this feedback  should be reflected in the architecture view, the application code and in the QA environments.
  3. Development can claim that they tested it and performed QA, and saw that it works fine in their test environment. As far as Development is concerned, the application works without implications from the change. They can say to Operations, ‘It’s a problem with your infrastructure, or with the way you deployed it.’

Then the typical finger pointing starts, with both sides saying, ‘Not my problem, it’s your problem,’ wasting a lot of time in the release process.

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.