A deployment pipeline turns a Terraform change into a reviewed, tested, and deployable infrastructure change. It joins two related practices: continuous integration (CI) keeps changes on the main branch workable, while continuous delivery (CD) gets approved changes into environments quickly and safely. Passing CI does not, by itself, deploy infrastructure. section 8.0 section 8.2.3
A practical GitOps pipeline follows this path:
- A developer checks the change locally, then opens a pull request. Keep local and automated testing environments as similar as possible so errors do not slip between them. section 7.2 section 8.3.1
- CI runs configured quality checks, such as linting, validation, security scans, and tests. A failed check is visible on the pull request and can block its merge. The pipeline cannot replace tests that have not been written or tools that have not been configured. section 7.1 section 7.7.2 section 8.3.1
- A speculative Terraform plan shows reviewers the proposed infrastructure changes. After review and merge, CD deploys the project from the main branch. section 8.3.1
A first CI job
Place a GitHub Actions workflow at .github/workflows/tflint.yml. Trigger it on pushes and pull requests; check out the repository, install TFLint, then run `make test_tflint`. If a step fails, the workflow fails and its result appears on the associated pull request. Reuse the same job pattern for other checks rather than treating linting alone as proof that a deployment is safe. section 7.7.2 section 8.3.1
Listing 7.40 TFLint on GitHub Actions
name: Lint
on: #1
push:
pull_request:
jobs:
tflint:
runs-on: ubuntu-latest
steps:
- name: Checkout source code #2
uses: actions/checkout@v4 #3
- name: Setup TFLint
uses: terraform-linters/setup-tflint@v4 #4
- name: Run TFLint
run: make test_tflint #5
The workflow listing shows the triggers, checkout action, TFLint setup, and makefile command that form the CI job. section 7.7.2
For larger test suites, a GitHub Actions strategy matrix can run test functions independently across selected Terraform or OpenTofu versions. This avoids mixing concurrent test logs or serializing slow infrastructure tests. Terraform’s own testing framework can also use a matrix and `terraform test` filters, but its supported test versions need closer attention because the framework is tied to Terraform versions. section 9.3.6 section 9.4.6
Keep delivery responsibilities and operational constraints explicit:
- Prefer an existing CI system for quality checks. Dedicated CD platforms can handle GitOps deployment workflows; deploying directly from CI is possible, but adding CD behavior and automatic state-drift remediation is more complicated. section 7.7.1 section 8.3.3
- Make deployments automatic from start to finish and keep changes small. CI quality controls supply the safety net for frequent deployment; they do not eliminate deployment risk. section 8.2.3 section 8.3.1
- Plan credential handling and platform fit. A CD orchestrator can hold secrets, but managing many copies becomes burdensome; OIDC or a secrets manager may be preferable. Check whether a platform supports every infrastructure tool the team needs. section 8.5.3 section 8.6.5
Do not force application images and infrastructure through one release cycle. Images can have their own CI/CD process; Terraform can reference a chosen image version, making an upgrade a Git-tracked configuration change. If another deployment tool controls progressive image rollout, account for that ownership in Terraform. section 10.8.2
