DevOps Foundations: Core Concepts and Fundamentals

Level: Beginner to Intermediate
Prerequisites: General familiarity with the software development lifecycle (IT or programming)

Table of Contents

1. Course Overview
2. Understanding Lean Software Development
   • The Origins of Lean
   • The 7 Principles of Lean Development
   • The 7 Wastes
   • Quality in a Lean Context
3. What DevOps Replaces
   • The Atomic Unit of DevOps: The Build
   • Architecture That Enables DevOps
   • Infrastructure as Code (IaC)
   • Secrets and Security in DevOps
4. Verifying Knowledge in DevOps
   • Change as a Constant
   • Unit Tests and Knowledge Creation
   • The Big Win: Automated Deployment
   • The Database Paradox
5. Adopting DevOps in the Enterprise
   • Who Loses in DevOps?
   • DevOps Adoption Story
   • Implementing Without Alienating
6. Reference Diagrams
7. DevOps Concept Reference Tables
8. Summary and Roadmap

1. Course Overview

This course covers the great founding ideas of DevOps — the ones the instructor wishes he had known from the start. Rather than teaching specific tools, it establishes the philosophical and practical principles underlying every successful DevOps initiative.

Main Topics Covered

The Central Proposition

“In science and technology, we grossly underestimate the value of certainty.”

DevOps, at its essence, is a system for creating certainty about the state of your software at any moment. This is the thread connecting Lean, automated testing, builds, and deployments.

2. Understanding Lean Software Development

The Origins of Lean

Lean finds its roots in Japan, in the story of the Toyoda family. Sakichi Toyoda, a young boy in the 19th century, watched his mother weave by hand for hours, in repetitive movements. Rather than accepting this waste of human potential, he sought to eliminate it.

This fundamental observation — placing the human being at the center of the analysis and identifying the core problem as the liberation of human potential — is the heart of Lean.

Toyoda invented automatic steam looms, and this philosophy evolved into what we call the Toyota Production System (TPS). His son Kiichiro then applied it to automobile manufacturing, creating Toyota Motor Corporation.

timeline
    title Evolution from Lean to DevOps
    1891 : Sakichi Toyoda invents the automatic loom
    1930s : Kiichiro Toyoda founds Toyota Motor Corporation
    1950s : Toyota Production System (TPS) formalized
    1980s : Lean Manufacturing adopted in the West
    2003 : Lean Software Development (Poppendieck)
    2009 : DevOps Movement (Agile Conference, Ghent)
    2010s : DevOps mainstream in the IT industry

The 7 Principles of Lean Development

1. Build Quality In

Two types of inspection exist:

• After the process: find defects
• During or before the process: prevent defects

The Japanese concept poka-yoke (“error avoidance”) refers to built-in mechanisms that make errors impossible. Examples:

• Real-time form validation (not after submission)
• The GFCI circuit breaker in your kitchen
• A USB connector that can only be inserted one way
• The principle of least privilege in security

DevOps application: Automated tests are the poka-yoke of development. They make it impossible to deploy code without verifying it works.

2. Create Knowledge

“‘This assertion’ and ‘it is certain that this assertion is true’ are two separate propositions.”

Certainty must be created, not assumed. Ways to create knowledge include:

• Automated tests (the strongest proof)
• Code reviews via pull requests
• Successful builds
• Load testing
• Static analysis of code

Key principle: In software, you can’t assume that because 100kg holds on a bridge, 150kg will too. Software is not linear. Human testing alone is insufficient — when a tester finds a bug and you fix it, the tester must start over from the beginning.

3. Defer Commitment

Two types of decisions exist:

• Reversible decisions: can be made early, changed later
• Irreversible decisions: must be deferred as long as possible for the best information

The earlier a commitment is made, the greater the uncertainty around its fulfillment. Predictions made too early paradoxically reduce predictability. Reversibility has intrinsic value — this is the principle on which Amazon built its empire (easy return policy).

4. Deliver Fast

“Fast” means two related things:

1. Speed: deliver at the end of a sprint rather than after 6 months
2. Frequency: move from a quarterly cycle to a weekly cycle

“If it hurts, do it often.”

When you have to deliver every week, you don’t do the same things differently — you do entirely different things. You automate what wasn’t worth automating before. The pressure decreases because the next version comes next week.

5. Respect People

Quote from Fujio Cho, former Toyota President:

“It is not the conveyor that operates the men, it is the man who operates the conveyor — this is the first step toward respect for human independence.”

Respecting people means:

• Not treating people like machines
• Giving them power over what they are responsible for
• Allowing anyone to contribute
• Open systems where anyone can contribute outperform rigid hierarchical systems

6. Optimize the Whole

“The number one mistake of brilliant engineers is optimizing something that should not exist.”
— Elon Musk

“The best part is no part. The best process is no process.”
— Elon Musk

Optimizing individual parts doesn’t guarantee optimizing the whole. A manager who refuses automated tests because they “lengthen development” suboptimizes their department at the expense of the overall system.

7. Eliminate Waste

See next section.

The 7 Wastes

The Poppendiecks identify seven primary wastes in software development, adapted from TPS’s 7 mudas:

Exponential Cost of Defects by Detection Time

Discovered by customer        ████████████████████████████████  Maximum cost
Discovered before release     ████████████████  
Discovered in code review     ████████
Discovered in development     ████
Discovered by TDD             ██                                 Minimum cost

Quality in a Lean Context

Pareto Analysis (80/20 rule): 80% of problems come from 20% of causes. In practice, most bugs come from a “bad neighborhood” in the code — an area everyone knows is fragile and risky. This is precisely where to go first.

3. What DevOps Replaces

Evolution of Complexity

Starting from a real scenario: a web application with a single developer. The success rate of manual deployments is about 70%. What may seem acceptable actually creates massive technical debt that worsens with every added complexity.

Classic pre-DevOps problems:

• Divergent environments: each developer’s machine is different
• Deploying from local machine: deploying the currently checked-out branch (not necessarily the right one)
• Undeclared dependencies: “it works on my machine”
• No rollback: undoing a deployment is as hard as the deployment itself

The Atomic Unit of DevOps: The Build

The automated build is the very first step toward DevOps. Its minimal definition: a single-click (or single-push) process that builds the software from source code in version control.

What the build accomplishes:

1. Deploy from a single source: the master branch (or designated deployment branch) — never from a developer’s machine
2. Deployment poka-yoke: impossible to accidentally deploy the wrong branch
3. Forced conflict resolution: developer must merge their changes into master before the build, forcing early conflict resolution
4. Detection of missing dependencies: if code doesn’t compile on the build server, there was an undeclared local dependency

Minimal example (.NET Core stack):

# Create a project
dotnet new webapp --name BuildWebApp

# Build the project (that's it!)
dotnet build

The simplicity is intentional. If your code isn’t structured to run dotnet build (or npm install && npm run build, or mvn package) without special configuration, that’s technical debt to fix immediately.

Architecture That Enables DevOps

Monolithic architecture couples all code together. When this monolith is complex, its fate is tied to a single deployment pipeline, and simple parts pay the price for complex parts.

Microservices architecture solves this by isolating complexity domains:

• Complex business logic (e.g., stock option calculations) lives in its own service
• The website with login and static pages lives in another service
• Each service can be deployed, tested, and scaled independently

Infrastructure as Code (IaC)

Simple definition: A script to build your infrastructure from scratch.

Without IaC, you must accept on faith that the target environment is properly configured. With IaC, you can:

• Rebuild infrastructure after a catastrophic crash
• Scale horizontally by adding identical servers
• Reproduce the production environment exactly in staging
• Version infrastructure like you version code

“Everything belongs in version control. Everything — except secrets.”

Common IaC approaches:

Container advantage: A Dockerfile is a particularly powerful IaC because it encapsulates not only infrastructure configuration but also the application runtime. The container becomes the immutable deployable artifact.

Secrets and Security in DevOps

Absolute rule: secrets never go into version control.

Version control systems are explicitly designed to make data difficult to permanently delete. A committed secret potentially becomes accessible in Git history forever.

How to manage secrets in DevOps:

What belongs in version control:

• ✅ Source code
• ✅ Build scripts
• ✅ Infrastructure configuration (IaC)
• ✅ Database migration scripts
• ✅ Dockerfile
• ❌ Passwords
• ❌ API keys
• ❌ Private certificates
• ❌ Customer/production data

4. Verifying Knowledge in DevOps

Change as a Constant

“Change is the only constant.”
— Heraclitus, ~500 BC

In a healthy organization, change is fractal: not only will things change, but how they change will change. DevOps is precisely the system that allows navigating this change with confidence, by continuously and automatically creating knowledge.

Unit Tests and Knowledge Creation

Every test — absolutely every test — has three components:

1. EXPECTATION  →  What we expect
2. OBSERVATION  →  What we actually observe
3. RECONCILIATION → The comparison (Assert.AreEqual, etc.)

Any of the three can be wrong. If the expectation is wrong, the system works correctly by its own rules — it’s the definition of behavior that must change, not the code.

Minimal example (C# .NET):

// In the main project
public class BusinessLogic
{
    public int GetBusinessValue()
    {
        return 5;
    }
}

// In the test project
[TestMethod]
public void TestGetBusinessValue()
{
    var logic = new BusinessLogic();
    var observation = logic.GetBusinessValue();
    Assert.AreEqual(5, observation); // Expectation = 5, Observation = result
}

What unit tests prove:

• Code behaves as expected under specific conditions
• Future changes don’t break existing behavior (regression)
• Business logic is correct, documented, and verifiable

Integration in the build pipeline:

dotnet build
dotnet test --collect:"Code Coverage"

If tests fail, the pipeline stops. Code cannot be deployed with failing tests.

The Big Win: Automated Deployment

The three great wins of DevOps, by value:

“If the idea of automating your deployment seems impossible, that project is precisely the one that needs it most.”

Progressive approach: Don’t try to automate 100% of the deployment at once.

• Automate what you can
• Accept a manual step where necessary
• Progressively eliminate each manual step

What a complete deployment pipeline accomplishes:

Code pushed → Build → Tests → Package → [Manual approval?] → Deploy Staging → Deploy Production

The Database Paradox

Databases are DevOps’ special case. They must simultaneously be:

• Consistent (existing data doesn’t change during a deployment)
• Changing (schema must evolve with the application)

The solution: database migrations

-- Migration V1: Initial state
CREATE TABLE Users (FullName NVARCHAR(255));

-- Migration V2: Split FullName into FirstName + LastName
ALTER TABLE Users ADD FirstName NVARCHAR(127);
ALTER TABLE Users ADD LastName NVARCHAR(127);
UPDATE Users SET 
    FirstName = SUBSTRING(FullName, 1, CHARINDEX(' ', FullName) - 1),
    LastName = SUBSTRING(FullName, CHARINDEX(' ', FullName) + 1, LEN(FullName));
ALTER TABLE Users DROP COLUMN FullName;

Common migration tools:

The database maintains an internal table of already executed migrations. Each migration is idempotent and runs only once.

5. Adopting DevOps in the Enterprise

Who Loses in DevOps?

DevOps forces everyone to stop pretending to know more than they actually know. This upsets those who benefit from ambiguity.

Example: the test coverage requirement

Scenario: you propose reaching 85% test coverage (100% for new code, progressive backfill for existing).

Typical objection: “That will double my development time.”

Two Types of Resistance

Caution: Before diagnosing a “heart problem” in others, verify the problem isn’t with you.

DevOps Adoption Story

The instructor describes a real DevOps adoption in a software consulting firm, about 10 years before “DevOps” was a common term:

Implemented steps:

1. Unit testing: initial resistance, partial coverage, but bugs start getting regression tests
2. Software builds: initially difficult (dependencies installed locally on developer machines), eventually resolved
3. Continuous Integration: builds triggered automatically on each commit (using Subversion at the time)
4. Automated deployment: the great transformation

Key lesson: Continuous integration means each developer merges to trunk/master regularly (at least once a day). Long-lived feature branches create integration debt — the more the branch diverges, the more painful the merge.

Implementing Without Alienating

The andon principle

The Japanese concept andon in TPS is a mechanism that allows any worker to pull a cord and stop the production line if they detect a problem.

DevOps application of andon:

• Any team member can block a deployment
• Automated tests are an automatic andon
• Mandatory code reviews are a human andon
• Feature flags allow “pulling the cord” in production without reverting

In practice: Create a culture where anyone can say “stop” without fear of reprisal. This is difficult in hierarchical organizations, but it’s what distinguishes safe organizations from dangerous ones.

6. Reference Diagrams

DevOps Cycle — CALMS Framework

flowchart LR
    C["Culture\n─────────\nBreak down silos\nDev + Ops together\nShared responsibility"]
    A["Automation\n─────────\nAutomated build\nAutomated testing\nAutomated deployment"]
    L["Lean\n─────────\nEliminate waste\nOptimize flow\nDeliver often"]
    M["Measurement\n─────────\nPerformance metrics\nCycle time\nFailure rate"]
    S["Sharing\n─────────\nTransparency\nBlameless post-mortems\nSpread best practices"]

    C --> A --> L --> M --> S --> C

    style C fill:#4A90D9,color:#fff
    style A fill:#27AE60,color:#fff
    style L fill:#E67E22,color:#fff
    style M fill:#8E44AD,color:#fff
    style S fill:#C0392B,color:#fff

DevOps Feedback Loop

flowchart TD
    Plan["Plan\nUser stories\nBacklog grooming\nSprint planning"] 
    Code["Code\nDevelopment\nCode review\nPull request"]
    Build["Build\nCompilation\nStatic analysis\nDependencies"]
    Test["Test\nUnit tests\nIntegration tests\nSecurity scan"]
    Release["Release\nArtifact creation\nVersioning\nChangelog"]
    Deploy["Deploy\nStaging\nProduction\nFeature flags"]
    Operate["Operate\nMonitoring\nAlerting\nIncident response"]
    Monitor["Monitor\nLogs\nMetrics\nTracing"]

    Plan --> Code --> Build --> Test --> Release --> Deploy --> Operate --> Monitor
    Monitor -->|"Fast feedback\n(minutes)"| Code
    Monitor -->|"Strategic feedback\n(weeks)"| Plan

DORA Metrics (DevOps Research and Assessment):

7. DevOps Concept Reference Tables

Core DevOps Tools

The Build → Test → Deploy Checklist

8. Summary and Roadmap

DevOps Adoption Checklist

Phase 1 — Foundations (weeks 1-4)

• All code is in version control (Git)
• An automated build exists (one command, reproducible)
• The deployment branch is defined and documented
• Secrets are removed from source code

Phase 2 — Quality (weeks 5-8)

• Unit tests exist for critical business logic
• Tests run automatically in the build
• A minimum coverage threshold is defined
• A code review process is in place

Phase 3 — Delivery (weeks 9-16)

• A CI/CD pipeline is configured
• Staging deployments are automated
• Manual approval gates exist for production
• Database migrations are scripted and versioned

Phase 4 — Maturity (ongoing)

• IaC for the production environment
• Monitoring and alerting in place
• Feature flags for risky deployments
• Blameless post-mortems after incidents
• DORA metrics tracked and improved

Philosophical Formulas from the Course

Further Reading

Search Terms

devops · foundations · core · concepts · fundamentals · ci/cd · git · lean · knowledge · adoption · checklist · development · quality · reference · unit