Two critical components of DevOps success
DevOps appears to be the right track for enterprise IT, but it’s a big change in the way things work and won't succeed without these two critical components.
ORLANDO, Fla. -- The convergence of software development and IT operations teams into the singular entity of DevOps promises more responsive software development, but traditional organizational barriers and inadequate tools threaten DevOps success.
More and more companies have moved toward the DevOps approach to get incremental software updates and patches into the hands of users faster and with less hassle than traditional software update cycles.
There is continued pressure to accelerate software releases in order to give an organization a more competitive advantage.
"It's how fast can you enter a new market or roll out a new platform," said Colin Fletcher, research director at Gartner Inc. during a session here at Gartner's IT Infrastructure and Operations Management Summit 2014 this week. Fletcher cited the pressures of competing in new markets, accommodating new computing platforms, and adding new product features or capabilities.
Traditional software development is a manual process that moves each product iteration from code to testing to release across areas of the organization that are often siloed. Even though DevOps is ideally supposed to alleviate barriers between developers, testers and other operational personnel, every organization structures their DevOps effort differently.
Developers and operations personnel see release management in very different ways, according to Ronni Colville, VM distinguished analyst at Gartner. Developers see releases as code, functionality and capability. Operations, however, see releases as a process or activity focused on moving code to recipients. Taken together, there are plenty of opportunities to drop steps or miscommunicate.
1. Avoid DevOps culture shock
Cultural change is critical for successful long-term adoption of DevOps and the overarching ability to release applications effectively. The first step is to establish a definition of DevOps that invokes collaboration between development and operations, which encourages operations to adopt software development methods, and utilizes a cloud infrastructure to physically test and deploy the code.
Any remaining traditional silos for development, testing, quality assurance (QA), integration, pre-production and production must come down because each silo slows the development cycle and can introduce unexpected problems.
This effort to better-integrate development and operations can benefit from merging team members. For example, add developers when discussing operations problem-solving or post-mortem release assessments. Conversely, add operations personnel in developer planning sessions. A collaborative combination of disciplines can improve working relationships and make the DevOps process more effective without any miscommunication that creates delays or oversights.
Such cultural changes are not easy. It takes shared organizational metrics so that developers and operations measure performance the same ways. Cultivating a team attitude helps focus on a single shared purpose rather than a narrow departmental goal. This sometimes involves rotating jobs or sharing knowledge. And Colville urged adopters to try things -- test creative new approaches to problems, take prudent risks, and learn from mistakes.
Cultural divides between operations and developers posed a serious challenge for Bob Jones University.
"We didn't have happy customers," said Terry Worley, senior manager of IT operations at Bob Jones, in Greenville, South Carolina. "I had to take operations and developers and get them to work together better. But I realized that culture is a beast and I can either sit in the chair or go slay it."
The benefits of cultural changes have proven worthwhile for Worley, who noted that after two projects using a revamped DevOps paradigm, developers did not want to go back to the traditional model of software development.
2. DevOps requires fully stocked toolbox
Beyond the cultural implications, organizations must rely on a variety of DevOps tools. For example, developers will use tools to write code, QA testers will use tools for release deployment, and cloud provisioning tools are needed to prepare the environment to move the new code to pre-production and production systems. This isn't a problem, Fletcher said, but it’s important to consider how the various tools interconnect and support the software's lifecycle.
There are numerous vendors already in the application release automation space. Vendors on the operations side include BMC Software, CA Technologies Inc. and XebiaLabs Inc. The developer side includes vendors such as IBM, Electric Cloud Inc. and Serena Software Inc.
There are also emerging vendors that specialize in developer workflow, build and release tools including Atlassian, CollabNet Inc., Rally Software, ThoughtWorks Inc. and OpenMake Software Inc. When considering these emerging vendors, it's wise to remember that acquisitions might impact future product availability and roadmaps -- adopt new application release automation products with caution.
