The infrastructure pipeline pattern — eight stages from commit to audit

Infrastructure CI is a pipeline, not a job. The most common mistake teams make when adopting CI/CD for Terraform, Ansible, or Kubernetes manifests is collapsing every check into a single step that runs terraform apply. That single step produces no useful signal: the apply either succeeds (and you learned nothing about risk) or fails (and you learned about a syntax error you could have caught at the format stage for free). The eight-stage pipeline exists to spread feedback across time, cost, and severity so that cheap checks happen first and expensive checks happen only on changes that have already passed the cheap ones.

The eight stages

The eight stages of an infrastructure CI pipeline, in the order they run, are: format, lint, security, tests, plan, review, apply, audit. Each stage is a separate job with its own runner, its own timeout, and its own success criterion. Failure at any stage halts the pipeline and surfaces a specific feedback signal.

flowchart LR
    A["1. format"] --> B["2. lint"]
    B --> C["3. security"]
    C --> D["4. tests"]
    D --> E["5. plan"]
    E --> F["6. review"]
    F --> G["7. apply"]
    G --> H["8. audit"]

The order is deliberate:

• Format runs first because it is the cheapest (seconds) and catches the most common contributor mistake (inconsistent whitespace, misaligned blocks). Failing here wastes zero reviewer time.
• Lint runs next because it is still cheap and catches semantic-but-not-syntactic problems: unused variables, deprecated resources, missing tags.
• Security runs third because it is more expensive (it builds a graph of resources) but still static. A misconfigured S3 bucket or an open security group should never reach plan.
• Tests run fourth because they are dynamic — they provision real or simulated resources. Tests belong after static gates so a change that fails lint never spins up cloud resources.
• Plan runs fifth because it is the most expensive static operation: a full provider refresh against real APIs.
• Review is the human-in-the-loop stage: a reviewer examines the plan artefact, the security report, and the test report before approving.
• Apply runs only after review, with the exact plan that was reviewed.
• Audit runs after apply to record what actually happened against what was approved.

What each stage catches

A useful way to read the pipeline is “what does this stage prevent?”. The table below summarises:

Static gates versus dynamic gates

The first four stages are static: they read the source files and produce a verdict without contacting any external system. Format, lint, security scanning, and unit-level convention tests all fit here. Static gates are fast, deterministic, and safe to run on every push, including pull requests from forks.

The next two stages are dynamic: they contact external systems. terraform plan calls the provider APIs and may read state from a remote backend. Terratest provisions real infrastructure (or mocks it via a local backend). Dynamic gates are slower, may have side effects (refreshing state, creating ephemeral resources), and are therefore gated behind the static gates.

The last two stages are operational: review is human, apply mutates state, audit records. These stages are not “checks” in the same sense; they are the point of the pipeline.

Production discipline

Three rules govern how an infrastructure pipeline is constructed:

1. Every stage is a separate job. Two stages that share a runner share an environment, and an environment that holds a terraform apply is an environment that should not be holding a tflint cache.
2. Every gate fails the build. A security warning that does not fail the build is not a gate; it is a log line. Decide whether the warning is a gate before you write the pipeline, not after the first false positive.
3. The plan artefact is the review artefact. The exact bytes the reviewer approved are the bytes that are applied. Re-planning between review and apply is a re-review, not a re-run.

Cross-course references

• Ansible for Production Sysadmins — Part XXXVII (RepoArch) covers Ansible repository layout, which feeds the lint and test stages of an Ansible CI pipeline.
• Terraform for Production Sysadmins — Part XXV (QualityGates) covers the format, lint, and validate gates in depth; the plan and review stages are covered in Part XXVI (PlanReview).
• Kubernetes for Production Sysadmins — Parts XXX-XXXII cover manifest validation, the Kubernetes analogue of the static gates.

Quiz