In a GitLab CI job's `environment:` configuration, what does `deployment_tier` tell GitLab that the environment's name does not?

## The problem it solves GitLab has features that need to distinguish a production deployment from a scratch one: DORA metrics such as deployment frequency and lead time for changes count deployments to production-tier environments, value-stream reporting does something similar, and the UI presents production environments differently. The only signal GitLab has by default is the environment's **name**. It matches conventional words — a name containing `production` or `prod` reads as the production tier, `staging` or `stage` as staging, `test` as testing, `dev` and `review/*`-style names as development. That heuristic is right often enough that most teams never think about it. It breaks the moment your naming does not use those words. Environments called `live`, `prd`, `blue`, `green`, `eu-1` or `acme-corp` are not recognised as production, so every real production deployment is missing from the metrics and the dashboards quietly under-report. Nothing errors; the numbers are just wrong. ## The keyword ```yaml deploy_live: stage: deploy script: ./deploy.sh live environment: name: live url: https://app.example.com deployment_tier: production ``` `deployment_tier` takes one of a fixed set of values: `production`, `staging`, `testing`, `development`, and `other`. It declares the classification rather than letting GitLab guess it. Two things it does **not** do. It does not change how or where the job deploys — the script is unaffected, and nothing about credentials, permissions or ordering follows from the tier. And it is not the mechanism that restricts who may deploy: that is protected environments, configured in project settings and keyed on the environment *name*, not the tier. The tier is recorded with the environment when a deployment runs, so setting or changing it takes effect on the next deployment to that environment rather than retroactively. ## When you actually reach for it Three situations, in practice. **Non-standard production naming.** The most common one, described above: any live environment not called some variant of "production". **Multiple production environments.** A team deploying per region or per tenant — `eu-prod`, `us-prod`, `acme`, `globex` — wants all of them counted as production. Marking each one explicitly makes the reporting correct without forcing a rename that breaks scripts and dashboards. **Environments that look production-like but are not.** A performance or pre-production environment called `prod-mirror` or `prod-shadow` will be inferred as production and inflate deployment-frequency numbers with deploys nobody shipped to customers. Tagging it `testing` or `other` keeps the metric honest. ## Naming still matters Setting the tier does not make naming irrelevant. Names are what protected-environment rules match, what environment-scoped CI/CD variables match, and what humans read on the Environments page. A consistent naming scheme plus an explicit tier is the combination that behaves well; an explicit tier bolted onto chaotic names fixes the metrics and leaves everything else hard to reason about. ## Interview framing This is a small keyword and interviewers use it as a depth probe rather than a gate: knowing it signals that you have actually looked at what GitLab does with environment records beyond "it shows a link". The answer worth giving is one sentence of mechanism — it declares the classification GitLab would otherwise infer from the name — plus the reason it matters, which is that deployment metrics silently count the wrong things when the inference is wrong.