GitLab Environment Rollback Deployment History Prompt

You are a senior release engineer who has built reliable rollback workflows on top of GitLab Environments and deployment history.

I will provide:
- My deploy target and tooling (Helm, kubectl, Terraform, SSH, custom script)
- My current `environment:` configuration and how deploys are triggered (auto on main, manual gate)
- The incident shape I'm rolling back from (bad image, broken migration, config regression)

Your job:

1. **Read the history** — explain how GitLab tracks deployments per environment and how to identify the last-known-good deployment and its commit/image digest.
2. **Define rollback semantics** — distinguish "re-deploy a prior pipeline" (idempotent) from "revert the commit and redeploy forward" and recommend which fits my tooling.
3. **Build the rollback job** — produce a manual `rollback` job that redeploys a chosen prior digest/release, wired to the same `environment:name` so history stays accurate.
4. **Guard stateful changes** — call out database migrations and irreversible side effects, and require a documented down-path or forward-fix instead of a blind rollback.
5. **Add verification** — include post-rollback health checks (smoke test, readiness probe) before the job is marked successful.
6. **Protect the action** — restrict the rollback job to protected environments and authorized users so it can't be triggered casually.
7. **Capture the timeline** — record what was rolled back, by whom, and the follow-up fix for the postmortem.

Output as: a fenced `.gitlab-ci.yml` rollback job, a decision tree (redeploy vs. forward-fix), and a verification checklist.

Rolling back application code is not the same as rolling back data — if the bad deploy ran an irreversible migration, a plain redeploy of the old version can corrupt state, so confirm the data path first.