· practice
What is DevOps?
A clipped compound of « development » and « operations »
DevOps (a clipped compound of « development » and « operations » ) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.
Many of the ideas (and people) involved in DevOps came from the Enterprise Systems Management and Agile software development movements.
What is DevOps?
Patrick Debois, (@patrickdebois) godfather of the DevOps movement, always says DevOps is a human problem.
In traditional, functionally separated organizations there is rarely cross-departmental integration of these functions with IT operations. DevOps promotes a set of processes and methods for thinking about communication and collaboration between development, QA, and IT operations.
DevOps is not a technology problem. DevOps is a business problem.
DevOps as a culture, movement or practice which is not a method of development.
It is more a cultural shift where applications are products and not projects. As a cultural change, all the teams are working together to provide a better product in a better time to market. Which means that teams are working together as A product team. And industrialization pratices are improved to optimize delivery automation.
DevOps integration targets product delivery, quality testing, feature development, and maintenance releases in order to improve reliability and security and provide faster development and deployment cycles.
Cultural shift
DevOps-part-dev-part-opsDevOps is more than just a tool or a process change; it inherently requires an organizational culture shift.
This cultural change is especially difficult because of the conflicting nature of departmental roles.
Operations seeks organizational stability; developers seek change; and testers seek risk reduction.
Getting these groups to work cohesively is a critical challenge in enterprise DevOps adoption.
Improved automation
DevOps is clearly not set of cool tools ! But to escort the cultural shift, automation must be set tooptimize the product delivery.
Automation is a key technical goal of DevOps, specialy practices like build, versioning, packaging, testing (all type of tests), code analysis (quality gate), deployment (to a execution environment), staging, promotion, monitoring.
All the SCM practices must be correctly understood and managed in order to get a product from development to production.
But also, tight association between architecture design and SCM is crucial to get the product working!
All the practices involved into set-up a continuous delivery process should be set in order to implement the tooling aspect of DevOps.
Agile movement
If the goals of DevOps sound similar to the goals of Agile, it’s because they are.
But Agile and DevOps are different things. You can be great at Agile Development but still have plenty of DevOps issues. On the flip side of that coin, you could do a great job removing many DevOps issues and not use Agile Development methodologies at all (although that is increasingly unlikely).
Agile and DevOps are related ideas, who share a common Lean ancestry.
But while Agile deep dives into improving one major IT function (delivering software), DevOps works on improving the interaction and flow across IT functions (stretching the length of the entire development to operations lifecycle).
Key goals of DevOps : CAMS
CAMS is an acronym describing the core values of the DevOps Movement: Culture, Automation, Measurement, and Sharing. It was coined by Damon Edwards and John Willis at DevOpsDays Mountainview 2010.
Culture
DevOps is mostly about breaking down barriers between teams. An enormous amount of time is wasted with tickets sitting in queues, or individuals writing handoff documentation for the person sitting right next to them. In pathological organizations it is unsafe to ask other people questions or to look for help outside of official channels. In healthy organizations, such behavior is rewarded and supported with inquiry into why existing processes fail. Fostering a safe environment for innovation and productivity is a key challenge for leadership and directly opposes our tribal managerial instincts.
Automation
Perhaps the most visible aspect of DevOps. Many people focus on the productivity gains (output per worker per hour) as the main reason to adopt DevOps. But automation is used not just to save time, but also prevent defects, create consistency, and enable self-service.
Measurement
How can you have continuous improvement without the ability to measure improvement? How do you know if an automation task is worthwhile? Basing decisions on data, rather than instinct, leads to an objective, blameless path of improvement. Data should be transparent, accessible to all, meaningful, and able to be visualized in an ad hoc manner.
Sharing
Key the success of DevOps at any organization is sharing the tools, discoveries, and lessons. By finding people with similar needs across the organization, new opportunities to collaborate can be discovered, duplicate work can be eliminated, and a powerful sense of engagement can be created among the staff. Outside the organization, sharing tools and code with people in the community helps get new features implemented in open source software quickly. Conference participation leaves staff feeling energized and informed about new ways to innovate.
What DevOps is not !
DevOps is not a set of tools
When speaking about DevOps, very often the subjects are going into « which tool can do that« . But DevOps can not be simpy resumed to that. Because its best improvement is to change the culture of organisations to make them think about product and not projects. Tools are required to automate the delivery but are not the value of the product.
DevOps is not a plan
Some of the early Devops thought leaders started noticing a trend that was particularly emerging from Agile based web operating (Webops) companies.
The observations were that some traditional enterprises were running Agile and Lean development cycles, but their operations still looked like the waterfall process. They started writing blog articles and they even created a small barcamp style conference called Devopsdays.
DevOps is not exclusive
Some might be extremely excited about the fact that they can deploy 20 times a day; however, just because they can, doesn’t mean that others should or even can.
Devops and process standards are not mutually exclusive. The idea is not to make another silo!
DevOps is not just a bunch of really smart people
Yes, there are some iconic like people involved in the Devops movement. But just like open source, the best and the brightest inventions and great ideas come from a a smaller group and then larger groups adopt and benefits.
Devops is not a product
If a vendor tells you that they have a Devops product or a Devops compliant product, then you will know immediately that they don’t have a clue of what Devops is. However, you know the true followers when they start talking about the Devops culture first and then their tool as a second-class citizen behind people and process.
Devops is not a run around traditional IT
When a Devops discussion starts with technology, the conversation is headed in the wrong direction. If you hear something like “Just hire smart people and give them root”, immediately run for the hills.
Sources
DevOps dictionnary CAMS
DevOps Agile
DevOps culture
DevOps anti-pattern
DevOps is not
Patrick Debois blog