DevOps Foundations and Terminology

Introduction and Context

DevOps is a set of cultural practices, organisational capabilities, technical methods, and tools that enables development and operations professionals to deliver and operate digital services more reliably and rapidly. The term combines development and operations, but DevOps is not simply a job title, software package, or department. It is an approach to organising work across the entire value stream: from understanding customer needs, through designing and building software, to deploying, operating, securing, and improving the service.

Traditional technology organisations often separated software development from infrastructure and operations. Developers were evaluated on delivering features, while operations teams were evaluated on stability and control. This separation created conflicting incentives. Developers might release changes frequently, whereas operations might resist change to protect service reliability. DevOps seeks to reduce this conflict through shared goals, automation, small changes, rapid feedback, and collective responsibility.

DevOps is especially important because modern organisations depend on digital services for sales, communication, logistics, public services, finance, and internal work. A failure in a digital service can cause financial loss, safety risks, regulatory consequences, and reputational damage. DevOps therefore connects technical practice with business performance.

Learning Objectives

By the end of this chapter, you should be able to:

• explain the origins and business value of DevOps;
• distinguish common DevOps roles and responsibilities;
• describe lifecycle terminology such as continuous integration, continuous delivery, deployment, monitoring, and observability;
• explain shared responsibility and the importance of feedback loops;
• apply the Three Ways and CALMS frameworks;
• compare the relationships among Agile, Lean, IT service management, and platform engineering;
• identify limitations, governance concerns, and good practices in DevOps adoption.

Origins and Evolution of DevOps

DevOps developed from several related movements rather than from one single invention. Agile software development, formalised in the early 2000s through the Agile Manifesto, emphasised working software, customer collaboration, responding to change, and frequent delivery. Agile improved the development process, but many organisations still handed completed software to a separate operations function. The resulting hand-off preserved delays and conflict.

Lean thinking contributed another important influence. Originating in manufacturing and later adapted to knowledge work, Lean focuses on customer value, smooth flow, reduction of waste, built-in quality, and continuous improvement. In software delivery, waste may include waiting for approvals, duplicated testing, excessive work in progress, rework, unused features, and hand-offs between teams.

The term DevOps became widely used around 2009, following discussions among practitioners concerned with collaboration between development and operations. The movement was influenced by systems administration, infrastructure automation, continuous integration, configuration management, Agile, Lean, and large-scale web operations. Books such as The Phoenix Project and The DevOps Handbook helped popularise its concepts, while research and industry reports connected DevOps capabilities with delivery performance and organisational outcomes.

DevOps has subsequently expanded to include security, compliance, reliability, data, and product management. Terms such as DevSecOps, DevDataOps, and platform engineering describe specialised applications of the same broad principle: quality and responsibility should be integrated into the flow of value rather than added only at the end.

The Business Value of DevOps

The business value of DevOps is not merely that software is released more quickly. Its value arises when improved delivery capability produces better outcomes for customers and the organisation. Typical benefits include:

DevOps can improve flow, meaning the movement of valuable work from idea to usable service. It can also improve quality, because testing, security, and operational considerations are addressed throughout the lifecycle. Finally, it can improve resilience, because teams practise recovery, automate repetitive tasks, and learn from failures.

DevOps does not guarantee success. Automation can accelerate a poor process, and frequent deployment can increase risk if testing and monitoring are weak. Business value must therefore be assessed using outcomes such as customer satisfaction, service availability, lead time, failure recovery, cost, security, and employee experience—not by counting tools or pipelines.

DevOps Roles and Shared Responsibility

DevOps changes how roles cooperate, but it does not eliminate professional specialisation. A cross-functional product team may include the following responsibilities:

• Product owner or product manager: clarifies customer problems, prioritises work, and defines expected outcomes.
• Software developers: design, implement, test, document, and maintain application code.
• Quality engineers: design test strategies and help build automated quality controls.
• Operations or site reliability engineers: maintain service reliability, capacity, performance, and recoverability.
• Platform engineers: provide internal platforms, reusable capabilities, and self-service workflows for product teams.
• Security engineers: integrate threat modelling, secure design, vulnerability management, identity controls, and compliance evidence.
• Database, network, and infrastructure specialists: design and operate specialised technical capabilities.
• Service managers: coordinate service levels, incidents, changes, continuity, and stakeholder communication.
• Business and compliance stakeholders: define regulatory, financial, legal, and customer requirements.

The exact titles differ among organisations. The central principle is that the team delivering a service should understand its operational consequences and participate in its support. This is often expressed as “you build it, you run it,” although the phrase should not be interpreted as requiring every developer to perform every operational task alone. Shared responsibility requires appropriate skills, platforms, escalation paths, and organisational support.

A useful distinction is between accountability and execution. A team may be accountable for the reliability of a service while specialised platform or security teams execute supporting activities. Responsibilities should be explicit through service ownership definitions, runbooks, escalation policies, access controls, and decision records.

Shared responsibility also applies to cloud computing. A cloud provider typically operates physical facilities and core infrastructure, while the customer remains responsible for aspects such as identities, configurations, data, application security, and workload resilience. The exact division depends on the service model and provider agreement; it should never be assumed without verification.

The DevOps Lifecycle and Essential Terminology

DevOps is often represented as a continuous loop rather than a one-way project. A typical lifecycle includes planning, coding, building, testing, releasing, deploying, operating, monitoring, and learning. These activities overlap and repeat.

Continuous Integration

Continuous integration (CI) is the practice of frequently merging code changes into a shared repository and validating them through automated builds and tests. CI reduces the risk associated with large, infrequent integration events. Effective CI normally includes version control, reproducible builds, automated tests, code analysis, and rapid feedback.

CI does not mean that every change is automatically released to users. It means that changes are integrated and evaluated continuously.

Continuous Delivery and Continuous Deployment

Continuous delivery is the capability to keep software in a releasable state through automation and disciplined process. A release may still require a human decision or approval.

Continuous deployment goes further: every change that passes the required automated controls is automatically deployed to production. Continuous deployment is therefore a possible implementation of continuous delivery, not a synonym for it.

A deployment moves software or configuration into an environment. A release makes functionality available to users; deployment and release may occur at different times. For example, a feature may be deployed but hidden behind a feature flag.

Infrastructure as Code

Infrastructure as code (IaC) manages infrastructure definitions through machine-readable files and version control. IaC can create repeatable environments, support peer review, and provide an audit trail. It must still be governed carefully: secrets should not be stored in plain text, state must be protected, and changes should be tested before application.

Configuration Management

Configuration management maintains consistency of servers, services, dependencies, and settings. Configuration drift occurs when environments gradually differ from their intended definitions. Automation, immutable infrastructure, and regular reconciliation can reduce drift.

Monitoring and Observability

Monitoring collects and evaluates known signals, such as CPU usage, error rates, latency, and service availability. Observability is the broader capability of understanding the internal state of a system from its external outputs. Logs, metrics, traces, events, profiles, and contextual metadata contribute to observability.

Monitoring may tell a team that requests are failing. Observability helps the team investigate which user journey, service dependency, deployment, or infrastructure condition caused the failure. Good observability supports actionable alerts rather than producing large volumes of unprioritised data.

Incident, Problem, Change, and Service

An incident is an unplanned interruption or reduction in the quality of a service. Incident management seeks to restore normal service quickly and reduce user impact.

A problem is the underlying cause, or potential cause, of one or more incidents. Problem management seeks to identify causes and prevent recurrence.

A change is an addition, modification, or removal that could affect a service. Modern change practices favour risk-based controls, automation, peer review, and evidence rather than unnecessary bureaucracy.

A service is a means of enabling value for customers by facilitating outcomes they want to achieve. DevOps teams should think beyond individual application components and consider the complete customer-facing service.

Feedback Loops and the Three Ways

Feedback loops are essential because delivery systems contain uncertainty. Customer needs, software behaviour, infrastructure conditions, security threats, and business priorities change over time. Feedback converts experience into information that can guide action.

Feedback may be:

• technical, such as test failures, logs, traces, and performance measurements;
• operational, such as incident reviews, capacity trends, and recovery results;
• customer-oriented, such as usability research, support requests, and product analytics;
• organisational, such as team retrospectives, delivery metrics, and employee feedback.

The Three Ways, associated particularly with Gene Kim and the DevOps literature, provide a practical model for improving flow and learning.

The First Way: Flow of Work from Left to Right

The First Way focuses on the fast and smooth movement of work from development toward operations and customers. Practices include limiting work in progress, reducing batch size, automating testing and deployment, removing hand-offs, and making queues visible.

The objective is not speed at any cost. Work should flow with appropriate quality and controls. A team that produces more unfinished features has not improved flow; it has increased inventory.

The Second Way: Fast and Continuous Feedback

The Second Way emphasises feedback from the right side of the lifecycle back to the left. Production monitoring, automated tests, security scanning, customer evidence, and post-incident learning help teams detect problems while they are still relatively inexpensive to correct.

Feedback must be timely, credible, and acted upon. A dashboard that no one reviews is not an effective feedback mechanism.

The Third Way: Continuous Learning and Experimentation

The Third Way encourages a culture of learning, experimentation, and improvement. Teams should be able to test hypotheses safely, learn from failures, and improve both technical systems and work processes. This includes controlled experiments, blameless incident reviews, resilience testing, and deliberate practice.

“Blameless” does not mean that responsibility is ignored. It means that investigations focus on system conditions, decisions, communication, and contributing factors rather than using humiliation or punishment to discourage reporting. Where misconduct or negligence exists, appropriate governance still applies.

CALMS: A DevOps Adoption Framework

CALMS is a commonly used framework for examining DevOps capabilities:

CALMS is not a rigid maturity checklist. An organisation may have strong automation but weak culture, or excellent sharing but inadequate measurement. Sustainable improvement requires balance. For example, automating a manual approval process without questioning its purpose may preserve waste rather than remove it.

Measurement should avoid encouraging harmful local optimisation. If developers are rewarded only for the number of features completed, quality and reliability may decline. If operations are rewarded only for avoiding change, delivery may stagnate. Measures should be interpreted together and connected to outcomes.

Relationships Among Agile, Lean, ITSM, and Platform Engineering

Agile and DevOps

Agile primarily addresses how teams discover, prioritise, and develop valuable products under changing conditions. DevOps extends the concern across delivery and operation. Agile iteration without operational feedback can produce software that is difficult to deploy or support. DevOps without product discovery can automate the delivery of work that customers do not need.

Agile ceremonies are not themselves DevOps. A daily meeting or sprint does not guarantee collaboration, automation, or reliable delivery. The connection is strongest when iterative planning is combined with continuous integration, operational ownership, and real customer feedback.

Lean and DevOps

Lean provides principles for improving value flow. Its concepts include value, value streams, waste, pull, flow, built-in quality, and continuous improvement. DevOps applies these ideas to digital work, where inventory may appear as unmerged branches, untested code, pending tickets, or unimplemented infrastructure changes.

Lean also warns against optimising one stage while constraining the whole system. Increasing development output is not beneficial if testing, security review, deployment, or operations becomes a bottleneck.

IT Service Management

IT service management (ITSM) provides practices for designing, delivering, supporting, and improving technology-enabled services. Frameworks such as ITIL describe concepts including incident management, problem management, change enablement, service configuration, service levels, and continual improvement.

DevOps and ITSM are sometimes presented as opposites, but this is misleading. Both seek reliable services and improved value. The difference is often one of emphasis: traditional ITSM implementations may rely heavily on formal processes and separation of duties, while DevOps emphasises flow, automation, decentralised decision-making, and rapid feedback. Modern ITSM can incorporate automated evidence, risk-based change, self-service, observability, and product-oriented ownership.

Controls remain necessary in regulated or safety-critical environments. DevOps should improve the efficiency and quality of control rather than remove legitimate control.

Platform Engineering

Platform engineering is the design and operation of an internal platform that provides reusable capabilities to application teams. Examples include deployment workflows, standard runtime environments, identity integration, databases, observability, secrets management, and policy controls.

A platform should be treated as an internal product. Platform engineers should understand developer needs, provide documentation and support, measure adoption and reliability, and avoid creating a restrictive central bottleneck. The goal is usually a “paved path”: a well-supported default route that teams can use safely, while justified exceptions remain possible.

Platform engineering supports DevOps by reducing cognitive load and providing consistent automation. It does not transfer all responsibility away from product teams. Teams still need to understand the behaviour, risks, and costs of the services they own.

An Illustrative Case: Northstar Retail

Background

Northstar Retail, a fictional online retailer, operated a web application using separate development, infrastructure, testing, and service-desk departments. Releases occurred every three months. A release required manual environment preparation, a large test cycle, several approval meetings, and weekend deployment work.

Problem

The organisation experienced delayed releases, recurring incidents, and strained relationships between departments. Developers claimed that infrastructure rules slowed delivery. Operations staff reported that changes arrived without adequate documentation or monitoring. Customers experienced intermittent checkout failures during major promotions.

Analysis

A value-stream review identified several causes:

• large batches of changes accumulated between releases;
• test environments differed from production;
• deployment steps were documented manually and inconsistently;
• service ownership was unclear;
• monitoring detected infrastructure symptoms but not checkout failures;
• incident reviews focused on individual mistakes rather than system conditions.

Approach and Solution

Northstar formed a cross-functional checkout team containing developers, a quality engineer, an operations specialist, a security representative, and a product owner. The team introduced version-controlled infrastructure definitions, automated unit and integration testing, deployment automation, feature flags, service-level indicators, and trace-based observability for the checkout journey.

The team adopted a risk-based change process. Low-risk, well-tested changes used an automated path; higher-risk changes required additional review. A platform team provided standard deployment templates and secrets management. After incidents, the team conducted blameless reviews and tracked improvement actions.

Outcome

The fictional case illustrates how DevOps changes the system of work rather than merely purchasing a pipeline tool. Smaller changes reduced the scope of failures. Automated environments improved consistency. Shared ownership improved communication, while observability shortened diagnosis. The organisation also retained governance by recording changes, protecting secrets, and applying additional controls to high-risk releases.

Learning Points

1. Technical automation is most effective when accompanied by organisational change.
2. Shared responsibility requires explicit ownership and enabling platforms.
3. Reliability and delivery speed can improve together when batch size and uncertainty are reduced.
4. Metrics should support learning and customer outcomes, not encourage blame or local optimisation.
5. Governance can be integrated into delivery workflows rather than treated only as a final gate.

Challenges, Limitations, and Governance

DevOps adoption can fail when it is treated as a tool installation, restructuring exercise, or demand that individuals work longer hours. Common challenges include:

• Cultural resistance: trust cannot be created by slogans alone; leaders must model collaboration and learning.
• Tool proliferation: many disconnected tools can increase complexity and maintenance costs.
• Automation debt: pipelines and scripts require ownership, testing, documentation, and lifecycle management.
• Skill gaps: teams need knowledge of software engineering, infrastructure, security, testing, and service operation.
• Metric gaming: poorly chosen measures can encourage unsafe speed or avoidance of change.
• Legacy systems: architecture, contracts, and release constraints may limit rapid delivery.
• Cognitive overload: asking one team to own every concern without a platform or support model can be harmful.
• Compliance misunderstandings: regulation generally requires control objectives and evidence, not necessarily manual processes.

Security and privacy must be integrated into the lifecycle. Important practices include least-privilege access, secure software supply chains, dependency management, secrets protection, auditability, threat modelling, vulnerability response, data minimisation, and appropriate retention. Automated security checks are valuable but cannot replace expert judgement or governance.

Artificial intelligence may assist with code suggestions, test generation, log summarisation, incident correlation, and documentation. However, AI-generated output can contain defects, insecure patterns, licensing concerns, biased recommendations, or confidential data leakage. Organisations should define acceptable use, review requirements, data boundaries, and accountability. AI should strengthen feedback and decision-making rather than obscure responsibility.

Best-Practice Principles

A certificate-level practitioner should remember the following principles:

1. Start with customer and business outcomes, not tools.
2. Make work and ownership visible.
3. Integrate code frequently and keep changes small.
4. Automate repeatable work, but maintain the automation responsibly.
5. Build quality, security, and compliance into the flow.
6. Use production feedback to guide improvement.
7. Design services for operability, resilience, and recovery.
8. Measure outcomes and interpret metrics in context.
9. Treat platforms as products for internal users.
10. Create psychological safety while retaining professional accountability.

Chapter Summary

DevOps is an organisational and technical approach for improving the flow, quality, reliability, and learning associated with digital services. It emerged from the interaction of Agile, Lean, systems administration, automation, and modern software delivery practices. Its business value comes from connecting technical capability to customer outcomes rather than from release speed alone.

DevOps distributes responsibility across development, operations, security, product, platform, and service-management roles. Important lifecycle terms include continuous integration, continuous delivery, continuous deployment, infrastructure as code, monitoring, observability, incident, problem, change, and service. Feedback loops enable teams to detect issues, learn, and improve.

The Three Ways describe flow from left to right, rapid feedback, and continuous learning. CALMS provides a complementary view of culture, automation, Lean, measurement, and sharing. Agile supports iterative product development; Lean improves value flow; ITSM supports reliable service management and governance; and platform engineering provides reusable internal capabilities. These approaches are complementary when applied thoughtfully.

Successful DevOps adoption requires more than tools. It requires clear ownership, appropriate governance, secure automation, useful measurement, psychological safety, and continuous attention to customer and service outcomes.

Key Terms

Agile: An approach to iterative product development that values collaboration, working outcomes, and responsiveness to change.

CALMS: A framework organised around Culture, Automation, Lean, Measurement, and Sharing.

Continuous delivery: The capability to keep software in a releasable state through reliable automation and process.

Continuous deployment: Automatic deployment of changes that pass defined controls.

Continuous integration: Frequent integration of code changes into a shared repository with automated validation.

DevOps: A set of practices and cultural principles integrating development, operations, security, and related responsibilities.

Deployment: The act of moving software or configuration into an environment.

Feedback loop: A mechanism through which results or observations influence subsequent decisions and actions.

Infrastructure as code: Management of infrastructure through version-controlled, machine-readable definitions.

Incident: An unplanned interruption or reduction in service quality.

IT service management: Practices for designing, delivering, supporting, and improving technology-enabled services.

Lean: A management philosophy focused on customer value, flow, waste reduction, and continuous improvement.

Observability: The ability to understand a system’s internal condition from its external outputs.

Platform engineering: Development of internal platforms that provide reusable capabilities and self-service paths.

Problem: An underlying or potential cause of one or more incidents.

Release: The act of making functionality available to users.

Shared responsibility: A model in which relevant teams jointly own outcomes while retaining explicit responsibilities.

Three Ways: DevOps principles concerning flow, feedback, and continuous learning.

Value stream: The complete sequence of activities required to deliver value to a customer.

Review Questions

Short Answer Questions

1. What is DevOps, and why is it more than a collection of tools?
2. Distinguish continuous delivery from continuous deployment.
3. What is the purpose of observability?
4. Name the five elements of CALMS.
5. How does platform engineering support product teams?

Long Answer Questions

1. Explain the historical relationship among Agile, Lean, and DevOps.
2. Describe the Three Ways and give one practical example of each.
3. Discuss how shared responsibility changes the relationship between development and operations.
4. Compare DevOps and IT service management, identifying areas of complementarity.
5. Explain why measurement can support or undermine DevOps adoption.

Analytical / Application Questions

1. A team deploys frequently but experiences many production incidents and slow recovery. Use the Three Ways and CALMS to diagnose likely weaknesses and recommend improvements.
2. Design a responsibility model for a cloud-hosted payment service involving developers, a platform team, security specialists, and a cloud provider.
3. Northstar Retail wants to automate every approval in its release process. What questions should it ask before doing so, and which controls should remain for high-risk changes?

Multiple Choice Questions with Answers

Question 1

Which statement best describes continuous integration?

A. Automatically deploying every change to production

B. Frequently merging code and validating it through automated checks

C. Manually approving releases at the end of a project

D. Monitoring infrastructure without changing source code

Correct Answer: B. Frequently merging code and validating it through automated checks

Question 2

Which of the following is the main focus of the First Way?

A. Increasing the flow of work from development toward customers

B. Removing all operational controls

C. Replacing monitoring with manual inspections

D. Assigning all work to a platform team

Correct Answer: A. Increasing the flow of work from development toward customers

Question 3

In CALMS, which element concerns evidence about delivery, reliability, quality, and outcomes?

A. Culture

B. Automation

C. Measurement

D. Sharing

Correct Answer: C. Measurement

Question 4

Which statement correctly distinguishes deployment from release?

A. Deployment always requires a customer-facing announcement

B. A release can never occur without changing infrastructure

C. Deployment moves software into an environment, while release makes functionality available to users

D. Deployment and release are always identical

Correct Answer: C. Deployment moves software into an environment, while release makes functionality available to users

Question 5

What is a central purpose of infrastructure as code?

A. To prevent all infrastructure changes

B. To manage infrastructure through repeatable, version-controlled definitions

C. To store secrets in application source files

D. To eliminate the need for testing

Correct Answer: B. To manage infrastructure through repeatable, version-controlled definitions

Question 6

Which relationship between Agile and DevOps is most accurate?

A. Agile and DevOps are identical terms

B. Agile focuses mainly on iterative product development, while DevOps extends concern across delivery and operation

C. DevOps rejects customer feedback used by Agile

D. Agile applies only to infrastructure teams

Correct Answer: B. Agile focuses mainly on iterative product development, while DevOps extends concern across delivery and operation

Question 7

What is the primary purpose of incident management?

A. To restore normal service and reduce user impact

B. To assign personal blame for every failure

C. To design all future product features

D. To replace problem management

Correct Answer: A. To restore normal service and reduce user impact

Question 8

Which practice best reflects the Second Way?

A. Increasing the size of release batches

B. Delaying all operational information until the end of a project

C. Using production monitoring and test results to provide rapid feedback to teams

D. Removing automated tests to accelerate coding

Correct Answer: C. Using production monitoring and test results to provide rapid feedback to teams

Question 9

What is a key risk of treating DevOps as only a tool-installation project?

A. Tools automatically solve unclear ownership and cultural conflict

B. Technical automation may accelerate an ineffective or poorly governed process

C. Automation makes feedback impossible

D. The organisation will necessarily reduce its security controls

Correct Answer: B. Technical automation may accelerate an ineffective or poorly governed process

Question 10

Which description best fits platform engineering?

A. A practice of replacing all product teams with one central operations department

B. Designing internal platforms that provide reusable capabilities and supported self-service paths

C. A method for avoiding documentation and standards

D. A process limited to purchasing cloud infrastructure

Correct Answer: B. Designing internal platforms that provide reusable capabilities and supported self-service paths