From Commit to Container

1.1 The definition

The name is the two job titles joined. Dev writes the features. Ops runs the servers. Before DevOps they usually sat in separate teams with opposite goals: developers were rewarded for shipping changes, and operations was rewarded for keeping things stable, and every change is a risk to stability. So releases were rare, large and stressful.

The slide's point is that DevOps is more than tools. You can install Jenkins and Docker and still have two teams throwing work over a wall. It's a way of working where the same people care about the code and about how it runs.

1.2 Where it came from

Waterfall ran each phase once, in order: requirements, design, implementation, testing, then deployment. You found out whether it worked at the very end. Agile cut the work into short sprints so the software is built and checked in small pieces. Agile fixed the development side, but deployment was still slow and manual. DevOps extends the same idea, small and frequent, all the way to production.

What do teams actually get from it? The slide lists four things: better collaboration, more efficiency, faster time to market, and higher quality and security. The last one surprises people, because shipping more often sounds riskier. It isn't, because each release is small and goes through the same automated checks.

1.3 The Three Ways

Gene Kim, author of The Phoenix Project and The DevOps Handbook, sums the principles up as three "ways".

1.4 The lifecycle

Every change goes round the loop in eight stages. Here's one real change, "add a /health endpoint", going all the way round. It's the change you make at the end of Lab 1.

1.5 Tools at each stage

Don't memorise the whole wheel below. Learn one tool per stage well. The ones this course actually uses are Git, GitHub Actions and Docker.

2.1 The DevOps engineer

The roadmap on the slide is the skill list for the job, in roughly the order you learn it: Linux and networking, then Git, CI/CD pipelines, containers and Kubernetes, infrastructure as code, cloud, then security, monitoring and reliability engineering. This course covers the middle of it: Git, CI/CD and containers.

2.2 Git triggers everything

In DevOps, Git is the single source of truth. If it isn't committed, it doesn't exist: the code, the tests, the pipeline file and even the server configuration all live in the repository. That matters because Git events are what start the automation.

The four events on the slide are push, pull_request, merge and tag. A workflow file chooses which ones it listens to with its on: block. This is the one from Lab 1:

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

2.3 The pull request workflow

1. Create a feature branch from main: git checkout -b feature/health-route.
2. Commit your changes on that branch and push it.
3. Open a pull request (PR). CI runs the tests on it automatically.
4. A teammate reviews the code. The PR can't merge while CI is red, if the repository is set up that way.
5. Merge into main. CI runs again on the merged code.

The point of the branch is that main always works. Nobody's half-finished code lands there, and nothing lands there untested.

2.4 Continuous integration

"Integration" is the hard part it's named after. If five people each work alone for a month and then merge, you get a month of conflicts at once. If they merge every day, each merge is small, and when the build breaks you know it was today's change.

The slide's five steps to set it up:

1. Write tests for the critical parts of your code.
2. Get a CI service to run them on every push.
3. Integrate your changes every day.
4. Fix the build as soon as it breaks.
5. Write tests for every new feature.

Step 4 is the cultural one. A red build that everyone ignores is worse than no CI at all, because people stop trusting the signal.

2.5 Continuous delivery vs continuous deployment

CD has two meanings, and the difference is one step.

• Continuous delivery: every change that passes is automatically packaged and released to a repository, ready to deploy. A person presses the button to put it in production.
• Continuous deployment: no button. If it passes, it goes to production automatically.

Why would anyone keep the button? Some releases need a human decision: a marketing launch date, an app store review, a bank's change approval. Continuous deployment needs a lot of trust in your tests, because nothing stands between them and your users.

The benefits on the slide follow from automation: fewer bugs reach users, less manual work, faster and less risky releases, and quicker user feedback.

2.6 CI/CD vs DevOps

CI/CD is a part of DevOps. CI/CD covers getting code from a commit to a release: version control, integration, testing and deployment. DevOps covers the whole loop, including planning, running the service and monitoring it, plus the culture around all of it.

3.1 Why test, and when

The big change in DevOps is when testing happens. It used to be a phase at the end. Now it runs through the whole lifecycle, which is called continuous testing. Two phrases on the slides describe the direction:

• Shift left: test earlier, while you write the code. A bug found by a unit test on your laptop costs you a minute. The same bug found in production costs an incident.
• Shift right: keep checking after release, by monitoring real use in production.

The slide's example of a costly defect is Delta Air Lines in 2024: a faulty update crashed systems worldwide and cost Delta about $500 million.

3.2 Manual vs automated

3.3 TDD and BDD

Test-driven development (TDD) writes the test before the code, in a short loop: red (write a test, watch it fail), green (write just enough code to pass), refactor (tidy the code while the test keeps you safe).

Try the loop. The tests below are already written, and the function is an empty stub, so every test starts red. Write the code until they're all green.

Behaviour-driven development (BDD) writes the expected behaviour in plain language first, so non-programmers on the team can read and agree on it. It uses Given / When / Then:

Given the user has entered a valid username and password,
When the user clicks the "Login" button,
Then the system should display a "Login Successful" message.

Tools like Cucumber turn each of those lines into an automated step. So BDD is TDD where the test is written as a sentence.

3.4 Functional and non-functional testing

The functional checks follow six steps: identify the functions, create input data, work out the expected outputs, run the test cases, compare actual with expected, and decide whether it passes.

3.5 The four levels

The five steps of unit testing on the slide: identify the unit, pick manual or a framework, set up the environment (test data, dependencies and mock objects that stand in for the real database), write the test cases, then debug and rerun. The frameworks listed: Jest and Mocha for JavaScript, JUnit for Java, NUnit for .NET, pytest for Python. Lab 1 uses Mocha.

Acceptance testing comes in several kinds: user (UAT), business (BAT), contract (CAT, against the agreed terms), regulation (RAT, such as health-data law), operational (OAT, is it ready to run), plus alpha testing in-house and beta testing by outside users before release.

3.6 Integration techniques

If you're testing how parts fit together, which parts do you put together first?

Tools on the slides: Postman for API tests, Katalon (built on Selenium), SoapUI, and Citrus for Java.

3.7 Linting

A linter reads your code without running it (static analysis) and flags mistakes and style problems: an unused variable, a misspelled name, == where you meant ===, inconsistent formatting. It runs in two places:

• Before committing, as a pre-commit hook, so bad code never reaches the repository.
• In the CI pipeline, so nobody can skip it. Lab 1 does this with yarn lint.

// ESLint would flag both of these:
const unused = 42;          // 'unused' is assigned a value but never used
if (user = admin) { … }     // assignment where a comparison was meant

3.8 Code coverage

Code coverage measures how much of your code ran while the tests ran. Tools report it four or five ways:

• Function: % of functions called.
• Statement: % of statements executed.
• Branch: % of the paths through each if/else taken.
• Condition: % of boolean conditions seen both true and false.
• Line: % of lines executed.

Pick which tests to run and watch the numbers.

4.1 What you build

A tiny Node.js web app whose only page says Hello, GitHub Actions!, plus a pipeline that lints, tests and measures coverage on every push and pull request. The app is deliberately boring. The pipeline is the point.

ci-cd-lab/
├── .github/
│   └── workflows/
│       └── ci.yml          ← the pipeline
├── test/
│   └── test.js             ← the tests
├── .gitignore
├── .yarnrc.yml
├── app.js                  ← the Express app
├── eslint.config.js        ← lint rules
├── package.json            ← dependencies and scripts
├── README.md
└── server.js               ← starts the app

The stack: Node.js 24, Yarn 4, Express 5, Mocha and Chai for tests, Supertest to call the app over HTTP, ESLint for linting, and c8 for coverage.

4.2 The app and its test

The app is split over two files on purpose. app.js defines the app and exports it:

import express from 'express';

const app = express();

app.get('/', (req, res) => {
  res.status(200).send('Hello, GitHub Actions!');
});

export default app;

server.js starts it on a port:

import app from './app.js';

const port = process.env.PORT ?? 3000;

app.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

import { expect } from 'chai';
import request from 'supertest';
import app from '../app.js';

describe('GET /', () => {
  it('returns HTTP 200', async () => {
    const response = await request(app).get('/');
    expect(response.status).to.equal(200);
  });

  it('returns the expected greeting', async () => {
    const response = await request(app).get('/');
    expect(response.text).to.equal('Hello, GitHub Actions!');
  });
});

describe and it come from Mocha, expect from Chai, and request(app) from Supertest. Both tests are unit-sized, but because they go through HTTP they're also a small integration test of Express and your route.

4.3 Lint, test, coverage

package.json names the commands, so everybody and CI run exactly the same thing:

"type": "module",
"packageManager": "yarn@4.18.1",
"scripts": {
  "start": "node server.js",
  "test": "mocha",
  "lint": "eslint .",
  "coverage": "c8 mocha"
}

• "type": "module" turns on import/export (ES modules).
• "packageManager" pins the Yarn version, so everyone installs the same way.
• c8 mocha runs the same tests while recording which lines ran, then prints the table and writes an HTML report to coverage/.

yarn install      # creates yarn.lock: commit it
yarn start        # open http://localhost:3000/
yarn lint
yarn test         # 2 passing
yarn coverage

  GET /
    ✔ returns HTTP 200
    1) returns the expected greeting

  1 passing (24ms)
  1 failing

  1) GET /
       returns the expected greeting:
     AssertionError: expected 'Hello, GitHub!' to equal 'Hello, GitHub Actions!'

4.4 The workflow file

.github/workflows/ci.yml is the pipeline. GitHub finds any YAML file in that folder and runs it on the events in on:.

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 24
          cache: yarn

      - name: Install dependencies
        run: yarn install --immutable

      - name: Run ESLint
        run: yarn lint

      - name: Run tests
        run: yarn test

      - name: Generate code coverage
        run: yarn coverage

      - name: Upload coverage HTML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: code-coverage-report
          path: coverage/
          if-no-files-found: ignore

      - name: Enable Corepack
        run: corepack enable

4.5 Run the pipeline

Pick what your commit did, then run it. Each step's log is shortened but follows what GitHub prints.

When a step fails, open its log on GitHub, fix the problem locally, run yarn lint, yarn test and yarn coverage yourself, then commit and push again. The run after a fix is just another push.

4.6 CI on a pull request

Step 14 proves the pull request half of on:. Make a branch, add a /health route and its test, and open a PR:

git checkout -b feature/health-route
# edit app.js and test/test.js
yarn lint && yarn test && yarn coverage
git add app.js test/test.js
git commit -m "Add health endpoint and test"
git push -u origin feature/health-route

One way to write it, so that the new test really checks the response:

// app.js
app.get('/health', (req, res) => {
  res.status(200).json({ status: 'ok' });
});

// test/test.js
describe('GET /health', () => {
  it('reports ok', async () => {
    const response = await request(app).get('/health');
    expect(response.status).to.equal(200);
    expect(response.body).to.deep.equal({ status: 'ok' });
  });
});

Open the pull request on GitHub. The CI checks appear on it, and merging it triggers one more run on main.

5.1 Bare metal

A bare-metal server is a physical computer with the operating system installed straight onto the hardware. Nothing sits in between. Each server usually did one job: one for the database, one for the website, one for email.

5.2 Virtual machines

Virtualization adds a layer, the hypervisor, between the hardware and the operating systems. It splits one physical machine into several isolated virtual machines (VMs), each with its own full operating system, and hands out the CPU, memory and storage between them. The technology dates from the 1960s, took off in the 2000s, and is what cloud computing is built on: an EC2 instance is a VM.

Benefits: cost savings, better use of hardware, VMs you can create, destroy and move between hosts, easier scaling and simpler disaster recovery. Drawbacks: the extra layer costs performance, the up-front investment is high, and there are now two things to manage, the physical hosts and every VM on them.

5.3 Containers

The key word is only. A VM carries a whole guest operating system. A container carries just your app and its libraries, and shares the host's kernel (the core of the OS). That's why containers start in about a second instead of booting, and are megabytes instead of gigabytes.

The architecture has four layers, bottom to top: the infrastructure (a laptop or a server), the host operating system, the container engine such as Docker Engine, and the containerized applications.

Benefits on the slide:

• Portability: build once, run anywhere. It ends "it works on my machine", because your machine's setup ships inside the container.
• Speed: no guest OS to boot.
• Isolation: each container has its own processes, network and file system view.
• Simpler operations: you manage standard containers, not hand-configured servers.
• Fast scaling: a traffic spike? Start more copies in seconds.

Process isolation is decades old. What changed things was Docker in 2013, which gave developers simple tools and one standard package format.

5.4 Compare the stacks

5.5 How a container is made

1. Define the environment in a Dockerfile: base image, copy the code, install dependencies, the start command.
2. Build an image: a read-only, layered package of the app and everything it needs. docker build
3. Store it in a registry such as Docker Hub, AWS ECR, GCP Artifact Registry or Azure Container Registry. docker push
4. Run it: the engine creates a container from the image. docker run

Step 4 is where the isolation comes from. The engine asks the host's kernel for:

• Namespaces: give the container its own process list, network stack and file system view, so it believes it's alone on the machine. Inside, your app is process 1.
• Resource limits (Linux calls them cgroups): cap its CPU and memory so one container can't starve the rest.

Tool types: a container engine runs containers (Docker Engine), an image builder makes images (docker build), a registry stores them, and an orchestrator runs them at scale.

5.6 Orchestration

A company can run hundreds or thousands of containers. Nobody starts those by hand. A container orchestration platform does it: it schedules containers onto machines, restarts the ones that crash, balances traffic between copies, and scales the number of copies up and down.

Kubernetes is the standard. Google open-sourced it, based on its internal system Borg. It works with any engine that follows the Open Container Initiative (OCI) standards. Alternatives: Docker Swarm for small clusters, Apache Mesos, Nomad, and managed services such as Amazon ECS/EKS, Google GKE and Azure AKS.

6.1 Architecture

Docker is a platform for building, shipping and running applications in containers. It uses a client-server design.

Client and daemon talk over a REST API, through a UNIX socket on the same machine or over the network, so your docker command can control a daemon on another server. Docker Compose is another client, for apps made of several containers, such as a web app plus its database.

6.2 Image vs container

An image holds everything the app needs: a base OS such as Ubuntu or Alpine, the code, the dependencies, and configuration like environment variables and the start command. A Dockerfile is the text file of instructions that builds it.

6.3 The Dockerfile

This is the Dockerfile on the slide, for a Node app:

FROM node:22-alpine
WORKDIR /app
COPY . .
RUN yarn install --production
CMD ["node", "./src/index.js"]

docker build -t my-app .            # build an image called my-app from ./Dockerfile
docker run -d -p 3000:3000 my-app    # start a container, map port 3000 to the host

6.4 Layer caching

Each instruction makes one layer, and Docker reuses a layer from the last build if nothing it depends on has changed. Once one layer changes, every layer after it is rebuilt. So the order of the lines decides how fast your rebuilds are.

That's why most real Dockerfiles copy package.json and the lockfile first, install, and only then copy the rest of the code. You change your code all day, and your dependencies rarely.

6.5 Try the commands

The slides end with KodeKloud's free docker run lab. Here's a safe practice terminal with the same commands. Click a command, or type one.

7.1 What is software architecture?

A system's architecture is its fundamental structure: the parts it's made of and how they interact. In practice it answers five questions:

1. How are the application's components organized?
2. How do the components communicate?
3. How is data stored and managed?
4. How is the application deployed?
5. How does it scale?

The last two are why this is a DevOps topic. Chapters 2–6 built the pipeline and the containers. Architecture decides how many things that pipeline has to build, test and deploy, and how they fail. The lecture's question for the cloud era: which model is best for you?

7.2 The monolith

A monolithic application is the traditional model: one program, with every feature packaged and deployed together. Its components are tightly coupled and share resources and one database. Any change means rebuilding and redeploying the whole thing.

A request goes in, the right module handles it, the app talks to the database, and the response comes back. The lecture's example is a user placing an order. All four modules run inside the same deployable application:

Monoliths are convenient early in a project: less code management, less to keep in your head, and everything ships at once.

7.3 Microservices

A microservices architecture splits the application into a set of independently deployable services. Each one has a specific business goal, its own logic and its own database. Updating, testing, deploying and scaling happen per service, and services talk to each other through simple interfaces.

Containers suit microservices well: each service is packaged with its own dependencies, so you can focus on the service and not on what's installed where. Modern cloud-native applications are usually microservices in containers, which is everything from Chapter 5 and Chapter 6 put to work.

Read the two tables side by side: almost every advantage of one is a disadvantage of the other. Choosing is a trade, not an upgrade.

7.4 Monolith or microservices?

The lecture asks you to choose for three scenarios, and to say what goes wrong if you choose badly. One reasonable answer:

7.5 Design principles

A circuit breaker works like the one in your house. After enough failed calls to a service, it "trips" and fails the next calls immediately for a while, instead of letting every caller wait for a timeout. That gives the struggling service room to recover.

7.6 Synchronous and asynchronous communication

7.7 Microservices need DevOps, and the tools that help

Microservices and DevOps enable and require each other. Microservices let teams build and deploy services independently. DevOps supplies the automation to build, test, deploy, monitor and operate them reliably. With 20 or 50 services, doing any of that by hand stops being possible.

7.8 Best practices

1. Don't start with microservices. Start with a monolith. Split it when it becomes hard to maintain, update or scale, and only where there's a clear need.
2. Don't use microservices without DevOps. Many services need CI/CD pipelines for building, testing and deploying, and monitoring and logging to spot problems.
3. Don't create too many small services. Start with services that group related tasks. Split one only when it gets hard to maintain, deploy or scale, because every extra service adds communication and management work.

7.9 Deployment strategies

Independent deployment is the point of microservices, so how a new version reaches users matters. The lecture covers four strategies:

Notice that A/B testing answers a different question. Blue/green, canary and rolling ask "is v2 safe to ship?" A/B testing asks "which version do users prefer?", so it runs for days and needs enough users to make the comparison meaningful.