Docker containers and the purpose of CI/CD

The "works on my machine" problem

An application that runs perfectly on your laptop can fail on a server because of a different operating system version, a missing library or a different runtime version. Containers solve this by packaging the application together with everything it needs into one portable unit.

Containers and virtual machines

Because containers are light, one server can run many of them, and the same container runs identically on a laptop, a test server and in the cloud.

Images and containers

• An image is a read-only template: the app, its runtime and its files, built in layers.
• A container is a running instance of an image. You can start many containers from one image.
• A registry such as Docker Hub stores and shares images.

A Dockerfile

A Dockerfile is a recipe for building an image. Here is one for a small Node.js web server:

# Start from an official image that already contains Node.js
FROM node:22-alpine

# Work inside /app in the image
WORKDIR /app

# Install dependencies first so Docker can cache this layer
COPY package*.json ./
RUN npm ci --omit=dev

# Copy the application code
COPY . .

# Document the port the app listens on, then define the start command
EXPOSE 3000
CMD ["node", "server.js"]

Build the image and run a container from it:

docker build -t devcrest-demo .
docker run -d -p 8080:3000 --name demo devcrest-demo
# The app is now at http://localhost:8080

docker ps            # list running containers
docker logs demo     # view the container's output
docker stop demo     # stop it

-p 8080:3000 maps port 8080 on your computer to port 3000 inside the container.

CI/CD: automating the path to production

Teams merge many changes every day. Testing and deploying each one by hand is slow and error-prone. CI/CD automates it:

• Continuous integration (CI): every push or pull request automatically builds the code and runs the tests. Broken changes are caught within minutes, before they are merged.
• Continuous delivery (CD): every change that passes CI is automatically packaged and ready to release; continuous deployment goes further and releases it to production automatically.

A GitHub Actions workflow

GitHub Actions runs CI/CD pipelines defined in YAML files inside the repository, under .github/workflows/:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

On every push to main and on every pull request, GitHub starts a fresh Linux machine, checks out the code, installs Node.js and the dependencies, and runs the tests. The result appears as a green tick or red cross on the pull request, so reviewers know whether the change is safe to merge.