CI/CD Lesson 10 – CI/CD in Modern DevOps | Dataplexa
Section I · Lesson 10

CI/CD in Modern DevOps

In this lesson

DevOps Culture CI/CD's Role in DevOps The Three Ways Toolchain Overview Platform Engineering

DevOps is a set of practices, cultural values, and organisational patterns that break down the traditional wall between the team that writes software and the team that runs it. It is not a job title, a tool, or a department — it is a philosophy about how high-performing engineering organisations work. At its technical core sits CI/CD: the pipeline that translates DevOps culture into daily, repeatable practice. You cannot have a functioning DevOps organisation without it.

What DevOps Actually Is — and What It Is Not

DevOps is widely misunderstood. Some organisations treat it as a job title — a "DevOps Engineer" who manages the pipeline while developers and operations teams continue to work in silos. Others treat it as a toolset: buy the right CI/CD platform and you have done DevOps. Neither is accurate.

DevOps is fundamentally about shared ownership. Developers own what happens in production. Operations teams understand the code that runs on their infrastructure. Everyone is responsible for quality, reliability, and delivery — not just the person whose job title contains the relevant word. The tools support this shared ownership; they do not create it on their own.

The Restaurant Kitchen Analogy

In an old-fashioned kitchen, chefs cook and waiters serve — with a wall between them and no shared accountability for the dining experience. In a modern open kitchen, chefs see the dining room, waiters understand the menu, and everyone cares about whether the guest leaves happy. DevOps is the open kitchen model applied to software. CI/CD is the pass — the counter where code moves from one side to the other, checked, confirmed, and ready.

The Three Ways — How DevOps Organisations Think

Gene Kim's The Phoenix Project and The DevOps Handbook describe the underlying principles of high-performing engineering organisations as the Three Ways. These are not steps in a process — they are mental models that shape how work flows through an organisation. CI/CD is the practical implementation of all three.

The Three Ways — and How CI/CD Implements Each One

First Way — Flow
Work moves fast and smoothly from development to production, with no unnecessary waiting, no handoff queues, and no large batches of change. CI/CD implements this by automating every step between a code commit and a running deployment — eliminating the bottlenecks that cause work to pile up.
Second Way — Feedback
Problems are discovered and fixed as close to their source as possible. CI/CD implements this by closing the feedback loop to minutes — a failing test, a security scan alert, or a deployment error surfaces immediately to the engineer who introduced it, while the context is still fresh.
Third Way — Continual Learning
Teams experiment, learn from failures, and build that learning back into their systems. CI/CD enables this by making experimentation cheap — a feature flag, a canary release, a one-click rollback. The pipeline records every run, making failure data available for analysis rather than buried in incident calls.

Where CI/CD Sits in the Modern Toolchain

A CI/CD pipeline does not operate in isolation. It connects to a wider ecosystem of tooling that together forms the DevOps toolchain. Understanding how these tools relate to each other is essential for working inside any modern engineering organisation.

The Modern DevOps Toolchain — Where Each Tool Fits

Source Control
GitHub, GitLab, Bitbucket — where code lives and where every pipeline begins. A push or pull request merge is the event that triggers CI.
CI/CD Platform
GitHub Actions, GitLab CI, Jenkins, CircleCI — orchestrates the pipeline: builds, tests, scans, deploys. The engine room of the DevOps toolchain.
Artifact Registry
Docker Hub, AWS ECR, GitHub Packages — stores the built, versioned outputs of the CI pipeline. Covered in depth in Lesson 14.
Infrastructure as Code
Terraform, Pulumi, CloudFormation — defines the environments the pipeline deploys into. The pipeline provisions infrastructure the same way it deploys code. Covered in Lesson 36.
Secrets Management
HashiCorp Vault, AWS Secrets Manager, GitHub Secrets — supplies credentials and API keys to pipeline steps without hardcoding them. Covered in Lesson 23.
Observability
Datadog, Grafana, Prometheus — monitors the health of what the pipeline deployed. The pipeline's feedback loop does not end at deployment; it continues through production metrics. Covered in Lesson 30.
Container Orchestration
Kubernetes, AWS ECS — manages how containers run in production. CI/CD pipelines typically deploy to an orchestration platform rather than to bare servers. Covered in Lesson 29.
Feature Flags
LaunchDarkly, Unleash — decouples deployment from release. Code can ship to production before a feature is visible to users, enabling dark launches and controlled rollouts. Covered in Lesson 35.

A Day Inside a Mature DevOps Team

Abstract descriptions of DevOps culture are easy to misread. Here is what a working day actually looks like inside a team that has CI/CD and DevOps working well together — not as a best-case scenario, but as an ordinary Tuesday.

An Ordinary Tuesday — With Mature CI/CD and DevOps

9:02 AM
A developer opens a pull request. Within 3 minutes, the CI pipeline reports: all 847 tests passing, code coverage at 91%, no security vulnerabilities flagged, lint clean. She knows her change is safe before a reviewer even looks at it.
10:15 AM
A second developer's PR fails the pipeline. One test is broken — a regression in the payment module. He sees the failure in Slack within 60 seconds of pushing, fixes it locally in 12 minutes, and pushes again. The pipeline goes green. No one else is involved.
11:40 AM
Three PRs are merged. Each one triggers an automatic deployment to the staging environment. The product manager reviews the changes on staging. No deployment meeting. No deployment ticket. No waiting.
2:30 PM
The team lead approves production deployment. The pipeline runs the full suite again, promotes the artifact to production, and updates the observability dashboard. The whole process takes 8 minutes. Four engineers ship to production without being in the same room or on the same call.
4:55 PM
An alert fires: error rate on the checkout endpoint up 0.3%. The on-call engineer checks the deployment log, identifies the responsible change, and triggers a one-click rollback. Production is back to normal in 4 minutes. A postmortem is scheduled for tomorrow — not a blame session, a learning session.

Platform Engineering — The Next Step After CI/CD

As organisations mature beyond basic CI/CD, many are moving towards platform engineering — building an internal developer platform (IDP) that wraps the entire toolchain into a self-service layer. Instead of every team configuring their own pipelines, secrets management, environment provisioning, and observability, a dedicated platform team builds and maintains a standardised platform that product teams use.

The pipeline is still there — it is just pre-built, standardised, and available to every team without each team having to reinvent it. A new service that follows the platform conventions gets CI/CD, monitoring, secrets management, and deployment tooling automatically, from day one. This is what large engineering organisations like Spotify (Backstage), Netflix, and Airbnb have built internally — and what open-source platforms like Backstage and Port are now making available to smaller organisations.

You do not need to build a platform to benefit from CI/CD. But understanding where platform engineering sits helps you see the trajectory — CI/CD is not the destination, it is the foundation that everything else is built on.

Warning: Buying the Tools Does Not Mean You Have DevOps

The most common failure mode for DevOps adoption is treating it as a tooling purchase rather than a cultural change. A team can have GitHub Actions, Terraform, Datadog, and Kubernetes — and still operate in silos, still blame each other for outages, still hold monthly release calls, and still fear production. The tools enable DevOps; they do not create it. If developers are not responsible for what runs in production, and operations teams do not understand the code, adding more tooling will not help.

Key Takeaways from This Lesson

DevOps is about shared ownership, not tools — it is the philosophy that developers and operations share responsibility for what runs in production. CI/CD is how that philosophy is implemented day-to-day.
The Three Ways frame how DevOps organisations think — Flow (move work fast), Feedback (catch problems early), and Continual Learning (experiment and improve). CI/CD is the technical implementation of all three.
CI/CD sits at the centre of a broader toolchain — source control, artifact registries, secrets management, observability, container orchestration, and feature flags all connect to and depend on the pipeline.
Mature DevOps teams ship without ceremony — multiple deployments per day, no deployment meetings, no release windows, no six-person calls. The pipeline handles what humans used to manage manually.
Platform engineering is where mature organisations go next — standardising the pipeline and toolchain into an internal developer platform so every team gets CI/CD, monitoring, and deployment tooling without configuring it from scratch.
DevOps is not a job title — a "DevOps Engineer" who owns the pipeline while everyone else works in silos is not DevOps. The shared ownership and responsibility must be cultural, not just organisational.
Buying tools does not create DevOps culture — organisations that deploy the entire toolchain without changing how teams collaborate and own production will see the same silos, blame, and fear they had before.
CI/CD is the foundation, not the destination — it enables everything else in the modern DevOps stack. Section II builds on this foundation by going deep into how each stage of the pipeline actually works.

Teacher's Note

When you join a new team, the fastest way to understand its DevOps maturity is one question: "Who gets woken up when production breaks?" If the answer is "operations," the wall is still there.

Practice Questions

Answer in your own words — then check against the expected answer.

1. What is the name of the framework from The DevOps Handbook that describes the principles behind high-performing engineering organisations — covering Flow, Feedback, and Continual Learning?



2. What is the discipline called — practised by large engineering organisations like Spotify and Netflix — where a dedicated team builds and maintains a standardised internal developer platform so that product teams get CI/CD and tooling automatically?



3. What is the core principle that separates genuine DevOps from simply buying a set of DevOps tools — the idea that developers and operations teams are both responsible for what runs in production?



Lesson Quiz

1. A colleague says their company "does DevOps" because they hired a DevOps Engineer to manage the pipeline. What is the most accurate response?


2. A CI pipeline reports a failing test within 3 minutes of a commit, while the developer is still working on the same task. Which of the Three Ways does this most directly implement?


3. What is the goal of platform engineering in a mature DevOps organisation?


Up Next · Lesson 11

Source Code Management

Every pipeline starts with a commit. Section II opens with source code management — how Git branching strategies, pull request workflows, and repository structure directly shape how your pipeline behaves.