Module 7 — Shipping It to Production

Your app works and it's tested. Now it has to run somewhere other than your laptop, deploy without you SSHing into a box, and tell you when it's sick. This module applies The Edge chapter: a proper container, a pipeline, observability, and an SLO.

Goal

• A Dockerfile that builds a small, secure image.
• A CI/CD pipeline: on push, run tests and migrations; on green + main, deploy.
• Structured logging with a request id, and a health check that means something.
• One SLO defined, so "is it broken?" has an answer that isn't a vibe.

Step 1: Containerise it properly

A container packages your app so it runs the same everywhere. "Properly" means small, layer-cached, and not running as root.

# build stage — has the toolchain
FROM node:22-slim AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build            # tsc → dist/

# runtime stage — only what's needed to run
FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev        # no dev deps in the shipped image
COPY --from=build /app/dist ./dist
USER node                    # don't run as root
EXPOSE 3000
CMD ["node", "dist/server.js"]

Step 2: The CI/CD pipeline

The pipeline turns "push to git" into "tested and deployed" with no manual steps to forget. The order is the safety: test before you deploy, always.

1. On every push: build and test

   Spin up Postgres in CI, run your migrations against it, run the suite from Module 6. A red suite stops here — nothing ships.

2. On green + main: build and push the image

   Build the Docker image, tag it with the commit SHA, push it to a registry.

3. Deploy with migrations first, then a rolling update

   Run pending migrations, then roll out the new image gradually — start new instances, health-check them, shift traffic, retire the old. Your Module 1 graceful shutdown is what makes the retirement clean.

# .github/workflows/ci.yml (sketch)
jobs:
  test:
    services:
      postgres: { image: postgres:16, env: { POSTGRES_PASSWORD: test }, ports: ["5432:5432"] }
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run migrate up      # real migrations
      - run: npm test                # the suite must pass to proceed
  deploy:
    needs: test                      # only if tests passed
    if: github.ref == 'refs/heads/main'
    steps:
      - run: # build, push image, trigger platform deploy

Step 3: Observability — see inside the running system

When this breaks at 2am (see the incident deep dive), you'll have only what you instrumented now. The three pillars:

// request-id + structured access log middleware
app.use("*", async (c, next) => {
  const reqId = crypto.randomUUID();
  const start = Date.now();
  c.set("reqId", reqId);
  await next();
  console.log(JSON.stringify({
    reqId, method: c.req.method, path: c.req.path,
    status: c.res.status, ms: Date.now() - start,
  }));
});

// readiness: don't take traffic if dependencies are down
app.get("/ready", async (c) => {
  try {
    await pool.query("select 1");
    await redis.ping();
    return c.json({ ready: true });
  } catch {
    return c.json({ ready: false }, 503); // LB stops routing here
  }
});

Step 4: Define one SLO

An SLO (service level objective) is a number that defines "good enough," so "is it broken?" stops being a vibe. The chapter's framing: pick a target, measure against it, and the gap between perfect and your target is your error budget — the room you have to take risks.

SLO: 99.5% of GET /s/:publicId requests succeed (non-5xx) and return in under 300ms, measured over 30 days.

That 0.5% is the budget. If you're comfortably within it, ship features faster. If you've burned it — a bad week of errors — the signal is to stop shipping risk and spend effort on reliability. One SLO on your most important path is worth more than a dashboard of metrics nobody has a threshold for.

Acceptance check

docker build -t snippets . && docker run -p 3000:3000 --env-file .env snippets
curl localhost:3000/health    # 200
curl localhost:3000/ready     # 200 if DB+Redis reachable; stop Postgres → 503

# push a branch → CI runs migrations + tests. Merge to main → it deploys.
# tail the logs → each request is one JSON line with a reqId, status, and ms.

You're done when the app runs from a non-root multi-stage image, CI refuses to deploy on a red suite, /ready flips to 503 when a dependency is down, logs are structured with a request id, and you've written down one SLO. Commit it.