10 · DevOps

Software Deployment

Deployment is the act of moving an artifact from "works on my machine" to "serves real users". The discipline is automation, repeatability, and the ability to undo.

The CI/CD pipeline

A pipeline is a sequence of stages, each running on every change. Typical stages:

1. Checkout the code.
2. Install dependencies.
3. Lint — static checks, formatter.
4. Test — unit, integration, with coverage gate.
5. Build — produce the deployable artifact (Docker image, JAR, zip).
6. Scan — secrets, dependencies, image CVEs.
7. Publish — push artifact to registry.
8. Deploy — to staging on every PR, to production on main.

CI = continuous integration: every change is merged often and tested.
CD = continuous delivery (always shippable) or deployment (every green build ships automatically). Pick the level your team and risk tolerance allow.

Artifacts & environments

Build once, deploy many. The same artifact promoted from dev → staging → production. Differences between environments live in configuration, never in the artifact.

Standard environments:

• Dev — engineers' branches; broken is fine.
• Staging — mirror of production, real data shape, synthetic volume.
• Production — real users; every change reviewed.

Containers & orchestration

A container packages the app with its OS-level dependencies. Same image runs on a laptop, a CI runner, or a production node. Best practices:

• Multi-stage Dockerfile (builder stage installs, runtime stage copies only what's needed).
• Run as a non-root user.
• Include a HEALTHCHECK.
• Pin base image versions; never :latest in production.
• Keep the image small — every MB is shipped to every node, every deploy.

Orchestration (Kubernetes, ECS, Fly Machines, Nomad) handles scheduling, scaling, rolling updates, and self-healing of those containers across many nodes.

Deployment strategies

• Recreate — stop old, start new. Downtime. Only for batch jobs.
• Rolling — replace instances N at a time. No downtime; mixed versions briefly serve traffic.
• Blue/green — full new fleet (green) deployed alongside the current one (blue); flip traffic in one step. Fast rollback, double cost briefly.
• Canary — route a small % of traffic to the new version, watch metrics, ramp up. The safest for risky changes.
• Feature flags — code is deployed but inactive. Toggle per user cohort. Decouples deploy from release.

Rollback

The most important property of a deploy is its inverse. If you cannot answer "how do we go back to the previous version in under 5 minutes?", you do not have a deployment process — you have a hope.

• Keep the previous artifact warm in the registry.
• Database migrations should be backwards-compatible (expand-then-contract).
• Feature flags let you "roll back" a feature without redeploying.

Infrastructure as code

The cloud config — VMs, networks, DNS records, IAM roles — lives in version-controlled files (Terraform, Pulumi, CloudFormation). Changes go through the same PR review as application code. No more "what did Pedro click in the AWS console last Tuesday?"

"If it isn't automated, it doesn't exist."

What to remember at exam time

• CI vs CD vs CD: integration, delivery, deployment.
• Build once, deploy many.
• Five deployment strategies + when to pick each.
• Rollback > rolling-forward in an incident.
• Migrations: expand → deploy code → contract.