Overview
8 Continuous Delivery and deployment
This chapter explains how Continuous Delivery complements, but is distinct from, Continuous Integration, emphasizing rapid, reliable, and automated deployments grounded in GitOps practices. It argues for centralized delivery systems over ad‑hoc local applies to avoid contention and improve consistency, framing each terraform apply as a deployment and positioning Git as the single source of truth. The narrative highlights the industry shift toward dedicated CD platforms, the value of small, frequent releases, and the need to manage multiple environments (feature, staging, production; regional; customer‑isolated) safely while keeping deployments automated and repeatable.
On the module delivery side, the chapter centers on semantic versioning and Terraform’s version constraints to balance stability with agility: tagging releases as vX.Y.Z enables consumers to adopt safe ranges (often via pessimistic constraints) while creators signal the scope of change and uphold compatibility. It weighs pulling modules directly from source control against using registries, noting SCM’s lack of constraint support and the resulting maintenance risks, then recommends adopting registries—public for open source or, more commonly, private ones integrated with your SCM—for scalable consumption. Practical guidance includes publishing flows (such as pushing to Artifactory via automation), maintaining clear changelogs, and treating correct semver as a team responsibility.
For infrastructure delivery, the chapter distills GitOps principles (declarative state, immutable history, pull‑based automation, continuous reconciliation) into a familiar workflow: branch, test, speculative plan, review, merge, and auto‑deploy from main, with drift detection—and optionally remediation—running on a schedule. It compares project structures, cautioning that a single shared root module couples all environments, and recommending per‑environment roots or Terragrunt for isolation and explicit version pinning. Secrets are managed by favoring OpenID Connect to eliminate long‑lived credentials, falling back to dedicated secret managers when needed, and only storing secrets in orchestrators as a last resort. The chapter closes by mapping CD platform features (RBAC, OIDC, secrets, state backends, private registries, policy via OPA, cost estimates), explaining Terraform vs. OpenTofu implications for vendor support, and surveying hosted and self‑hosted options so teams can choose a platform that fits their compliance, multi‑IaC, and cost constraints—ultimately enabling faster, safer delivery.
Summary
- Module Delivery is similar to publishing other software libraries.
- Semantic Versioning makes it easier for developers to use shared modules by making dangerous upgrades obvious.
- Delivering Infrastructure is very different from delivering modules.
- Practices such as GitOps and Continuous Delivery make delivering infrastructure changes safer.
- Continuous Delivery Platforms can be an important tool to enable Continuous Delivery.
- Different teams have different needs and will need to match those needs to the right Continuous Delivery Platform.S
FAQ
How do Continuous Integration (CI) and Continuous Delivery (CD) differ for Terraform?
CI ensures every change builds and passes checks, giving you a safe, always-working codebase. CD focuses on frequently deploying those changes into environments with low risk and fast recovery. Modern teams use dedicated CD platforms for Terraform because they handle deployments, queuing, long-running jobs, and drift remediation more effectively than generic CI systems.Why is Semantic Versioning important for Terraform modules?
Terraform registries expect git tags in the form vX.Y.Z and enable consumers to use version constraints. SemVer communicates upgrade risk: Patch = safe fixes, Minor = new features without breaking, Major = breaking changes. With constraints, consumers can auto-receive safe updates while avoiding breaking ones, reducing maintenance overhead.What version constraints should I use for modules and providers?
Prefer ranges that allow safe upgrades and block breaking ones. Practical guidance: set the lowest compatible version and allow Minor/Patch upgrades, e.g. ~> 1.1 (equivalent to >= 1.1.0, < 2.0.0). Use specific exclusions (e.g., != 1.3.2) if a known-bad release exists. Only pin (= 1.1.1) when you must freeze an exact version.Should I load modules directly from Git or use a registry?
Registries are recommended for scalability because they support the version field and constraints. Direct Git sources don’t support version = ... and force you to choose between risking unreviewed changes (default branch) or pinning exact refs (extra maintenance). Direct Git can be fine for short-lived testing branches.How do private registries and Artifactory-based publication work?
Most private registries integrate with your SCM and ingest releases via SemVer git tags. For Artifactory, you push module releases using the JFrog CLI (jf). Automate via a CI/CD workflow triggered on tags (v[0-9]+.[0-9]+.[0-9]+) and use OIDC to authenticate the workflow to Artifactory without static credentials.What is a Terraform deployment and why centralize it?
A deployment is any terraform apply that updates real infrastructure and state. Centralizing deployments prevents developers from overwriting each other’s changes, enforces one-at-a-time applies per environment, handles network access to private targets, and tolerates long-running jobs—key reasons to use a CD platform.What is GitOps and how does it apply to Terraform?
GitOps uses your SCM as the single source of truth. CD agents pull desired state from git and continuously reconcile it against real infrastructure. For Terraform this means: PR-based changes with speculative plans, automatic deploys from main, and scheduled drift detection (and optionally auto-remediation).How should I structure Terraform for multiple environments?
Two common approaches: 1) Application-as-root with environment-specific tfvars; 2) Environment-as-root, where each environment is a thin wrapper that calls the application module at a specific version. The latter gives true environment independence, easy staged rollouts, and clear version pinning per environment. Terragrunt can simplify this wrapper pattern with small terragrunt.hcl configs.What’s the recommended way to handle secrets in Terraform delivery?
- Prefer no static secrets: use OpenID Connect (OIDC) so your CD system exchanges short-lived tokens for cloud/provider access, avoiding service users and key rotation. - If secrets remain, store them in a Secrets Manager (AWS Secrets Manager, Azure Key Vault, Vault) and load via data sources or native integrations. - As a last resort, store secrets in the CD tool’s secure settings. Be aware secrets may appear in state; avoid storing sensitive values in Terraform-managed outputs or resources when native secret references exist.What features should I look for in a Terraform CD platform, and how do vendors differ?
Key features: GitOps flows, RBAC, OIDC, secret storage, speculative plans, drift detection (with optional remediation), policy enforcement (OPA), cost estimates (built-in or via Infracost), state backend, and a private registry. CD ecosystem notes: newer closed-source Terraform versions effectively tie you to HCP Terraform; most other vendors support OpenTofu (and often Terragrunt, Helm, etc.). Options range from TACOS-style suites (state + registry + delivery) like Env0, Spacelift, Scalr, and HCP Terraform, to GitHub-first operators (Digger, Terrateam), and self-hosted OSS (Atlantis, Terrakube).
Terraform in Depth ebook for free
