As a Configuration Manager, I have to ask two questions: What is DevOps, and why should I care? According to Wikipedia, that fount of all knowledge these days, “DevOps is a set of processes, methods and systems for communication, collaboration and integration between departments for Development (Applications/Software Engineering), Technology Operations and Quality Assurance (QA). It relates to the emerging understanding of the interdependence of development and operations in meeting a business' goal to producing timely software products and services.”[1][2]

The primary reason DevOps seems to be gathering acceptance is that it tears down silo walls and lets divisions communicate their needs, schedules, etc. once again. This is done to accelerate the develop/test/deploy time and to allow Operations to get what they need when they need it. It is hard to remember that these silos, these walls, were put in place for these very same reasons. They were put in place to reduce the time spent communicating and to maximize the expectations (think requirements) needed before something was thrown over those walls.

The driving force behind this seems to be the logical progression from Continuous Integration to Continuous Deployment. The faster deployment frequency is, the less time there is for communication, mistakes, recalls and any of the other problems normally experienced in more classic development. In the figure below, it takes Development three tries to get a release acceptable to Operations and QA/QC may have to retrench to be able to do the second round of testing. Given enough time, this is not a problem.

In a more accelerated model with more rapid deployments, especially in the arena of Continuous Deployment, this takes too much effort and time. Automation is an assist, but the biggest payback is in the cooperation and coordination between the teams. In the figure below, notice that Operations is directly involved in the testing of each feature (or at least the ones that concern or affect them). The changes are smaller, making the overall test time quicker. Automation of regression testing allows objective insurance that each new feature does not break existing functionality. The combination of these accelerates the overall cycle without sacrificing quality. It also means that the number of rejections that actually occur by Operations is reduced and does not normally block other feature development and testing. Note that this only applies when Operations is actually a part of the corporate environment for a given product or component.

The Wikipedia article that “defines” DevOps includes the following diagram illustrating the interrelation between Development, Operations and QA. Please compare it to the other illustration of CM's interrelationship with Quality and Development.

Not surprisingly, there is a close resemblance. The biggest difference is that CM does not normally concern itself with Operations unless you include ITIL. Let us briefly address CM and ITIL. They utilize the same concepts and philosophy, but the tools used to implement them are different. ITIL has no problem in stating that they are from the IT and Operations areas and is intended to provide the consistency, versioning, problem and change tracking, and auditablity of both applications and classical configuration settings from acquisition through installation and configuration. CM, or more properly in this context Software Configuration Management, is intended to provide consistency, versioning, problems and change tracking, and auditablity of software at the source level from code creation through build, packaging and deployment.

So, back to the second question of why CM should be care? SCM should care since the Development portion of DevOps is essentially Agile development. Smaller isolated changes are made, are built using some form of Continuous Build, and go through a faster targeted suite of testing prior to deployment. At that time ITIL takes over and tracks how the deliverables are installed and configured as well as which environment(s) have been modified. The advantage of DevOps is that the deliverables do not need to be versioned again by ITIL. Ironically, other than this advantage, there will be very little change to either SCM or ITIL for some time. But we need to care so we can adapt and our organizations do. This is the same reason we cared when silos separated our organizations and CM was one of the few cross-silo teams that spanned them. And the same reason we cared when Agile came into vogue. We always care – at least when we have time to raise our heads up and see change coming.

References

[1] Wikipedia (http://en.wikipedia.org/wiki/DevOps).

[2] Some feel that Requirements should also be represented in this mix, others that this is already included in Development.

[3] DevOps Overview figure from Wikipedia (http://en.wikipedia.org/wiki/File:Devops.png) and is licensed by Rajiv Pant according to the Creative Commons Attribution 3.0 Unported license (http://creativecommons.org/licenses/by/3.0/deed.en).

[4] This is a revamped copy of a diagram previously used in The Business of Process Development (CM Journal, 2006/12/19, http://www.cmcrossroads.com/cm-journal-articles/7415-the-business-of-software-development) and Do the Right Thing (CM Journal, 2007/06/18, http://www.cmcrossroads.com/cm-journal-articles/8219-do-the-right-thing). The change was solely to combine QA and QC into a single bubble to more match the one for DevOps.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment