The Plan: Commit → Production

The overview promised one commit reaching production safely, automatically, and observably. Before we build any single piece, we draw the whole path — because every later page is just one box in this diagram, and it’s far easier to learn a step when you already know where it sits in the whole. This page is the map; the rest of the Part fills it in.

The discipline here is worth naming: decide what “good” looks like before you build the machine. We set numeric targets first (the DORA metrics), then design a pipeline whose every stage exists to hit them. Build the pipeline first and “fast and safe” stays a vibe; set the targets first and every stage has a job to justify.

The whole path on one page

Here is the journey, end to end. Every box is something a human used to do by hand. The arrows are the automation that now does it the same way every time.

  ┌─ DEVELOPER ──────────────────────────────────────────────────────────────┐
  │  edit code on a branch ─► git push ─► open Pull Request                   │
  └──────────────────────────────────────────────────┬───────────────────────┘
                                                      │  (Part 5: Continuous Integration)
                                                      ▼
  ┌─ CI  (GitHub Actions)  ──────────────────────────────────────────────────┐
  │  build ─► unit tests ─► lint ─► build image ─► Trivy scan ─► sign ─► push │
  │     │        │            │                       │                       │
  │   fail?    fail?        fail?                    CVEs?   ── stop the line ─┤  ← never reaches prod
  └──────────────────────────────────────────────────┬───────────────────────┘
                                                      │  immutable image: snip:<git-sha>
                                                      ▼
  ┌─ REGISTRY  ──────────────────────────────────────────────────────────────┐
  │  ghcr.io/acme/snip:<git-sha>   (content-addressed, signed, scanned)       │
  └──────────────────────────────────────────────────┬───────────────────────┘
                                                      │  pipeline bumps the tag in...
                                                      ▼
  ┌─ GITOPS REPO  (snip-config)  ────────────────────────────────────────────┐
  │  desired state in git: Deployment/Rollout pins image: snip:<git-sha>      │
  └──────────────────────────────────────────────────┬───────────────────────┘
                                                      │  (Part 5: GitOps)
                                                      ▼
  ┌─ ARGO CD  ───────────────────────────────────────────────────────────────┐
  │  reconciliation loop: cluster ← git, forever                             │
  └──────────────────────────────────────────────────┬───────────────────────┘
                                                      │  (Part 4: Kubernetes)
                                                      ▼
  ┌─ KUBERNETES + ARGO ROLLOUTS  ────────────────────────────────────────────┐
  │  canary:  10% ─► analysis ─► 50% ─► analysis ─► 100%                      │
  │             │  metrics from Part 7 say healthy?   ─► promote              │
  │             └─ metrics say bad?                    ─► auto-rollback       │
  └──────────────────────────────────────────────────┬───────────────────────┘
                                                      ▼
                                              ┌─ PRODUCTION ─┐
                                              │  users       │
                                              └──────────────┘

Read it top to bottom: a human writes a change and opens a PR; from there, no human touches anything until they choose to merge. The machine builds it, proves it, freezes it into an artifact, records the new desired state in git, and a controller pulls that state into the cluster and rolls it out gradually, watching real metrics the whole time.

Every box is a Part you’ve already read

This Part invents nothing. Each stage is a chapter you can go back and reread:

Stage in the pipeline	Where it was taught	What it removes
Branch, push, open PR, merge small often	Continuous Integration	The big, scary, batched release
Build + test + lint on every push	Pipelines & Stages	”Run the tests you remember, by hand”
Image build + immutable tag	Dockerfiles, Images & Layers	”Works on my laptop”
Vulnerability scan gate	Image & Dependency Scanning	Shipping known-vulnerable code
Push to a registry	Artifacts & Registries	Copying tarballs over SSH
Desired state in git	GitOps	Imperative kubectl against prod
Controller reconciles cluster ← git	Argo CD, reconciliation loop	A human applying changes by hand
Gradual rollout, auto-rollback	Deployment Strategies, Progressive Delivery	The big-bang manual cut-over
Health visible on real signals	Metrics, SLOs	Tailing logs with fingers crossed

Two repos, on purpose

There are two git repos in this story: the app repo (Snip’s source code, where CI runs) and the config repo (snip-config, the desired Kubernetes state Argo CD watches). Keeping deployment manifests out of the app repo is the GitOps move — CI never needs cluster credentials; it only writes a new image tag into the config repo, and the in-cluster controller pulls from there. We’ll see exactly how in Canary Deploy.

What “good” means: the target DORA metrics

The DORA metrics are how we’ll know this pipeline is actually good and not just complicated. Four numbers, two about speed and two about stability — and crucially, the same practices push both up at once.

DORA metric	Target for Snip	Which stage delivers it
Deployment frequency	On-demand — every merge to main deploys	Automated CI/CD; no release “events”
Lead time for changes	< 1 hour, commit to prod	Fast pipeline + auto-promote canary
Change failure rate	< 15% of deploys cause a problem	Test/scan gates + small batches
Failed-deployment recovery	< 5 minutes	Auto-rollback on metrics + git revert

Speed and stability are not a trade-off here

The naive intuition is that deploying more often must be less safe. The pipeline inverts it. Frequent, small deploys mean each change is tiny, so it’s easier to review, faster to test, and trivial to pinpoint when something breaks. The same automation that makes you fast (no manual steps) is what makes you safe (no manual mistakes). This is exactly the speed-vs-stability argument, now with a concrete machine behind it.

By the numbers — where Snip’s targets sit on the DORA scale

Snip’s four targets aren’t arbitrary; they aim at the “Elite” performer band the DORA / State of DevOps research has reported across its early-2020s surveys. Lined up against the published tiers:

   metric                  Snip target     DORA "Elite" band (approx, early-2020s)
   ──────                  ───────────     ───────────────────────────────────────
   deploy frequency        every merge     on-demand (multiple per day)
   lead time               under 1 hour    under 1 hour
   change failure rate     under 15%       0–15%
   failed-deploy recovery  under 5 min     under 1 hour

The point isn’t the precise thresholds (they drift between report years) but the shape: the same practices in this pipeline — small batches, automated gates, gradual rollout, fast rollback — are what separate Elite teams from low performers on all four axes at once. Snip’s recovery target is actually stricter than the band, because auto-rollback on canary metrics makes “under 5 minutes” realistic rather than aspirational.

The thread, stated for the whole pipeline

The manual, error-prone step this plan removes is the entire human-driven release: a person deciding it’s release day, pulling code, building locally, running a remembered subset of tests, copying artifacts to servers, and applying changes by hand under pressure. Every one of those is replaced by a stage that runs identically every time, refuses to proceed when a gate fails, and leaves an attributable record in git. Production gets safer not because nothing ever breaks, but because the path is deterministic, gated, and reversible — a bad change is caught at a gate, or caught by the canary on real metrics, or undone by a one-line git revert.

With the map drawn, we build it from the inside out. The first box that turns Snip from source into something shippable is the image: Containerize the App.

Check your understanding

1. Trace a single commit through every box in the diagram. At which points can it be stopped before reaching a user, and what stops it at each?
2. Why are there two git repos (app and config), and what would CI need that it currently doesn’t if you collapsed them into one?
3. The four DORA targets split into speed and stability. Name which is which, and explain why the same pipeline improves both rather than trading one for the other.
4. The plan says “decide what good looks like before you build the machine.” Why set DORA targets first instead of measuring them after?
5. State the single manual step this whole plan removes, and name two distinct mechanisms in the pipeline that make a bad change reversible.

Show answers

1. It can be stopped at the CI gates (a failing build, unit test, lint, or Trivy scan halts the pipeline — nothing is pushed), and at the canary (if analysis on real metrics fails, Argo Rollouts auto-rolls-back before traffic widens). Everything before a gate that fails is discarded; the image never reaches the registry, or the rollout never reaches 100%.
2. The config repo keeps deployment state out of the app repo so CI never holds cluster credentials — it only commits a new image tag, and the in-cluster controller pulls. Collapse them and CI would need write access (and credentials) to the production cluster, widening the blast radius and breaking the pull-based GitOps model.
3. Speed: deployment frequency and lead time. Stability: change failure rate and recovery time. The same automation improves both because removing manual steps removes both delay and mistakes, and small frequent batches are simultaneously faster to ship and easier to debug.
4. Because targets turn “fast and safe” from a vibe into a spec. With numbers set first, every stage has a job to justify, and you can tell whether the finished pipeline actually succeeded instead of just feeling busy.
5. The removed step is the entire human-driven release (release-day, manual build, remembered tests, SSH copy, hand-applied changes). Two reversibility mechanisms: auto-rollback on canary metrics and git revert of the config commit, which Argo CD reconciles back.