Production Capstone: Build, Secure, Scale, Observe, and Govern a Complete GitLab Delivery Platform: Requirements, Constraints, and Target Architecture

1. Start with delivery requirements, not a giant YAML file

The capstone integrates the entire course into one operating model. The goal is not to demonstrate every GitLab keyword. The goal is to make a delivery platform whose important state can be reconstructed: which source and configuration created a pipeline, which reusable configuration was resolved, which identities and runners executed it, what evidence and artifact identity were produced, which deployment target changed, what governance controls applied, and how recovery would be proved.

Imagine the fictional Atlas Relay service. It has a small application, one reusable CI contract, untrusted merge-request work, a trusted release path, synthetic security evidence, an immutable release bundle, a simulated staging deployment, and a governance register. The production requirement is deliberately phrased as outcomes: changes must receive fast feedback; release artifacts must be traceable to source; privileged execution must be isolated; deployment state must be independently verified; organization-level controls must not hide their origin; and every incident must leave enough first-failure evidence for review.

2. Translate business constraints into engineering constraints

3. Define non-goals before architecture

A production platform becomes brittle when every adjacent product is silently treated as GitLab CI/CD. This capstone does not turn GitLab into a general secrets vault, cloud provider, Kubernetes control plane, package manager, scanner implementation, or automatic rollback oracle. The mandatory path uses local files for the deployment target and synthetic reports so the state transitions are inspectable without a cloud subscription or paid GitLab feature.

Optional mappings show where a real system would integrate OIDC, registries, Kubernetes, protected environments, pipeline execution policies, audit-event APIs, and provenance services. Those integrations remain separate trust domains and must be verified independently.

4. Inventory the state before changing it

5. Target architecture and trust zones

The architecture has four trust zones. Zone A is developer-controlled source and merge-request input. Zone B is the pipeline-control plane: repository CI configuration plus versioned reusable configuration and, on Ultimate, optional pipeline execution policy injection. Zone C is runner execution; untrusted validation and trusted release jobs must not share an unsafe privileged boundary. Zone D is retained/external state: artifacts, reports, registries, environments, cloud/Kubernetes/IaC targets, audit systems and dashboards.

The arrows matter. Source does not deploy itself. GitLab first compiles configuration and evaluates rules; jobs are then scheduled to runners; jobs produce evidence and artifacts; authorized deployment logic changes an external target; governance captures or enforces policy around those transitions.

            flowchart TD
             A[Developer source / MR
            Zone A] --> B[Compiled reusable CI
            Zone B]
             P[Policy project / version
            optional Ultimate] --> B
             B --> C1[Untrusted validation runner
            Zone C]
             B --> C2[Trusted release runner
            Zone C]
             C1 --> R[Test / quality / security reports
            Zone D]
             C2 --> X[Release artifact + digest
            Zone D]
             X --> D[Authorized deployment
            Zone D]
             D --> T[External target + health
            Zone D]
             B --> E[Pipeline / job IDs + logs]
             R --> E
             X --> E
             T --> E
             E --> G[Audit / SLO / exception / recovery evidence]
          

6. Separate mandatory learning from optional enterprise controls

7. Define SLOs, failure budgets and cost bounds

A governed pipeline needs operational objectives, not only security controls. For the lab, use these synthetic objectives: 95% of validation pipelines should start a runnable job within 60 seconds; the validation critical path should be under 8 minutes; release artifacts must have a source SHA and digest 100% of the time; staging deployment verification must complete within 2 minutes; and every declared exception must have an owner and expiry.

Cost bounds are equally explicit: no privileged shared runner for untrusted work; no unbounded autoscaling; no cloud subscription; no mandatory paid GitLab feature. If a production team later chooses paid controls, their cost and failure mode are architecture inputs rather than hidden assumptions.

8. Read-only preflight: prove what platform you actually have

Before creating anything, capture versions and source state. The commands are intentionally read-only. On a real GitLab project, add project/pipeline/runner identifiers only if the project is authorized and disposable.

date -u +%FT%TZ
git --version
python --version
glab --version 2>/dev/null || true
gitlab-runner --version 2>/dev/null || true

git rev-parse --show-toplevel 2>/dev/null || true
git rev-parse HEAD 2>/dev/null || true
git status --short 2>/dev/null || true

# Optional authenticated disposable-project checks.
glab ci lint --dry-run --include-jobs --ref main 2>/dev/null || true
gitlab-runner list 2>/dev/null || true
gitlab-runner verify 2>/dev/null || true

9. The capstone evidence contract

Every later lesson adds to one packet. At minimum it must answer: source/ref/SHA; pipeline source and compiled/reusable configuration identity; pipeline/job IDs if GitLab is used; runner/executor/tool versions; non-secret rule/input result; report and artifact identifiers/digests; deployment/target verification; policy/exception evidence; and assumptions/limitations. Evidence is useful only when another engineer can connect it to the exact state transition it proves.

10. Lesson summary

You now have requirements, explicit non-goals, trust zones, state inventory, tier-aware boundaries, SLOs and an evidence contract. Lesson 2 turns that architecture into a small, runnable delivery platform whose configuration, build evidence, artifact identity and simulated deployment are all inspectable.

Knowledge check

Official references and version notes

Further reading — current official GitLab sources

Version-sensitive assumptions in this production capstone were checked against current official GitLab documentation on 2026-09-13. Re-check your exact GitLab, GitLab Runner, glab, executor, component, image/tool and external-provider versions before applying the operating model to production.

• GitLab Docs — GitLab 19.3 release notes
• GitLab Docs — Critical patch release 19.3.2
• GitLab Docs — Release and maintenance policy
• GitLab Docs — Deprecations and removals
• GitLab Docs — CI/CD YAML syntax reference
• GitLab Docs — Use CI/CD configuration from other files
• GitLab Docs — CI/CD inputs
• GitLab Docs — CI/CD components
• GitLab Docs — Pipeline security
• GitLab Docs — Validate CI/CD configuration / CI Lint
• GitLab Docs — Runner security
• GitLab Docs — CI/CD job token
• GitLab Docs — OIDC authentication using ID tokens
• GitLab Docs — Job artifacts
• GitLab Docs — CI/CD artifact report types
• GitLab Docs — Environments and deployments
• GitLab Docs — Protected environments
• GitLab Docs — Deployment approvals
• GitLab Docs — Pipeline execution policies
• GitLab Docs — Audit events
• GitLab Docs — Audit events API
• GitLab Docs — Attestations API (Experimental)
• GitLab Docs — glab attestation (Experimental)

Current assumptions used in this chapter: Version-sensitive YAML, Runner/executor behavior, APIs, security features, policy controls, tiers, and deprecations must be verified against the exact GitLab, GitLab Runner, tool, and external-system versions used in production. Preserve the exact project/ref/SHA, compiled configuration, pipeline/job IDs, runner/tool versions, and external target evidence used for reproducible work.