DevOps is a loosely defined set of practices that combine software development (Dev) and operations (Ops), founded on Agile.
It's grounded in CALMS: Culture, Automation, Lean, Measurement and Sharing, an acronym for understanding the key points of DevOps philosophy.
In short, DevOps values:
- adaptability over efficiency;
- do and adapt over plan, implement; and
- release quality at all times.
Or, in depth:
- Trust but verify.
- Empowerment of individuals to control their own destiny.
- Accountability after a service is launched; you write it, you own it.
- Continuous improvement of software and process.
- Making data-driven decisions: measuring things and using data to influence direction.
- Customer empathy, whether the customer is internal or external. Changes should benefit them.
Organisations applying DevOps principles are typically very customer-focused, using a definition of done defined by shipping. A clear view of the entire development and deployment pipeline and automation grants high deployment throughput, in turn enabling smaller, more frequent releases. This requires better defined feedback loops, which lead to further refinement of process and product innovation.
In larger organisations there's often a need to rebuild trust between the IT organisation and the wider business due to a gatekeeper/"team of no" perception. In these cases start small, maybe with a single project, and build out.
Note the characteristics of larger organisations that make DevOps implementations harder:
- More stakeholders means more people to involve in ceremonies; consider nominating members from each team.
- Functional silos across departments may need to be broken down. A Value Stream Mapping exercise should help to identify candidates for optimisation.
- Managing existing technical debt may require additional architectural consideration.
- Compliance requirements require consideration around planning and review.
- Outsourcing in the traditional handover sense will need to be replaced with collaboration.
No more silos
The historical separation of a development and operations teams is old-fashioned and leads to extreme siloisation of knowledge. It incentivises local optimisation over sharing and a lack of collaboration, causing poor business outcomes.
Accidents are normal
Accidents happen as a result of missing safeguards, not individual failings. It's better to address bad interfaces that make failure inevitable if a system slips into an unintended state than to fruitlessly punish one individual.
Change should be gradual
Change is best when little and often. Change is risky, but risk can be managed when release size is regulated by velocity. We can further support gradual change through continuous delivery.
Tooling and culture are interrelated
Tooling is an important component of DevOps, but organisational culture is key to success: good culture can workaround bad tooling, but the opposite is often untrue.
Measurement is crucial
Establish the reality of what's happening by looking at the numbers.
- Volume of build errors and warnings
- Operational metrics