Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Understanding how DevOps software development evolved

Many IT organizations are turning to the practice of DevOps software development. But this requires more than implementing an open source tool.

The desire to deploy quality code and to do so more rapidly is driving many IT organizations to adopt the practice...

of DevOps software development. However, this new approach to software development requires more than implementing an open source tool. To better understand how to achieve the end goal -- dev and ops groups working together -- it may help to understand how the idea of DevOps came to be and how it can be applied to enterprise IT.

"A lot of the DevOps purists are saying DevOps did not come from Agile, it did not come from open source, it did not come from innovative uses of automation, it did not come from change management practices, and it did not come from the breaking down of big Waterfall silos. And I disagree," Paul Peissner, director of business development at CollabNet, said. "I think [DevOps] came from all of those, and all of those created the perfect storm where we could question the infrastructure of siloed IT."

Siloed IT -- and the specialists who control the silos -- were a response to the technology itself. "The technology, when you left mainframe, was fragile, distributed and competitive. [So, specialists] created rules that limited the scope and impact that developers could have in the existing infrastructure," Peissner said. These rules, according to Peissner, came in the form of ITIL, governance and compliance, and they slowed down developers and created bureaucracy.

DevOps began as grass-roots movement

The pain from these rules was felt most heavily around release management. "DevOps started out as very much a grass-roots movement from the ops side and it's really grown in a number of ways. It has created a new tooling market around the automation side of release management and having continuous delivery or deployment -- two terms that mean similar things," Michael Azoff, principal analyst at Ovum, said.

DevOps-in-a-box is just not possible. You can't put people variables inside a box.
Chris Rileyfounder and DevOps analyst, Fixate IO

"DevOps started with release management because that was the most broken piece in IT," Peissner said. "Release was the slowest-moving piece in all of IT. It could take us years to invent, months to QA, but we would sit indefinitely staring at each other saying, 'When is the right time to release this?' We physically didn't have the cultural capacity to introduce changes and recover from that gracefully. It was an 'aha moment' that we could release if we listened to each other," Peissner said.

Although tools can help facilitate release management and continuous delivery, experts are careful to de-emphasize their role in a company's move to adopt DevOps software development. "Culture first, process second and then tools. Everyone wants to lead with tools. Vendors are guilty of creating this problem, because they imply that if you use our tools, you will be DevOps," said Chris Riley, founder and DevOps analyst at Fixate IO. "DevOps-in-a-box is just not possible. You can't put people variables inside a box."

A large number of companies use Puppet and Chef and are on the path to better software quality, but Riley said that doesn't make them DevOps software development shops. "I estimate the number of people doing DevOps to be fewer than 25%, because it is such a new idea. Some organizations still believe Waterfall is the best way or they are just learning Agile, and that's the result of a culture built on business processes," Riley said.

People need to be tied to business gains

According to Peissner, many IT organizations haven't made the organizational changes necessary for DevOps or Agile. "Both [Agile and DevOps] are flawed because the reward system, when they hire you, is still a siloed system. You can be a superhero in a portion of the software conversation that doesn't affect the business, and bring efficiencies and improvements to your segment, but if it doesn't transfer to the business, you'll see zero impact. Until you tie people to business gains and efficiency gains that are measurable and attainable, you're just throwing money at segmented groups," he said.

David Linthicum, senior vice president at Cloud Technology Partners, said there's always a reorganization that comes with moving to DevOps. "The objective is to remove some of the latency in terms of how [organizations] deliver software. It's a matter of putting everyone in the same room and having everyone report to one consistent leader, someone who controls the money and the group's destiny. If you leave the ops organization out and the developers or CTO are supposed to influence the group but no one can fire people or control the money, there are not going to be a lot of changes."  

Ovum's Azoff agreed. "With experience, you find you need executive support, someone right at the top to mandate a change in approach to deal with the need to get products out to the market a lot quicker," he said. "One of the things about DevOps is having closer collaboration in IT and business areas, so it's also an approach to how you work rather than a process. so you have a better idea of what's coming upstream or downstream. There are fewer surprises."

The bottom line, according to Fixate IO's Riley: Start with people. "This culture element doesn't have anything to do with anything fuzzy or wishy-washy. I would say it always has to be people first, because where [DevOps] fails is the highly variable people part, and all that it needs is that you're deliberate. Instead of letting culture define itself and evolve organically, you are deliberate about it," he said.

 

Next Steps:

DevOps in the cloud

 

The future of Agile and DevOps

This was last published in April 2015

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

A DevOps primer: Start, improve and extend your DevOps teams

Join the conversation

8 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What do you think is the best way to prepare staff for transitioning to DevOps?
Cancel
Software vendors have been always doing hot fixes and small client specific feature releases. However, there was no standard process that everybody followed.  Customer priority and sales quota overrides any ITIL standards for the software vendors.  DevOps is a a new  name of  many non-standard processes followed by software vendors.
Cancel
Can't see that there just one best way - a few "best" ways come to mind.
1) Set up self contained teams per deployment
2) Let team agree on the common success metrics and rewards
3) Co locate teams
4) Team report to APM for the duration of the project 
Cancel
We created some FREE training on this:
https://github.com/emccode/training
Cancel

github and bitbucket are excellent collaboration tools.  Organizations should have as a minimum some control and processes to ensure quality and  completeness of the development and testing for each unit of deployment. I suggest that a log or repository should be created :

1. details of request for fix or new feature

2. classification and identification of the components that needs to be changed (interface, data, codes etc.)

3. estimate time and cost

4. prioritize based on cost benefit and code dependencies of all ongoing changes

5. create and assign virtual teams of architect, developer and tester for each request

6. automate test and deployment process as much as possible  

7. create unique release sequence number for each piece of codes that have gone through the dev/test stages

8. ensure a regression testing after every few releases by a completely independent test group

9. ensure documentation is updated and shared after every change as they progress

10. primary difference between agile and dev/ops are multiple simultaneous code update, virtual teams where same person may be working on multiple projects, time cycle of deployment may be everyday, scaled down deployment testing and introducing integration testing at a later time.   


Cancel
While I see we are doing some pieces in a DevOps like manor, I find one of the problems we suffer is from risk-aversion.  Our business is such that the down side of risk is really high, but ironically no one seems to appreciate that we are creating more risk by doing things by hand.  How do you convince a culture that has 'always done it by hand' that there is less risk and more traceability by using automation?
Cancel
Tools play into building a devops infrastructure.  But a foll with a tool remains one.  DevOps is a way of thinking about software, and it is far more than just a tool set.
Cancel
One might argue that there are virtually no parts of the business where tools DO translate to prowess. Indeed, while many vendors claim this to be the case, I've never seen it bear out.
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close