Pipelines, promotion and GitOps

a merge triggers a sequence of stages on someone else's machine, and the sequence is now the only way anything reaches production.

Build pipeline

the pipeline definition lives in the repository it builds, so changing it is a pull request rather than a click.

Pipeline as code

the job waits in a queue because every machine that could run it is busy, and nobody thinks of that as capacity.

Pipeline runner

the build runs on your own machines so it can reach the private network, and now you own patching and isolating it.

Self-hosted runner

the pipeline produces one file with one version, and everything downstream refers to that file rather than rebuilding.

Build artefact

every build output is stored somewhere with a version and a retention policy, and deploying is a pull from there.

Artefact registry

the exact bytes tested in staging are the bytes that run in production, with only the configuration differing.

Build once, deploy many

the same version moves from staging to production by changing a reference, and no build runs to make that happen.

Artefact promotion

it worked in staging and broke in production, because staging had one replica, no mesh and a different database size.

Environment parity

opening the pull request created a whole running copy at its own URL, and merging it destroyed the copy.

Ephemeral environment

nobody has credentials to deploy; an agent in the cluster watches a repository and makes reality match it.

GitOps

what is deployed lives in a separate repository from the code, and the commit history there is the deployment history.

Config repository

the cluster reaches out to fetch what it should be running, so the pipeline never needs credentials into production.

Pull-based deployment

the pipeline holds a production credential and applies the change itself, and the job's log tells you exactly what happened.

Push-based deployment

someone scaled the deployment by hand during a spike and the agent scaled it straight back down, twice.

GitOps drift

the pipeline stops and waits for a human to press a button, or for a metric to stay inside a threshold for ten minutes.

Deployment gate

instances are replaced a few at a time, so both versions serve traffic simultaneously for several minutes.

Rolling deployment

the pipeline hits three real endpoints after the rollout and fails the deploy if any of them is unhappy.

Post-deploy verification

error rate crossed the threshold ninety seconds in and the system reverted to the previous version without waking anyone.

Automated rollback

the release goes to one percent, then five, then twenty-five, and each step is only taken if the metrics stayed flat.

Progressive delivery

your own staff get it first, then the tolerant customers, then everyone, over about a week.

Deployment ring

the release goes out on Thursday whatever is ready, and anything that missed it waits for the next one.

Release train

nothing may ship for three weeks over the peak period, so a hundred changes go out together on the day it lifts.

Change freeze