LFCA 81 🐧 What DevOps Is
DevOps is a set of practices, cultural philosophies, and tools that integrate software development and IT operations. It is not a job title, a tool, or a single methodology. It is a response to a specific problem: the wall between the people who write software and the people who run it. That wall produces slow releases, finger-pointing when things break, and a constant tension between “we need to ship features” and “we need to keep the system stable.”
The LFCA exam places DevOps under DevOps Fundamentals, which carries 12–16% of the total weight. The study plan lists “DevOps Basics” and “Deployment Environments” as core topics. The exam expects you to understand what DevOps is, why it emerged, and how it changes the way teams build and operate software.
Key point: DevOps is not a tool. Tools like Docker, Kubernetes, Jenkins, and Terraform are enablers. They make DevOps practices possible at scale. But a team that uses all the tools without changing how it works is not doing DevOps. The culture comes first. The tools amplify it.
Why DevOps exists
Before DevOps, development and operations were separate teams with separate goals. Development was measured by features shipped. Operations was measured by uptime. These goals conflicted.
The wall problem. Developers wrote code and threw it over the wall to operations. Operations deployed it, managed it, and got paged when it broke. When something failed, operations blamed the code. Development blamed the infrastructure. Neither team had the full picture, and neither team had the incentive to fix the other’s problem.
The release problem. Releases were infrequent and risky. A release was a major event that required coordination between teams, a maintenance window, and a rollback plan. The longer the gap between releases, the more changes were bundled together, and the harder it was to identify what caused a failure. A single release could contain hundreds of changes, and the team had no way to isolate the one that broke production.
The feedback problem. Developers did not see the consequences of their code. They did not have access to production logs. They did not know how the application performed under real load. The feedback loop between writing code and seeing its impact was measured in weeks or months. By the time a problem was discovered, the developer had moved on to another task.
The automation problem. Manual deployments were the norm. An operations engineer followed a runbook, typed commands, and verified each step. The process was slow, error-prone, and impossible to reproduce. When it failed, the recovery was another manual process, often performed under pressure.
The trade-off. DevOps changes the structure of teams and the distribution of responsibility. Developers are expected to understand operations. Operations is expected to understand code. The boundary shifts. Some engineers resist the change because it expands their responsibilities. The resistance is real, but the alternative is the wall.
a. The Core Principles
DevOps is built on a set of principles that guide how teams work. The principles are not new. They come from lean manufacturing, agile software development, and systems thinking. What DevOps does is apply them to the entire software delivery lifecycle, not just the development phase.
Collaboration. Development and operations work together, not in sequence. The same team that writes the code is involved in deploying it and running it. The shared responsibility eliminates the “throw it over the wall” dynamic. The team owns the feature from idea to production .
Automation. Manual processes are replaced with automated pipelines. Building, testing, deploying, and monitoring are automated. The automation is not just for speed. It is for consistency. A manual process executed by a human can produce different results each time. An automated process produces the same result every time .
Continuous improvement. The team measures everything: deployment frequency, lead time for changes, mean time to recovery, change failure rate. These four metrics are the DORA metrics, and they are the standard measure of DevOps performance. The team uses the measurements to identify bottlenecks and improve the process .
Customer focus. DevOps is not about the process for its own sake. It is about delivering value to the customer faster and more reliably. The process exists to serve the outcome. When the process becomes the goal, it has lost its purpose.
Shared responsibility. The team owns the entire lifecycle. There is no “that’s not my job” when something breaks. The developer who wrote the code is the first person to look at the logs. The operations engineer who deployed it is involved in the design. The boundary between the roles is blurred by design .
b. The DevOps Lifecycle
DevOps is often described as an infinite loop with eight phases. Each phase flows into the next, and the end of the loop feeds back into the beginning.
Plan. The team defines the feature, estimates the work, and prioritizes it. The output is a backlog of work items.
Code. The team writes the code. The code is version-controlled. The branches are short-lived. The code is reviewed before it is merged.
Build. The code is compiled, packaged, and versioned. The build is automated. The artifact is stored in a registry.
Test. The automated tests run. The tests include unit tests, integration tests, and end-to-end tests. The tests are fast and reliable. A failing test blocks the pipeline.
Release. The artifact is prepared for deployment. The release is versioned and tagged. The release notes are generated.
Deploy. The artifact is deployed to the target environment. The deployment is automated. The deployment is reversible. The deployment is monitored.
Operate. The application runs in production. The team monitors its health, its performance, and its error rate. The team responds to incidents.
Monitor. The team collects metrics, logs, and traces. The data is used to identify problems and improve the process. The feedback loops back into the plan phase .
The lifecycle is not a waterfall. The phases overlap. A team might deploy a fix while planning the next feature. The point is that the entire lifecycle is continuous, and the team owns all of it.
c. DevOps vs Traditional IT Operations
The difference between DevOps and traditional IT operations is not just the tools. It is the structure, the incentives, and the culture.
Traditional operations separates development and operations into different teams with different managers. The development team writes code and hands it to operations. The operations team deploys it and manages it. The handoff is a formal process with documents and sign-offs. The feedback loop is slow. The responsibility is fragmented.
DevOps integrates development and operations into a single team or a tightly coupled set of teams. The same team writes the code, deploys it, and operates it. The handoff is eliminated. The feedback loop is fast. The responsibility is shared.
The deployment frequency difference. A traditional team might deploy once a quarter. A DevOps team might deploy multiple times per day. The difference is not just speed. It is risk. A small, frequent deployment is easier to debug than a large, infrequent one. If something breaks, the team knows exactly what changed.
The recovery difference. A traditional team might take hours or days to recover from a failure. A DevOps team might take minutes. The difference is the automation, the monitoring, and the shared responsibility. The team that wrote the code is the team that fixes it.
The culture difference. Traditional operations values stability and control. DevOps values speed and learning. The shift is not just technical. It is a change in what the team values and how it measures success .
Complete Example Session
This session demonstrates the DevOps lifecycle through a simple application: writing code, building an artifact, deploying it, and monitoring it.
# ============================================
# PART 1: THE APPLICATION
# ============================================
# A simple Node.js application with a health endpoint.
# src/index.js
# const express = require('express');
# const app = express();
# app.get('/health', (req, res) => res.json({ status: 'ok' }));
# app.listen(3000);
# ============================================
# PART 2: THE VERSION CONTROL
# ============================================
# The code is stored in Git.
git init
git add .
git commit -m "Initial commit"
# A feature branch is created.
git checkout -b feature/health-endpoint
# The code is pushed to the remote.
git push origin feature/health-endpoint
# ============================================
# PART 3: THE CI PIPELINE
# ============================================
# The CI pipeline runs on every push.
# .github/workflows/ci.yml
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npm test
- run: docker build -t my-app:${{ github.sha }} .
# ============================================
# PART 4: THE BUILD ARTIFACT
# ============================================
# The build produces a Docker image.
docker build -t my-app:1.0.0 .
# The image is tagged with the Git commit SHA.
docker tag my-app:1.0.0 my-registry/my-app:abc123
# The image is pushed to the registry.
docker push my-registry/my-app:abc123
# ============================================
# PART 5: THE DEPLOYMENT
# ============================================
# The deployment is automated.
# A Kubernetes manifest describes the desired state.
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: my-registry/my-app:abc123
ports:
- containerPort: 3000
# The manifest is applied.
kubectl apply -f deployment.yaml
# ============================================
# PART 6: THE MONITORING
# ============================================
# The application exposes metrics.
# Prometheus scrapes the metrics.
# Grafana displays the dashboards.
# The four DORA metrics are tracked:
# 1. Deployment frequency
# 2. Lead time for changes
# 3. Mean time to recovery
# 4. Change failure rate
# ============================================
# PART 7: THE INCIDENT
# ============================================
# A new version is deployed.
kubectl set image deployment/my-app my-app=my-registry/my-app:def456
# The error rate increases.
# The alert fires.
# The team receives a notification.
# ============================================
# PART 8: THE ROLLBACK
# ============================================
# The team rolls back to the previous version.
kubectl rollout undo deployment/my-app
# The error rate returns to normal.
# The team investigates the cause.
# ============================================
# PART 9: THE POST-MORTEM
# ============================================
# The team writes a post-mortem.
# The post-mortem is blameless.
# It identifies the root cause and the action items.
# The fix is implemented.
# The pipeline is updated to catch the issue.
# ============================================
# PART 10: THE CYCLE CONTINUES
# ============================================
# The team plans the next feature.
# The cycle begins again.
# Each iteration is faster and more reliable than the last.The ten parts cover the application, version control, the CI pipeline, the build artifact, deployment, monitoring, an incident, the rollback, the post-mortem, and the continuing cycle.
Quick Reference
The DevOps Principles
| Principle | Description |
|---|---|
| Collaboration | Development and operations work together |
| Automation | Manual processes are replaced |
| Continuous improvement | Measure, learn, improve |
| Customer focus | Deliver value to the customer |
| Shared responsibility | The team owns the entire lifecycle |
The DevOps Lifecycle
| Phase | Activity |
|---|---|
| Plan | Define and prioritize work |
| Code | Write and review code |
| Build | Compile and package |
| Test | Run automated tests |
| Release | Prepare the artifact |
| Deploy | Deploy to the environment |
| Operate | Run in production |
| Monitor | Collect metrics and logs |
The DORA Metrics
| Metric | Definition |
|---|---|
| Deployment frequency | How often code is deployed |
| Lead time for changes | Time from commit to production |
| Mean time to recovery | Time to recover from a failure |
| Change failure rate | Percentage of deployments that cause a failure |
The DevOps vs Traditional
| Aspect | Traditional | DevOps |
|---|---|---|
| Team structure | Separate dev and ops | Integrated |
| Deployment frequency | Quarterly | Multiple per day |
| Recovery time | Hours or days | Minutes |
| Responsibility | Fragmented | Shared |
| Culture | Stability and control | Speed and learning |
The Key Tools
| Category | Tools |
|---|---|
| Version control | Git |
| CI/CD | Jenkins, GitHub Actions, GitLab CI |
| Containers | Docker, Podman |
| Orchestration | Kubernetes |
| Configuration | Ansible, Terraform |
| Monitoring | Prometheus, Grafana, Datadog |
Best Practices
✅ Do This:
# Automate the build and test pipeline
# Every push triggers the pipeline # ✅# Deploy small, frequent changes
# Small changes are easier to debug # ✅# Monitor the four DORA metrics
# Measure deployment frequency, lead time, MTTR, change failure rate # ✅# Write blameless post-mortems
# Focus on the system, not the person # ✅# Share responsibility between development and operations
# The team owns the entire lifecycle # ✅❌ Don’t Do This:
# Don't deploy large, infrequent releases
# They are harder to debug and riskier # ❌# Don't blame individuals for failures
# Blame the system and improve the process # ❌# Don't treat DevOps as a tool
# Tools enable the culture; they are not the culture # ❌# Don't skip the post-mortem
# The post-mortem is how the team learns # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| DevOps becomes a job title | The culture is ignored | Focus on the practices, not the title |
| Tools without culture | The tools are adopted without the principles | Start with collaboration |
| No automation | Manual processes remain | Automate the pipeline |
| No measurement | The team does not know if it is improving | Track the DORA metrics |
| Blame culture | Failures are punished | Adopt blameless post-mortems |
Real-World Examples
1. Version Control
git commit -m "Add health endpoint"2. CI Pipeline
- run: npm test
- run: docker build -t my-app .3. Build Artifact
docker build -t my-app:1.0.0 .4. Deployment
kubectl apply -f deployment.yaml5. Rollback
kubectl rollout undo deployment/my-app6. Monitoring
# Prometheus + Grafana7. DORA Metrics
# Deployment frequency, lead time, MTTR, change failure rate8. Post-Mortem
# Blameless analysis of the incident9. Automation
# The pipeline runs on every push10. Continuous Improvement
# Measure, learn, improve, repeatVisual
The DevOps Lifecycle
┌──────────────────────────────────────────────┐
│ DEVOPS LIFECYCLE │
│ │
│ Plan │
│ │ │
│ ▼ │
│ Code │
│ │ │
│ ▼ │
│ Build │
│ │ │
│ ▼ │
│ Test │
│ │ │
│ ▼ │
│ Release │
│ │ │
│ ▼ │
│ Deploy │
│ │ │
│ ▼ │
│ Operate │
│ │ │
│ ▼ │
│ Monitor │
│ │ │
│ └──────────> Plan │
│ │
│ The loop is continuous. │
│ │
└──────────────────────────────────────────────┘The DevOps vs Traditional
┌──────────────────────────────────────────────┐
│ TRADITIONAL │
│ Dev team ──handoff──> Ops team │
│ Wall between them. │
│ Slow feedback. │
│ Separate goals. │
│ │
│ DEVOPS │
│ Dev + Ops ──> One team │
│ Shared responsibility. │
│ Fast feedback. │
│ Shared goals. │
│ │
│ The wall is removed. │
│ │
└──────────────────────────────────────────────┘The DORA Metrics
┌──────────────────────────────────────────────┐
│ DORA METRICS │
│ │
│ Deployment frequency: │
│ How often code is deployed │
│ │
│ Lead time for changes: │
│ Time from commit to production │
│ │
│ Mean time to recovery: │
│ Time to recover from a failure │
│ │
│ Change failure rate: │
│ Percentage of deployments that fail │
│ │
│ These four metrics measure DevOps │
│ performance. │
│ │
└──────────────────────────────────────────────┘The Toolchain
┌──────────────────────────────────────────────┐
│ DEVOPS TOOLCHAIN │
│ │
│ Version control: Git │
│ CI/CD: Jenkins, GitHub Actions │
│ Containers: Docker, Podman │
│ Orchestration: Kubernetes │
│ Config: Ansible, Terraform │
│ Monitoring: Prometheus, Grafana │
│ │
│ Tools enable the practices. │
│ The culture comes first. │
│ │
└──────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| DevOps definition | Practices, culture, and tools integrating development and operations |
| Core principles | Collaboration, automation, continuous improvement, customer focus, shared responsibility |
| Lifecycle phases | Plan, Code, Build, Test, Release, Deploy, Operate, Monitor |
| DORA metrics | Deployment frequency, lead time, MTTR, change failure rate |
| Key tools | Git, Jenkins, Docker, Kubernetes, Prometheus |
| LFCA weight | DevOps Fundamentals, 12–16% |
Key takeaways:
- DevOps is not a tool. It is a set of practices and a culture. Tools like Docker, Kubernetes, and Jenkins enable the practices, but they are not the practices themselves. A team that uses the tools without changing how it works is not doing DevOps.
- DevOps emerged to solve the wall between development and operations. Development was measured by features shipped. Operations was measured by uptime. The goals conflicted. DevOps integrates the teams and shares the responsibility .
- The core principles are collaboration, automation, continuous improvement, customer focus, and shared responsibility. These principles guide how the team works. They are not new — they come from lean manufacturing and agile development — but DevOps applies them to the entire lifecycle .
- The DevOps lifecycle is an infinite loop with eight phases. Plan, Code, Build, Test, Release, Deploy, Operate, Monitor. The end of the loop feeds back into the beginning. The team owns all of it .
- The four DORA metrics measure DevOps performance. Deployment frequency, lead time for changes, mean time to recovery, and change failure rate. The metrics reveal bottlenecks and guide improvement .
- Traditional operations separates development and operations. DevOps integrates them. The difference is not just the team structure. It is the incentives, the feedback loop, and the culture .
- The LFCA exam places DevOps under DevOps Fundamentals, which carries 12–16% of the total weight. The exam expects you to understand the principles, the lifecycle, and the tools that enable the practices.
Remember: DevOps is a response to a specific problem: the wall between the people who write software and the people who run it. The wall produces slow releases, finger-pointing, and a constant tension between speed and stability. DevOps removes the wall by integrating the teams, automating the pipeline, and sharing the responsibility. The tools are the enablers. The culture is the foundation. The lifecycle is the process. The metrics are the measure. And the goal is to deliver value to the customer faster and more reliably.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!