Practically speaking, it's something that's been taking shape for a long time based on the changes that are happening in the industry. These include a demand for faster product releases from application builders, increased data center automation and configuration management tools and the use of agile software development. (Get some background on this type of development in Agile Software Development 101.)
In a nutshell, DevOps represents the intersection between development, operations and quality assurance, three areas that, in the past, operated relatively independently.
Sounds simple, right? Although the basic idea of DevOps is pretty straightforward, the fact is that a lot of people are talking about it in a lot of different ways. So let's take a look at a few them.
The DevOps AdvantageAlthough detailed descriptions of DevOps differ, most people agree that the essential goal of this kind of approach is to change how developer teams and others work on projects that are made to "go live." All live projects, software products and technologies for public use or specific end-user communities start out as ideas and get kicked around by various coders as part of what's often a complex process that must occur before they're released. This is what DevOps tends to address. The idea is to make this process as smooth as possible, and keep the most effective people involved every step of the way.
Some of the flurry of information on DevOps shows that professionals in this role sometimes get pigeonholed as "sys admins" or typecast in other way. Some see DevOps people as people who just put on different hats, vacillating between a developer and an admin role.
But many HR specialists might see something different when the word DevOps pops up on a resume. That's because DevOps professionals often work as project "hand-holders," people who oversee an otherwise overlooked aspects of product development and help get the work done. More specifically, DevOps addresses the idea that if there are no active and engaged people to help bring something live, it might in fact go live the wrong way.
DevOps and the History of Project ManagementAccording to some of those who sing the praises of DevOps, the new idea really grapples with some core problems in the way that development used to work (and in some cases, still does.) One related issue is some developers' failure to create things that are user friendly and to have a vested interest in the operations side of development. But another area that DevOps can address is the automation of practices, where developers may become frustrated with sub-par ways to enable efficient coding to get a project toward that ultimate goal of going live. Both of these common development issues can get be addressed by a DevOps plan.
DevOps and the CloudLots of consumers know the cloud primarily as a place for remote storage, but developers can see a lot of other potential for using cloud services to provide better methodologies for projects. In a DevOps initiative, planners might look at continuous delivery or more seamless assembly lines for software. Basically, if your company releases applications or other products on a regular basis, some protocols for repetitive tasks can ensure better outcomes and higher quality-assurance benchmarks.
Those in DevOps might also look for opportunities to automate some of what was previously done manually. Cloud services can enable all kinds of new resources for bringing software products along through parts of the life cycle in an easier way. There’s often a focus on bringing products to multiple environments, or deploying with less work by using new tools promising "zero-touch" deployment. But again, DevOps approaches, combined with cloud services, are also commonly used to forge new ways of working while discarding stale change-management systems and helping to make radical change possible within a given corporate or IT culture. (Get some background on the the cloud in Cloud Computing: Why the Buzz?)
DevOps Is Made of PeopleIn a nutshell, a lot of what’s in the average DevOps department or structure has to do with making sure that people work well together. By building a particular DevOps component into a company, the leadership is often hoping to ensure that there’s a lot of good communication as a project makes its way through the often complex assembly line that stretches from an idea to a working prototype and on into the live phase of a software product. That means using DevOps personnel to sort out whether a developer team is calling for the right resources, coordinating tasks, or sending their work on to the right next step team. If all of this sounds pretty elaborate, it’s no surprise to those who work in larger IT companies or other firms that build their own IT products.
Devops is a complex idea for a complex world, a world in which work often has a lot more to do with things like process documentation, networking and inter-office collaboration than with simple manual, or even cognitive, labor. And to many top-level managers whose IT processes require more than a few full-timers, it’s the right idea for its time.