CI/CD Pipelines Explained: From Push to Production

Part 1 of 17 · ~1 min

Overview

Priya is still logged into the staging box from an hour ago, and it is 6:40 on a Friday. She types docker pull ghcr.io/snapledger/worker and then docker run from memory, the way she's done a dozen times since the Docker chapter of this story ended — except this time two builds finished within nine minutes of each other, one from main and one from a branch Marcus was using to poke at a receipt-currency bug, and the tag sitting at the top of her shell history isn't the one she thinks it is. worker restarts, picks up jobs from the queue, and starts mangling parsed totals on real receipts for forty-one minutes before a customer's bookkeeper notices a number that doesn't add up and emails support.

Nobody did anything wrong, exactly. Priya typed a real command against a real image that genuinely existed. The problem is that "which image is this" lived entirely in a human being's short-term memory, at the end of a long week, and short-term memory is not a reliable place to keep the one fact that decides what a paying customer's data gets run through.

That's where this picks up. Everything up to this point — the Dockerfile, the multi-stage build, the health checks, the resource limits — produces a correct, well-built image. None of it says anything about how that image reliably, repeatably, verifiably ends up running in front of a customer instead of in front of nobody, or worse, in front of everybody with last week's bug still in it. That's a different machine, and this is where it gets built, one gear at a time, until the day it also breaks in its own new way.