Practical DevOps: from commit to stable production

DevOps is not just tooling#

Many developers start DevOps by installing Jenkins, GitHub Actions, Docker, Kubernetes, or Terraform. Those tools matter, but DevOps is first a delivery discipline: how code moves from a developer machine to production in a repeatable, observable, and reversible way.

A solid DevOps process answers operational questions before incidents happen: who changed what, which checks ran, which artifact is in production, how rollback works, where logs live, which metrics define health, and whether secrets are kept out of source code and images.

The delivery lifecycle#

• Commit: small changes with clear intent and review context.
• Build: produce an artifact that can be reproduced outside a local machine.
• Test: run lint, type checks, unit tests, integration checks, and security scans where useful.
• Package: tag a deployable bundle or container image with a traceable version.
• Deploy: move the tested artifact into an environment with controlled configuration.
• Observe: watch logs, metrics, traces, alerts, and user-facing behavior after release.

A minimal CI pipeline#

For a small web application, a useful pipeline can start with validation, build, scanning, and deployment. Fast feedback is more important than an impressive number of stages.

name: delivery

on:
  push:
    branches: [main]
  pull_request:

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npx tsc --noEmit
      - run: npm test --if-present

Environment consistency#

Local, staging, and production do not need to be identical, but the pieces that change application behavior should be standardized: runtime versions, environment variables, migrations, startup commands, network ports, permissions, and cache settings.

Docker helps standardize runtime, but it does not solve secrets, backups, migrations, storage, or rollback planning by itself. Code should live in the repository; environment-specific configuration and secrets should not.

Deployment strategy#

Not every system needs blue-green or canary releases on day one. Small web products often work well with rolling deployment plus health checks and artifact rollback. Higher-traffic systems may benefit from canary releases where a new version receives a small percentage of traffic first.

• Recreate: simple, but usually causes a short downtime window.
• Rolling: replaces instances gradually and needs reliable health checks.
• Blue-green: keeps two environments and switches traffic when the new one is ready.
• Canary: releases to a small slice of traffic before wider rollout.

Observability is part of the feature#

Deployment is not finished when the command succeeds. Logs show what happened, metrics show system health, traces show where time was spent, and alerts bring the right person in when user-facing behavior is affected.

For APIs, start with request rate, error rate, p95/p99 latency, CPU, memory, database connections, queue depth, and restart count. For frontend, track Web Vitals, runtime errors, failed API calls, and key page load time.

Production checklist#

• README explains local setup, tests, and deployment.
• CI runs lint, type checks, and tests before merge.
• Artifacts are tagged by commit SHA or release version.
• Secrets are stored in the deployment platform or a secret manager.
• Database migrations have a rollback or compatibility plan.
• Health checks verify meaningful readiness, not just a fake 200 response.
• Logs include request or correlation IDs.
• Alerts focus on user impact, not noisy resource changes.

Primary references#

• Docker Docs: Multi-stage builds
• Kubernetes Docs: Deployments
• OWASP API Security Top 10 2023